It's things like this that gives Java such a low reputation in some operational areas.
This is how the 'real world' should work: System monitoring software watches memory usage on a process / machine. It alerts operational staff when it moved beyond acceptable bounds Investigation starts - action is taken - and the app stays up. As RAM usage goes up and we move to virtual memory/swap you'll find that the machine may become very slow as it spends most of its time paging, but it stays up. With a hard limit on Heap size, instead, my app / app server hits a limit and dies in some creative an unusual manner. We can all say 'oh, you should know how much memory your app uses' etc etc... but that's just like saying we could eliminate the road toll by all driving safely, despite best intentions this isn't always possible or even likely. A case this week at work, two Microstrategy developers are running a report which crashes with an Out of Memory exception on a the Java VM. They say 'oh, we need to reboot the server' and 'We should move to a 64bit server' They are using a Java based product but aren't Java developers, they have no idea there even is a Java VM - on investigation the embedded Java VM is set to have a 256M heap size! Yes, you can bitch and moan about it, but this is how the real world works. On Jan 1, 5:45 am, "Matthew Beldyk" <[email protected]> wrote: > My impression was that a fixed size of the heap was designed to keep > the program from using all the ram on the machine. Personally, I'd > rather have a single program crash than have an entire machine come to > it's knees (I no longer have any machines running a single application > unless they are running some low level embedded operation, and that's > a completely different beast). > > I will admit, 64M is a little on the low side for modern desktop > applications (this from a guy with 8 gigs or ram on his workstation, > so take that statement with a grain of salt). But 64M is actually on > the large side some embedded systems. I'm going to guess that 64M was > decided upon as a good place to start; I imagine it would cover most > usual programs. > > Configuring the maximum heap size is also fairly trivial (the -Xms and > -Xmx flags, I believe). And having a ballpark idea how much ram your > program should use should be a basic benchmarking test before you put > something into production (I've been guilty of missing that test > before and won't make that mistake again). > > All this being said, I have been burnt by this with tomcat before when > we forgot to configure this correctly and ended up with some very > strange behaviors (suddenly some of our applications could no longer > find libraries that tomcat was dropping out of the heap; I don't know > the exact details as I was on vacation that week and this is all > hearsay). > > In my opinion, the fixed max heap size is a required annoyance. > Unless I were better able to manually manage memory usage in java, I'm > disinclined to allow program's ram usage to grow unchecked. > > -Matt > > On Wed, Dec 31, 2008 at 10:54 AM, [email protected] > > <[email protected]> wrote: > > > I've never understood why sun chose to have a "max heap size" setting > > and default it to 64 megs. To figure out what your max heap size > > should be you pretty much have to use trial and error. This makes > > java inherently unstable. I can't count the # of times I've had > > processes crash with an OutOfMemoryException because the heap size is > > set either to the default 64 meg or too low. > > > Why not do what every other runtime does and just allocate memory as > > needed? And what exactly does the max heap size setting do anyway? > > -- > Calvin: Know what I pray for? > Hobbes: What? > Calvin: The strength to change what I can, the inability to accept > what I can't, and the incapacity to tell the difference. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
