Cause of high NP Pool (nonpaged pool) in afd.sys?
imays
afd.sys? I tried verifier.exe and pooltag.exe however I cannot find
the exact cause.
I googled for it and found some forum threads which already discusses
it, and someone say SO_SNDBUF,SO_RCVBUF and someone say 'too much
issue of overlapped WSASend(To) and WSARecv(From)' can also cause the
problem. However, I cannot figure out the exact cause yet.
What is the recommended way for tracing the cause of NP pool problem
with afd.sys?
Thanks in advance.
Hyun-jik Bae
David Schwartz
> How can I find the cause of NP pool (nonpaged pool) peaking high of
> afd.sys? I tried verifier.exe and pooltag.exe however I cannot find
> the exact cause.
Exactly what operating system are you using? How much physical memory
does the machine have? How high does NP usage get?
Do you see high NP usage associated with a particular executable? If
so, what does that executable do? (The task manager can show NP usage
by process.)
Most likely, the cause is one of three things:
1) Wise use of TCP overlapped I/O but insufficient physical memory.
2) Using non-server operating systems for servers.
3) Incorrect use of overlapped I/O such as posting very large buffers
or heavily fragmented buffers.
DS
imays
> On Sep 22, 3:23 am, imays <imay...@gmail.com> wrote:
>
> > How can I find the cause of NP pool (nonpaged pool) peaking high of
> > afd.sys? I tried verifier.exe and pooltag.exe however I cannot find
> > the exact cause.
>
> Exactly what operating system are you using? How much physical memory
> does the machine have? How high does NP usage get?
The total NP pool usage doesn't hit over 100MB, however, the suffering
process takes 20MB of NP pool with 22MB of commited memory pages.
>
> Do you see high NP usage associated with a particular executable? If
> so, what does that executable do? (The task manager can show NP usage
> by process.)
As mentioned above.
>
> Most likely, the cause is one of three things:
>
> 1) Wise use of TCP overlapped I/O but insufficient physical memory.
1 isn't the cause, I think. In ordinary situation (even with heavy
simultaneous connection) my app takes lesser than 1MB NP pool which
22MB memory pages are committed.
>
> 2) Using non-server operating systems for servers.
2 isn't the cause. I use Windows Server 2008.
>
> 3) Incorrect use of overlapped I/O such as posting very large buffers
> or heavily fragmented buffers.
Yesterday I found that NP pool increases rapidly whenever many ICMP
host(and port) unreachable packets are received at the server side.
(The server side executes my app.)
So I experimently blocked ICMP host(and port) unreachable packet via
Windows Firewall and the problem doesn't occur anymore. You might
guess that incorrect handling of the case where WSARecvFrom returns
WSACONNRESET may be the cause, however, my app uses setsockopt
(SIO_UDP_CONNRESET=FALSE) so there's no chance to occur WSAECONNRESET
on the server.
I suspect there's a problem on using SIO_UDP_CONNRESET in Windows 2008
Server.
>
> DS
David Schwartz
> So I experimently blocked ICMP host(and port) unreachable packet via
> Windows Firewall and the problem doesn't occur anymore. You might
> guess that incorrect handling of the case where WSARecvFrom returns
> WSACONNRESET may be the cause, however, my app uses setsockopt
> (SIO_UDP_CONNRESET=FALSE) so there's no chance to occur WSAECONNRESET
> on the server.
> I suspect there's a problem on using SIO_UDP_CONNRESET in Windows 2008
> Server.
Sounds like that may be the issue. Does the issue go away if you don't
set SIO_UDP_CONNRESET to FALSE?
DS
imays
Sorry, my mistake. The version occuring the problems was what
SIO_UDP_CONNRESET has been used.
My app have treated WSAECONNRESET just like this:
If WSARecvFrom() returns THEN call WSARecvFrom() UNTIL it returns
WSAECONNRESET no more.
I think this may cause a great amount of overlapped io (for recvfrom)
and it takes NP pool seriously.
However I assumed returning WSAECONNRESET by WSARecvFrom() will lead a
GetQueuedCompletionStatus() function call emit completion event with
WSAECONNRESET, but it never does at my experiment.
Now my question becomes: what is the recommended way in case of
overlapped WSARecvFrom() call returns WSAECONNRESET?
Thanks!
Hyun-jik Bae
David Schwartz
> Now my question becomes: what is the recommended way in case of
> overlapped WSARecvFrom() call returns WSAECONNRESET?
I think I see your problem. You are not waiting for the operation to
finish completing to issue another operation, so you wind up with
large numbers of operations in-flight. That can cause high NP pool, as
you've discovered.
When WSARecvFrom returns WSAECONNRESET, the operation has completed,
but you have no yet gotten the completion indication. If you reissue
an operation now, you'll have multiple completion packets in-flight.
That's normally okay, so long as you do nothing when you do get the
completion indication.
There are two fixes:
1) If WSARecvFrom returns WSAECONNRESET, do nothing. When you get the
completion indication, issue another WSAECONNRESET.
2) If WSARecvFrom returns WSAECONNRESET, check your operation count.
If it's high, do not issue another operation. If it's low, issue
another WSARecvFrom and bump the operation count. When you get the
completion, drop the operation count but do nothing else.
DO NOT double operations by issuing another operation both when
WSARecvFrom returns and when you get the completion indication!
DS