Java is scary

Submitted by gwolf on Thu, 11/11/2004 - 13:21
A friend asked me to become the sysadmin for his machine - Great. A crappy Fedora Core 2 system, terribly installed (it has EVERYTHING in there, three MTAs, the whole X environment...). I have been cleaning up the mess, but decided to debootstrap Debian instead. Now, the system configuration the ISP gave them is even crappier that the Fedora install they made - a dual Xeon at 2.8 with 128MB RAM?! Now, my friend complained that JBoss was running too slow. Ok, I had a 0.00, 0.00, 0.27 loadavg - Memory was quite fine, using only about 10% of the 1GB swap. I launched top... and instantly I had a 300MB Java monster (which in few seconds grew up to 400MB). It gobbled up to 70% of the running memory (at least parts of it could be nicely swapped). The top running process was, of course, kswapd. I ask him, what is JBoss doing? Nothing yet, he says. Shit. Java sucks, no matter what they say. :-/
( categories: )
James Stansell's picture

RE: Java is scary

Java in general requires more memory than even Perl does, but unlike Perl, Java can be given a maximum amount to use. JBoss can be run in a minimal mode that should work OK even on that small of a box. If you need to run a full-blown JBoss you probably will need a bigger server. BTW, you didn't mention what version (or vendor) of Java you were using. Regards, -james.
Matthew Good's picture

RE: Java is scary

Yeah, Java is generally a memory hog, but I put some of the blame on JBoss bloat. If you can just stick to Tomcat you'll probably be better off. We have some stuff developed using JBoss at work and it really slows down my testing cycle due to enormous startup and reload times. I should probably take some time to experiment with the minimal config as I don't really need any of the JBoss services besides Tomcat and a datasource. In default mode though, JBoss can take over a minute to start up and deploy my app, while in Tomcat it can load in under 10 seconds and times to redeploy are very small. Of course the other thing I like about running Tomcat on its own is the Manager and Admin webapps it includes for deploying webapps and managing the server configuration.
James Stansell's picture

RE: Java is scary

If you think JBoss start-up time is slow, you ought to see the closed-source J2EE servers! If Tomcat does everything you need, that's great. But I'd suggest also testing with Jetty, as 1) Jetty is generally considered superior to Tomcat; and 2) testing on more than one server can help you find bugs you didn't even know you had.
vicm3's picture

RE: Java is scary

Well i think i at some time talk about the origin of project "mundito" of our "cabras locas" group... well it was Morango's work, let me tell you about a celullar automata... pretty nice... writen on java... he asked for an account on our Ultra 450 (Ultra Sparc 450x4 4GB RAM, 120GB 4x40scsi,etc.), well for short one day came to my place on office, saying "what are you doing?, the performance is really bad!, and the machine keeps telling me out of memory", surprised (as this machine had an 2GB swap!) enter the system, can't run top, but doing a free, really, this is no more memory left... a rapid ps auxf and a lot of java so goes the question "how many instances of tour program are you running?" "only four i was going to launch a five one"... well 340 and some defunct don't check with 4... so a rapid kill to defunct ones begin freeing memory... bettermore killall java... it happens that our friend had have no worry to write on his beatiful code what to do if no conected with the other instances (lost connection) or simply if finished (rather than write result to disk)... so we had a production machine... crawling, because a "litte" pet project... not to mention what was say when the killall made effect (or when the other sysadmin on weekend took all his process to death and close is account!)... talking of scary ones... (also know on a "production" application that has a memory leak and need to be restarted every day as for to this day there is not a real fix... j2ee in this case...) Regards