> Perhaps I'm not reading the GC logging information correctly, but it didn't > appear to me that the GC was to blame for the pauses. Perhaps it might not > even be the JVM but the OS kernel? Until I have a good idea what's causing > them, it seems that throwing solutions (such as moving to a realtime VM) is > just stabbing at the dark.
>From your GC logs it doesn't look like GC is the problem no so for now the point is moot. However, if you are targeting 10 ms pause times you may or may not at some point have a problem. For very small heap sizes and moderate allocation rates it'll probably work okay. Once you start having larger heap sizes or lots of allocation, it becomes more difficult. Depending on your application, it may or may not be an issue. Just be aware that there is no expectation that CMS will *guarantee* you 10 ms pause times. Same for G1 (or JRockit for that matter). As for discovering the real cause of the pause: Without obvious culprits I would probably just do a "binary search" of source, in terms of the call stack. Keeping doing the timings at different places and see where you're not seeing the pauses and where you are seeing them, and drill down. Another option, depending on how fast 'jstack' is in relation to your pauses, is to try to get a 'jstack' on the process while you're seeing a pause and see if there is a thread blocking in an unexpected location. That's assuming there is something blocking for an extended period of time that is causing it. -- / Peter Schuller -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
