Hello Christopher, On Mon, Jul 6, 2020, 8:50 PM Christopher Schultz < ch...@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > All, > > Definitely off-topic, but it's the kind of weird thing someone here > might have experience with. > > I have an offline operation I'm considering bringing "inside" my > web-based application. My only concern is memory usage: it requires > that a bunch of data be loaded from a db into memory and then > analyzed. It doesn't take long to execute -- maybe 10 seconds or so, > so the memory can be released back to the rest of the application. > > I've instrumented the command-line process with a thread which runs > every .5sec and captures the used-memory, maintaining a high-water > mark and reporting it after the whole operation is done. The first > time I ran it (with no specific JVM memory-related settings), it > reported that the high-water mark was ~450MiB. > > I figured that was higher than necessary, and probably just > represented a lazy GC with loads of memory, so I constrained the > process using -Xmx64M. That resulted in a 16MiB high-water mark. I > tried again with -Xmx8M and the high-water mark became 5MiB. > > Is there a particularly good way to force the GC to be as aggressive > as possible to see how low I can go, or should I just keep > playing-around with the -Xmx setting. > Looks like you wanted to track live objects generated by your program. I don't recall a JMX metrics of JVM to get that. If someway you can trigger couple of Full GCs during processing and logging everything on a GC log, then you'll get that. So, reducing -Xmx will help after some iterations. One thing you can try using is -Dsun.rmi.dgc.client.gcInterval and server flags and set them to 1 sec. That way you will get Full GC every 1 sec. It worked properly with Parallel GC and doesn't work with G1 in JDK 1.8. You can try and see if serves your purpose. More on that property can be found at https://docs.oracle.com/javase/8/docs/technotes/guides/rmi/sunrmiproperties.html > > Another option is to serialize my in-memory structure to the disk to > get a sense of the size in-memory, though it's really not the same -- > it will at least get me in the right ballpark. > > Any suggestions? > > Thanks, > - -chris > -----BEGIN PGP SIGNATURE----- > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl8DQT8ACgkQHPApP6U8 > pFhvJA/+N8CfjjWvBwkXSpAW6gbozyqgcxx0zt5z9TEbC4viCZNAQchlh0WE1jxF > dQL2NS6138VNOn45QfVLru7jcVQdk6loRSK4Dxe02neAD6sEwe0v3/zsuu7CDu4x > Ln3fwohp+5YNxHAUGc4ssGtw8cilShSSLnJCHwG3mxA+grxg6QvVRVqCxV0b+sCE > ocH0MirON5G7b7zETZohtm5lPcghwDy5SBQ4fVo3mLDjUGR8woGr8SL820pQ3BuY > rjGrJ7SHxq+rVnhOrtX6c4YdEebhjR963385kwPf1ND0GoeCp8Yk/LgySxBRPAbh > 2Kt0UTlbK7wYSDii6kVag1Ayrt5gCyUSrHndvVIl6SdI5gLWfZDbTB3+fvHNg+k5 > x/+Xx/YPvDbXv+b7CtO663uIKV+24iaVq94W+0NVacp3P0YmAmK1CZ9ggs7HQ/SC > uu3R1wRo4yp7eWszhgfpwPHJBvb9Krtfsr8P6rhs5Ry03pzblkmzzTRCvsE85UEZ > 96RN1OGx2YfPEM4+EN9+rxB1hcElLT8V420MAZd9Jx2n8JmJqdZl6DxJ7vgtvKKj > 0Y60VaC211M7tzq2zZ5Sh3th3X2tePPoeJQH/vYrreM4snlM8Mt22eQ7jVFri4bY > F+mu+8DGP3csWmY16nZ0SQ+ZDUS4E9yEplOHq1YKKyHSYGHjn88= > =u12k > -----END PGP SIGNATURE----- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
