Java Performance Tuning

Java(TM) - see bottom of page

|home |services |training |newsletter |tuning tips |tool reports |articles |resources |about us |site map |contact us |
Tools: | GC log analysers| Multi-tenancy tools| Books| SizeOf| Thread analysers|

Our valued sponsors who help make this site possible
New Relic: Try free w/ production profiling and get a free shirt! 

Site24x7: Java Method-Level Tracing into Transactions @ $12/Month/JVM. Sign Up! 

Javva The Hutt August 2007

jKool for DevOps
Light up your Apps & get a cool t-shirt

JProfiler
Get rid of your performance problems and memory leaks!


Java Performance Training Courses
COURSES AVAILABLE NOW. We can provide training courses to handle all your Java performance needs

Java Performance Tuning, 2nd ed
The classic and most comprehensive book on tuning Java

Java Performance Tuning Newsletter
Your source of Java performance news. Subscribe now!
Enter email:


New Relic
New Relic: Try free w/ production profiling and get a free shirt!

Site24x7
Site24x7: Java Method-Level Tracing into Transactions @ $12/Month/JVM. Sign Up!


jKool for DevOps
Light up your Apps & get a cool t-shirt

JProfiler
Get rid of your performance problems and memory leaks!


Back to newsletter 081 contents | All Javva's articles

Threads, Threads, Threads Everywhere

I recently read Heinz Kabutz's The Law of the Distracted Spearfisherman. The basic piece of advice is "know what your threads are doing". So I decided to follow Heinz's advice on our main system. It's several years into deployment, and threads are everywhere. With dozens of different types of Java processes, I decided to start on the most important components. It has over 500 threads and it is a pain to work out what even half of them are doing. So I wrote something that parsed them all, and tried to categorize them.

My week consisted of asking one developer after another pretty much the same things. The conversations would go like this:

Basically either threads were being spawned unnecessarily, or they weren't cleaned up properly, or they were sitting there as part of a pool. Now the real kicker for me was the analysis showed IT DIDN'T MATTER. Yes, despite many Java processes each with many idle threads sitting around, the OS didn't really care. Sure it was having to do some extra scheduling and context switching - but all the processes were coming in under the SLAs. So I had a most uncomfortable conversation with the project manager which went something like this:

So that was the upshot of quite a bit of work. We have too many threads. Lots of them are useless. And it doesn't really matter - at the moment anyway. Nevertheless I agree with Heinz, it's good to know what the threads are doing, and I expect this analysis will come in useful in the future when there are problems - and I'll be able to do the same analysis much more quickly.

Javva The Hutt.


Back to newsletter 081 contents


Last Updated: 2017-05-01
Copyright © 2000-2017 Fasterj.com. All Rights Reserved.
All trademarks and registered trademarks appearing on JavaPerformanceTuning.com are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries. JavaPerformanceTuning.com is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
URL: http://www.JavaPerformanceTuning.com/news/javvathehutt081.shtml
RSS Feed: http://www.JavaPerformanceTuning.com/newsletters.rss
Trouble with this page? Please contact us