-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Suvendu,
On 1/5/18 6:46 AM, Suvendu Sekhar Mondal wrote: > I really never found any explanation behind this "initial=max" heap > size theory until I saw your mail; although I see this type of > configuration in most of the places. It will be awesome if you can > tell more about benefits of this configuration. It's really just about saving the time it takes to resize the heap. Because the JVM will never shrink the heap (at least not in any JVMs I'm familiar with), a long-running server-side process will (likely) eventually use all of the heap you allow it to use. Basically, memory exists to be used, so why not use all of it immediately? > I usually do not set initial and max heap size to same value > because garbage collection is delayed until the heap is full. The heap is divided into sections. The first heap to be GC'd after JVM launch is likely to be the eden space which is relatively small, and few objects will survive the GC operation (lots of temporary String objects, etc. will die without being tenured). The only spaces that take a "long" time to clean are the tenured generation and the (until recently named/replaced) permanent generation (which isn't actually permanent). Cleaning those spaces is long, but a GC to clean those spaces should not happen for a long time after the JVM starts. Also, most collector algorithms/strategies have two separate types of operation: a short/minor GC and a long/full GC. As long as short/minor GC operations take place regularly, you should not experience application-pauses while the heap is reorganized. Finally, application pauses are likely to be long if the entire heap must be re-sized because then *everything* must be re-located. > Therefore, the first time that the GC runs, the process can take > longer. Also, the heap is more likely to be fragmented and require > a heap compaction. To avoid that, till now my strategy is to: - > Start application with the minimum heap size that application > requires - When the GC starts up, it runs frequently and > efficiently because the heap is small I think this is a reasonable expectation for someone who doesn't understand the Black Art of Garbage Collection, but I'm not sure it's actually true. I'm not claiming that I know any better than you do, but I suspect that the collector takes its parameters very seriously, and when you introduce artificial constraints (such as a smaller minimum heap size), the GC will attempt to respect those constraints. The reality is that those constraints are completely unnecessary; you have only imposed them because you think you know better than the GC algorithm. > - When the heap is full of live objects, the GC compacts the heap. > If sufficient garbage is still not recovered or any of the other > conditions for heap expansion are met, the GC expands the heap. > > Another thing, what if I know the server load varies a lot(from 10s > in night time to 10000s during day time) during different time > frame, does "initial=max heap" apply for that situation also? My position is that initial==heap is always the right recipe for a server-side JVM, regardless of the load profile. Setting initial < max may even cause an OOM at the OS level in the future if the memory is over-committed (or, rather, WILL BE over-committed if/when the heap must expand). - -chris -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQJRBAEBCAA7FiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlpTi1MdHGNocmlzQGNo cmlzdG9waGVyc2NodWx0ei5uZXQACgkQHPApP6U8pFjidA/+J6TwZ7KA3IOvzyx/ dPRX0QDF91DJRcSNiw1m2WnyBIzSsYD3Q16I5Y2A/6Lp5b5a6Sgr8Ru+hVYlFpms 8mAgm1M438DiE4oyPCleJfW95ias/h5O0mlsj5sbWs6LsACuy4jJp11ejMfMYrPf SOzFQmD9ZNDRD4XzmYySliu7duyo0QLV1pNRZ92v1GFqowtO9bWoLTTyp/QoqgJL gwiMUdykMfqdsH7j2/U7z1Y9sS91p2NnxBWVr+i8aI9QhWAaqP8Hzf8K47rCN1NG zAFB/N7xwcUkK8M+3GhoReGJtIrhqjEGBjOCrkuVrdL3mWblZdUDDo/0SH3GtvuR osISeTmmSfN3xQng8NQI0s6uKlG+bzAaJUffF2iP61AIRF33DJKte04n8ECGm1Ct UF4HFEtZDL5Qb28sqrwR1HdpqkXb4FwPw/NTEfJCWVQzWwnEcekDUbYWQMVwCDMC hbXNSwXTGalykDJIMjIqtV3yw6THUbT8GeUSC31/vADQLC2W8r3z1R1CVwdArfiy zmBHe/pUw4ZZvnEuLdoIMUp7sARLUVIqSIMPWkXFbkOgNt7g5fAOd5lA0JUe1hJn Wpgm62Pz836+ywIx0+e7QMZJorn3H54ayZvYTOWX19TWQ+gXiHmD56wXAnaaBg9N 40Fpa/phyOZ3zUvcj3g+nCeN8u4= =ee4n -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
