patternsqlModerate
Non-yielding IOCP Listener
Viewed 0 times
listeneryieldingiocpnon
Problem
Does anyone know what "Non-yielding IOCP Listener" indicates?
On of our SQL Servers just had a bugcheck dump:
`=====================================================================
BugCheck Dump
=====================================================================
This file is generated by Microsoft SQL Server
version 9.00.5292.00
upon detection of fatal unexpected error. Please return this file,
the query or program that produced the bugcheck, the database and
the error log, and any other pertinent information with a Service Request.
Computer type is AT/AT COMPATIBLE.
Bios Version is DELL - 1
Phoenix ROM BIOS PLUS Version 1.10 1.5.2
Current time is 23:01:04 09/07/12.
48 Unknown CPU 9., 2 Mhz processor (s).
Windows NT 6.1 Build 7601 CSD Service Pack 1.
Memory
MemoryLoad = 81%
Total Physical = 524278 MB
Available Physical = 97549 MB
Total Page File = 524276 MB
Available Page File = 94472 MB
Total Virtual = 8388607 MB
Available Virtual = 78
On of our SQL Servers just had a bugcheck dump:
`=====================================================================
BugCheck Dump
=====================================================================
This file is generated by Microsoft SQL Server
version 9.00.5292.00
upon detection of fatal unexpected error. Please return this file,
the query or program that produced the bugcheck, the database and
the error log, and any other pertinent information with a Service Request.
Computer type is AT/AT COMPATIBLE.
Bios Version is DELL - 1
Phoenix ROM BIOS PLUS Version 1.10 1.5.2
Current time is 23:01:04 09/07/12.
48 Unknown CPU 9., 2 Mhz processor (s).
Windows NT 6.1 Build 7601 CSD Service Pack 1.
Memory
MemoryLoad = 81%
Total Physical = 524278 MB
Available Physical = 97549 MB
Total Page File = 524276 MB
Available Page File = 94472 MB
Total Virtual = 8388607 MB
Available Virtual = 78
Solution
IOCP is an I/O Completion Port. A Non-Yielding IOCP Listener means that the thread that handles the IO completion routines took a (relatively) looooong time doing something, and SQLOS though that it may be stuck/hung/whatever.
Sql server does lots of ASYNC IO. The way it works is when it submits the IO request to the OS, it says "Do this IO asynchronously. Here's a function pointer to call when it's done."
The function that gets called is the IO completion listener.
Consider a page read from disk. A thread running a select needs to read a page that's not in memory. It takes a PAGEIOLATCH, issues the async IO to windows to read the page, and goes to sleep.
When the OS finishes the IO, it calls the IOCP function which flags the IO as "done". Shortly afterwards, a sql thread finishes its 4ms quantum, and checks for IO's to handle. It flags it as done and signals the issuing thread to wake up. The SELECT thread get scheduled, releases the PAGEIOLATCH, and life is good.
Now, the amount of work that the IOCP does varies depending on the type of IO involved. I believe that with DB Mirroring, it does more work than it would if it was just reading a page into the buffer pool.
If you're a programmer working on sql server, and you want to optimize the DB Mirroring code, you might be tempted to put more work in the IOCP mirroring code path vs the SQLOS system thread code path.
Or maybe the IOCP needs to copy the data into some mirroring buffer that is a fixed size, and it sits in a loop until it's done.
Or maybe <> happens, and the IOCP function seems "stuck".
I wouldn't worry about this if it happened during a failover and a lot of LOG activity happened. If it happens consistently, then it may require further investigation.
Sql server does lots of ASYNC IO. The way it works is when it submits the IO request to the OS, it says "Do this IO asynchronously. Here's a function pointer to call when it's done."
The function that gets called is the IO completion listener.
Consider a page read from disk. A thread running a select needs to read a page that's not in memory. It takes a PAGEIOLATCH, issues the async IO to windows to read the page, and goes to sleep.
When the OS finishes the IO, it calls the IOCP function which flags the IO as "done". Shortly afterwards, a sql thread finishes its 4ms quantum, and checks for IO's to handle. It flags it as done and signals the issuing thread to wake up. The SELECT thread get scheduled, releases the PAGEIOLATCH, and life is good.
Now, the amount of work that the IOCP does varies depending on the type of IO involved. I believe that with DB Mirroring, it does more work than it would if it was just reading a page into the buffer pool.
If you're a programmer working on sql server, and you want to optimize the DB Mirroring code, you might be tempted to put more work in the IOCP mirroring code path vs the SQLOS system thread code path.
Or maybe the IOCP needs to copy the data into some mirroring buffer that is a fixed size, and it sits in a loop until it's done.
Or maybe <> happens, and the IOCP function seems "stuck".
I wouldn't worry about this if it happened during a failover and a lot of LOG activity happened. If it happens consistently, then it may require further investigation.
Context
StackExchange Database Administrators Q#23922, answer score: 10
Revisions (0)
No revisions yet.