|
|
|
|
Back to newsletter 099 contents
I spend increasing amounts of my time profiling inactivity. It's a consequence of modern systems, and it's only going to get worse as systems become ever more multiprocessor multi-core multi-threaded and distributed. Every system I look at now has multiple JVMs each with multiple threads running on multiple multiprocessor multi-core servers, communicating with each other quite a lot. That multiplies to quite a lot of different places where activity can happen. And where activity can be delayed.
For CPU and memory profiling, this multiplication doesn't matter too much. It's pretty simple to identify which threads are using up CPU, and then identify where time is spent. Similarly, memory tracking doesn't usually depend on which thread is running the code, as much as what the code is doing or which objects are holding on to things. But inactivity is a whole new ball game. If things are flowing too slowly, and there are no CPU or memory bottlenecks, then you need to track the flow of activity and find where it is being delayed. But if you are looking at a system with 5,000 threads spread across 20 processes, most of which are in a wait, sleep, or blocked state, it's not an easy task to identify blockages.
What you want, ideally, is for every data packet to be an object which continually records "I'm here ... I'm here now ... now I'm over here doing this ... now I'm leaving this thread ... now I've entered this process ... " and so on. Then you can ask every data packet "how long did you take to get from start to finish, and where did you get delayed. From there, you can usually infer why the packet is getting delayed and fix that.
Alas, not many systems are architected to be able to ask that. And while there are tools that will insert that level of tracking into the system, I'm not usually hired to buy an expensive tool to use to track the system - even though in the long term it would work out cheaper. False economies mean that I end up tooling up systems to be monitored so that they can be diagnosed for inactivity. It's a reflection of the inefficiencies of our industry, and how we make them ourselves one way or another.
But the bigger story is that our complex I.T. systems are just getting more complex and the challenges in keeping them efficient are changing. Are you ready for that? When your system suddenly goes idle for a bit, are you able to say why? If not, it's time to start thinking about how you will find out why.
Now on with this month's newsletter. We have our usual lists of Java performance tools, news, and articles. Javva The Hutt tells us the outcome of Weevil's complaint, at fasterj we have a new cartoon Avoiding long pauses by the garbage collector and, of course, we have extracted tips from all of this month's referenced articles.
Java performance tuning related news.
Java performance tuning related tools.
Back to newsletter 099 contents
