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.
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?
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?
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.
On 9월23일, 오전6시35분, David Schwartz <dav...@webmaster.com> wrote:
> 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?
Windows 2008 Server (x86) in physical memory 4GB. 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.
On Sep 23, 9:45 pm, imays <imay...@gmail.com> wrote:
> 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?
On 9월24일, 오후5시46분, David Schwartz <dav...@webmaster.com> wrote:
> On Sep 23, 9:45 pm, imays <imay...@gmail.com> wrote:
> > 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
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?
On Oct 4, 2:40 am, imays <imay...@gmail.com> wrote:
> 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!
|
