Am 11.08.2016 um 21:16 schrieb Jose María Zaragoza:
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 ?
Allocation size is not the same as size of objects in memory. An
allocation of 400 MB during some test means the sum of the sizes of all
objects that were created was 400 MB. The life time of those objects
could be very short. So it is possible that only few of them were in
memory at the same time.
An extreme example: suppose you create 1000 objects per second (or one
per millisecond) each of size 10 KB. That means you have an allocation
rate of 10 MB/s or after one minute 600 MB. Assume further that each
object only lives 5 milliseconds, because it maybe is created and used
only inside a method that runs very short. Then at each point in time
about 5 of those objects exist which makes up only 50 KB of memory.
For many java programs the popular slogan "most objects die young" is
correct, which means you can have high allocation rates with relatively
small memory. Allocation is relatively cheap in Java. As always details
go far beyond such simplistic slogans.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
