Yes I am referring to the Http11NioProcessor objects. Playing with the cache size did not help, since I had to deal with ~7000 registered Http11NioProcessor objects (by registered I mean the object becoming a JMX managed object). That amount by itself consumed a lot of the old gen space (around ~600MB of the 1.6GB) and left no room for other long lived objects. As a consquence, the server had to constantly perform a GC. Also, since the cache size was much lower than 7000, the actual creation, registration and dereregistration of Http11NioProcessor objects caused a major concurrency bottleneck. Changing the Http11NioProcessor to be dedicated to request and not to a connection dropped the number of concurrent registered processors to ~500 (instead of the 7000) in the same production environment and eliminated all memory ad concurrency problems.
I am not sure how the maxKeepAliveRequests can help. The problem is the delay between each new http request on the same TCP connection. Browsers tend to keep connections open without sending new requests in a hope for reusing the connection. In the meantime, the processor is doing nothing (reference in kept in the connections map, socket state is LONG), consuming memory and not returned to the cache. On Thu, May 21, 2009 at 5:12 PM, Filip Hanik - Dev Lists <devli...@hanik.com > wrote: > hi Sagi, are you referring to the Http11NioProcessor objects? > If so, you should be able to configure the cache size when connections are > released. So you could also use maxKeepAliveRequests to limit it > > do you have the memory dump available? > Filip > > > > sagi tomcat wrote: > >> Hello, >> >> I am using Tomcat 6.0.18 in a production server, serving thousands of >> users >> and hundreds of transactions per second. I am using the NIO connector. >> I've >> noticed a serious memory utilization problem which were traced to the fact >> that a single processor is dedicated to a connection and is not recycled >> in-between requests. I've noticed ~7000 registered processors and that, as >> a >> result, the server was busy doing GC and nothing else. I've performed >> modification to the code to allow a processor to be recycled between >> requests (I believe this was the behavior in older Tomcat versions) which >> indeed solved the memory problem. I'd like to know more regarding the >> implications of such a modification and to understand more why is the >> processor is dedicated to a connection and not to a request. >> >> Thanks >> >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
