-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Chuck,
On 8/2/18 1:52 PM, Caldarale, Charles R wrote: >> From: James H. H. Lampert [mailto:jam...@touchtonecorp.com] >> Subject: Problem with CATALINA_OPTS in setenv.sh > >> I've been experimenting with some CATALINA_OPTS changes, as >> recommended by our webapp developer, and one of them is causing >> Tomcat to "crash on takeoff" with stacktraces like this: >>> 30-Jul-2018 22:58:00.708 SEVERE [main] > org.apache.coyote.AbstractProtocol.init >>> Failed to initialize end point associated with ProtocolHandler > ["http-nio-80"] >>> java.net.SocketException: Cannot allocate memory > >> We're running on a Google Compute instance, with 1 CPU and 4G of >> memory, > >> What the webapp developer asked for was (after I'd vetted his >> request against the Java 8 docs) >>> -Xms2048m -Xmx2048m -XX:+ScavengeBeforeFullGC >>> -XX:+AlwaysPreTouch -XX:+CMSScavengeBeforeRemark >>> -XX:+CMSClassUnloadingEnabled -XX:+UseConcMarkSweepGC >>> -XX:+CMSPermGenSweepingEnabled > >> which produced the crash-on-takeoff, and I was able to narrow it >> down to specifically the "-XX:+AlwaysPreTouch" that was doing >> it. > >> Anybody have any insights into why that parameter would cause >> Tomcat to crash on takeoff? > > A bit of research shows that +AlwaysPreTouch seems like a really, > really bad idea for anything but small, bare-metal, dedicated > systems, and especially useless on a VM: > > "With the -XX:+AlwaysPreTouch option the JVM touches every single > byte of the max heap size with a '0', resulting in the memory being > allocated in the physical memory in addition to being reserved in > the internal data structure (virtual memory). Pretouching is single > threaded, so it is expected behavior that it causes JVM startup to > be delayed. The trade off is that it will reduce page access time > later, as the pages will already be loaded into memory." Sounds like garbage to me. The OS isn't going to keep pages in RAM just because they are zeroed. Also, unless the JVM does it exactly correctly (which it probably *is* doing), the zeroing-operation might actually be a no-op. The most likely result from using AlwaysPreTouch is that you get more memory pressure and therefore more swapping to virtual memory. I can't really see a use-case for this option. I'm guessing your dev requested this because #security or #sawitonstackoverflow. Given that it crashes your JVM, I'd say you have a decent argument for NOT using this option even if it fails the sniff test for other reasons. > The fact that Tomcat is crashing during the pre-touch would > indicate that you can't actually use a 2 GiB heap on a supposed 4 > GiB VM - something other than the heap is eating up a lot of space. > You should probably remove the option and reduce the heap size. But the process isn't failing on pre-touch. It's failing when it's trying to bind a socket to a port. - -chris -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAltjWTQACgkQHPApP6U8 pFgRlBAAl6yo/nyrV7NnaCXMz34b+6OLqpPjTiR5Rm06YoGuoZD5CDpiDgwMR59O qJmKn6545gtF/CjbjOLdtJCeHH+hMzEKy2JcEfBIkc0pen5jK+AQmFVMl7xpfx+/ qjD08IWALpqAuKTPEZQNUVCAOIVPjOdLuk9wsOXtyTa8TBAoy50nVk9h+O72+Zpr z25ynggKA/wDzs49NoHaN0x8o8+Y40IJr02dQ9O4QGh+Jt3OT7QxJMDuu7OvFNko E/Y8PsUeiENSGxVtprw7HbBYhLYQJ8aD3fCk9munDlnyzWhf5ASy5nnRncQfhMsP XyI8pJKvV+qZNveBIj4jBwO81vjRzUGyUeYwmSPmZq6dFU4ZhNktFEi/iCTy2seb S36rvGQg16/ekBZtNhqJDdIbeImbjggVK8dwPTqv5FoMx1w8XQB57vh1ROhPo7u2 9esbImd262rdQuE9feAfrY6hi0t9iU40rrCzFntvFm+TpcNyouOgXX7fFIXnVWz8 oGRRYOGFOreSLHjHLn4Nptl220o0Ux8n1iZ7mZDMJSPueidov95YExrYFKawUxwc kZJi/gEfZfcd3YpxLcH3O6I2vTJmvGPYgIIBIfBR0gSqgGhN9ad87rVoEqM+AE8D TCsdOSDS7A+PqU50Efwqspp1Xae9z2SXSg5e66kGjKQiJ0oua6A= =Nn19 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
