tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: Tomcat and Window nonpaged pool
Date Fri, 05 Apr 2013 14:53:03 GMT
Jeffrey Janner wrote:
>> -----Original Message-----
>> From: André Warnier []
>> Sent: Thursday, April 04, 2013 12:34 PM
>> To: Tomcat Users List
>> Subject: Re: Tomcat and Window nonpaged pool
>> Jeffrey Janner wrote:
>>>> -----Original Message-----
>>>> From: Harris, Jeffrey E. []
>>>> Sent: Thursday, April 04, 2013 10:45 AM
>>>> To: Tomcat Users List
>>>> Subject: RE: Tomcat and Window nonpaged pool
>>>>> -----Original Message-----
>>>>> From: Jeffrey Janner []
>>>>> Sent: Thursday, April 04, 2013 11:04 AM
>>>>> To: 'Tomcat Users List'
>>>>> Subject: Tomcat and Window nonpaged pool
>>>>> Tomcat 6.0.x (unsure but 33+)  with Java 1.6 and Windows 2008
>> Server.
>>>>> I've got a customer who is monitoring his system using the Windows
>>>>> Performance Monitor and is concerned about Tomcat usage of the
>>>>> nonpaged pool.  When monitoring just the Tomcat service, it shows
>>>>> the line for the pool to slowly rise over time, with hardly ever a
>>>>> drop that cannot be attributed to a restart of the service (I
>> think).
>>>>> I know that the nonpaged pool contains structures that should not
>> be
>>>>> paged out by Windows per this quote:
>>>>>   "Nonpaged pool is therefore always kept present in physical
>> memory
>>>>> and nonpaged pool virtual memory is assigned physical memory.
>> Common
>>>>> system data structures stored in nonpaged pool include the kernel
>>>>> and objects that represent processes and threads, synchronization
>>>>> objects like mutexes, semaphores and events, references to files,
>>>>> which are represented as file objects, and I/O request packets
>>>>> (IRPs), which represent I/O operations."
>>>>> I am struggling with how this relates to internal workings of
>> Tomcat
>>>> &
>>>>> Java.  Obviously, as more processing threads, in this case
>>>>> connectors not executors, are opened, I would expect to see a rise
>>>>> in this pool to support all the items it uses.  I would expect to
>>>>> see a drop as usage dropped and connectors were returned (or are
>>>>> they permanent at
>>>> 6).
>>>>> Also, I assume processing threads for the Oracle connection pool
>>>>> will cause this to increase as well, and should drop as the pool
>>>>> size drop back to normal.  Any app-based threads would also cause a
>>>>> rise, but should drop if the thread is properly terminated.
>>>>> I guess that this shows a potential memory leak somewhere, I'm just
>>>>> wondering if there are other things I should look at that could
>>>>> determine if this is normal behavior or indicative of a real issue.
>>>>> I do most of my Tomcat app monitoring using jconsole, jvisualvm,
>> and
>>>>> the Oracle OEM for looking for connection pool leaks there (not an
>>>>> easy task).
>>>>> Any help is appreciated.
>>>>> Jeff
>>>> You might try the procedure in this URL to further isolate the
>> issue:
>> nonpaged
>>>> -
>>>> and-paged-pool-errors-in-windows/
>>>> If you have the ability, you might also try disconnecting your
>>>> Webapps and Oracle and see if simply running Tomcat by itself still
>>>> displays the same behavior; if so, then the issue is probably
>> Tomcat,
>>>> rather than a Webapp or Oracle.
>>>> If you are not using the latest version of Tomcat 6.0, you might
>> also
>>>> want to try upgrading and see if the behavior changes, as it is
>>>> possible there are memory leaks in earlier versions of Tomcat (some
>>>> of the Tomcat developers can speak to that).
>>>> Jeffrey Harris
>>> Oh, I fully expect any problems to be with our webapp and not Tomcat.
>>> The end user should be on a version of Tomcat6 very near the latest
>> release, at least if they are following our usage recommendations.
>>> Unfortunately, it's at a customer site and I have not access to it.
>> I'm totally dependent on their willingness to research the issue on
>> their end and any information about how they are using the app vs. our
>> other customers.  I think they are using a specific feature that is
>> little used by 90% of our customer base causing the issue.
>>> I ran the same monitor against two of my hosted Tomcat instances,
>> with several virtual hosts each, meaning a diverse user base. It does
>> not appear to show the pattern. However, I may need to do a longer run
>> to see if I replicate their results.  My results were over a 15 minute
>> period.  Theirs was several days.  Mine remained flat, or nearly so.
>> In fact, I saw a nice little random rise and fall in the graph right
>> around a central value for both Tomcats.  One actually ended lower than
>> it started.
>>> So, I'm pretty sure it's our app and how it's being used.  Just
>> trying to understand what objects might be getting tossed into this
>> pool, so I know what to go after.
>> Does you app connect to anything by itself ?
>> If so, does it close these connections properly ?
>> "netstat -pan" might show something.
> Yes, it connects to an Oracle DB, and I strongly suspect they may be seeing a connection
pool leak in a little-used bit of code.  But I'm also trying to figure this out without access
to the machines themselves, so was hoping to get guidance on other questions to ask them.
> Essentially, as I understand it, the non-paged pool primarily stores data structures
needed to manage threads and semaphores, which in tomcat terms is connectors, executors, and
any DB pool connections, etc.  I would assume that the heap and classes get put into the paged
pool.  I was hoping someone here knew exactly if there was something other I should suspect.
> Reviewing older posts, thanks Christopher, it does appear that there could be some release-level
issues in Java/Tomcat/native as well as it could be Windows OS issues itself. (Didn't realize
I'd seen this on a local machine 2 years ago until I checked the archive.)  So I do have some
questions to ask the customer admin.

I am totally out of my depth regarding the type of things which are stored in this 
non-paged memory (to tell the truth, I did not even know that there existed such a thing..)
But since you mentioned that the kind of things stored there included structures allocated

for the access to files e.g. (I suppose that each opened file must have some kind of "file

descriptor" structure along with low-level I/O buffers and the like), this would probably

also apply to any kind of network connection that is not being properly closed, or 
"returned to the OS" at the end of it's usage.  That is why I suggested a "netstat", to 
display such and get an idea if there are things lingering there longer than they should.

  If there are, then I suppose that over time this could amount to a leak of memory.
It could also be a bit "sneaky", in the sense that from the Tomcat/java point of view, 
these things are no longer connected to the process, but from the OS point of view, they 
are not really released, so they stick around.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message