Also, in case the info might help track something down: Its pretty darn odd that both your survivor spaces are full. I've never seen that ever in one of these dumps. Always one is empty. When one is filled, its moved to the other. Then back. And forth. For a certain number of times until its moved into the tenured space. Both being filled like that really seems like a bug to me - I've looked over tons of the dumps in the past (random ones online), and I have never seen one of the survivor spaces not empty.
Mark Miller wrote: > Jonathan Ariel wrote: > >> Ok. After the server ran for more than 12 hours, the time spent on GC >> decreased from 11% to 3,4%, but 5 hours later it crashed. This is the thread >> dump, maybe you can help identify what happened? >> >> > Well thats a tough ;) My guess is its a bug :) > > Your two survivor spaces are filled, so it was likely about to move > objects into the tenured space, which still has plenty of room for them > (barring horrible fragmentation). Any issues with that type of thing > should generate an OOM anyway though. You can find people that have run > into similar issues in the past, but a lot of times unreproducible. > Usually, their bugs are closed and they are told to try a newer JVM. > > Your JVM appears to be quite a few versions back. There have been many > garbage collection bugs fixed in the 7 or so updates since your version, > a good handful of them related to CMS. > > If you can, my best suggestion at the moment is to upgrade to the latest > and see how that fairs. > > If not, you might see if going back to the throughput collector and > turning on the parallel tenured space collector might meet your needs > instead. You can work with other params to get that going better if you > have to as well. > > Also, adjusting other settings with the low pause collector might > trigger something to side step the bug. Not a great option there though ;) > > How many unique fields are you sorting/faceting on? It must be a lot if > you need 10 gig for 8 million documents. Its kind of rough to have to > work at such a close limit to your total heap available as a min mem > requirement. > > -- - Mark http://www.lucidimagination.com
