This problem known as much time as Niagara processor but still a lot of Java applications suffer from it
Some JVM parameters vary depending on the machine type. For example JVM will set different garbage collectors for different types of machines.
At start JVM detects that Niagara system has a lot of “cpu’s” and so this is a server and if garbage collector is not set it will use parallel gc. And this garbage collector creates a number of gc threads, which is comparable to number of “cpu’s”. ( looks like correct formula for today is : (ncpus <= 8) ? ncpus : 3 + ((ncpus * 5) / 8) ) So you will have really a lot gc threads per JVM at your Niaraga system. And it isn't really a big problem until you use just a few number of JVM's. But if your application use really a lot of JVM's or, for example, you use your Niagara server to consolidate some Java applications this overhead will be significant. Last time I saw this problem at T5440 with just 74 JVM's. And it led to periodical hangs of the whole server. Yes, this is a bug. But there are a lot of Java applications at Niagara servers which use rather old JVM right now. And some of them experiencing performance problems... Solution is really simple. You can set number of gc threads by your hands :
Where 4 will be a good N for most of applications.
This can not only solve performance problems with some apps but also free some servers resources.