2016-08-10 14:29 GMT+02:00 Lazar Kirchev <lazar.kirc...@gmail.com>: > Hello Christopher, > > I tried with 32 MB and even 24 MB heap and the CPU usage and response time > remained the almost the same (the difference is negligible) as with 1 GB > heap. The cumulative allocated memory for the HeapByteBuffer remains about > 400 MB, but of course the frequency of GCs is increased.
A newbie question: if you tried with 32 MB ( I guess -Xmx size ) , why is not raised an OOM error ? are those 400MB allocated outside heap ? Thanks > > Regards, > Lazar > > On Tue, Aug 9, 2016 at 7:27 PM, Christopher Schultz < > ch...@christopherschultz.net> wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA256 >> >> Lazar, >> >> On 8/9/16 8:40 AM, Lazar Kirchev wrote: >> > Hello! When handling requests which make use of request dispatcher, >> > Tomcat 7.0.70 allocates more memory in comparison to 7.0.69. This >> > seems to come from the encoding of the path introduced with this >> > change http://svn.apache.org/viewvc/tomcat/tc7.0.x/trunk/java/org/ >> > apache/catalina/core/ApplicationContext.java?r1=1741024&r2=1741023&pat >> hrev= >> > >> > >> 1741024 >> > 50000 requests to a very simple servlet which only gets a request >> > dispatcher for some path lead to allocation of about 400 MB. >> > However, after a GC they are freed and this actually does not >> > influence CPU or response time. Has anybody noticed this effect and >> > what do you think about it? >> >> What happens if you set the heap size very low (e.g. 32MiB) and run >> the same test? Does the memory usage grow to 400MiB, or does the >> request performance start to degrade? >> >> I'm curious if you are just seeing the effect of the GC doing its job >> correctly. >> >> - -chris >> -----BEGIN PGP SIGNATURE----- >> Comment: GPGTools - http://gpgtools.org >> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >> >> iQIcBAEBCAAGBQJXqgSPAAoJEBzwKT+lPKRY6+8P/2vzkhQJkPKjYAFln5wkbPp7 >> lbIVDvcH5546ch4nTQsrMPiUT/m71wwDytn6qOMzP9dIbAXjC3tBJI+nqDthkZyQ >> ScmIi2A93JQl0aOHrMzCuS3cFk0sNdwK3n2sk8ZcFd5/KZ5cwxkyeUqwiRVbU5bA >> MjJsEiq+r7Vgo6V3mAxMwaKS7mwLc1hcgJMrhJA8gjfeHzxhzeG0mcrIGrg5cGvl >> mTHLovt9x1ts4KNApdt4DUSg+Yt3Fx/Gj1aoL1x1KbPM9VIJSb52IG/03WPMxIkq >> fSM71fbZHpjZy19uV+e50sHzM0fg96RsrlQ7m5Uvjgqkz6zxNYlsX3tC0z1E7oEr >> wq1Qi0C3dCbRe6vqnN3znYg+DyrlZ/R+qO8+35GD3ljiiDuJLpevYFNVjNceFn1Y >> Qno6W8/2Dp1eHTxaAAVY4hhbdZyzLgxD+lOu+THkOnoZwx8Bw8TXStHIdbwtMfSz >> 9jGuZU4W/t9uTgW6ZnauS16v2EKUbicFY9L5FB3vrRUi1qm+pYVMUdQoZtVl2yL6 >> ZoDTEZTGzvpNUoJLGDzWjp9QkXkVGIrgM7+uYXIDcMUn7QrmLLab7oGJO1pLuAlz >> 9BJiLpjqja5eAHp/Bz1ud5ZZhBaNECJIqhkjma/+LAC1Meullf3ct4FRmL8aGfUz >> m0ntWlqyXwr6EbmRjbFE >> =FTq+ >> -----END PGP SIGNATURE----- >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
