Quick-tip!
You know you don’t know what’s really going on whentop shows you just a bunch of “java” processes like this:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2898 jboss 20 0 3103m 84m 5704 S 0.7 4.5 0:37.83 java 3978 jboss 20 0 3147m 387m 4640 S 0.7 20.6 0:44.26 java 6589 jboss 20 0 3117m 350m 18m S 0.7 18.7 0:19.42 java 3255 jboss 20 0 3103m 96m 5704 S 0.3 5.2 0:36.44 java 3614 jboss 20 0 3103m 258m 5704 S 0.3 13.8 0:36.65 java 4336 jboss 20 0 3640m 422m 5908 S 0.3 22.5 0:39.78 java
As seen above, we run six java services (JBoss instances) on one machine. If one “misbehaves” (uses lots of cpu, ..), it is hard to deduce which service it is. Luckily, there is an option to fix this.
Create symlinks to the actual java binary, for instance:
ln -s /usr/bin/java /home/jboss/service-a
ln -s /usr/bin/java /home/jboss/service-b
etc..
Then export the JAVA environment variable before starting each service:
export JAVA=/home/jboss/service-a
Then start the jboss/wildfly instance using standalone.sh
Now look at top again:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 7624 jboss 20 0 3116m 142m 5792 S 0.7 7.6 0:17.38 service-a 8747 jboss 20 0 3103m 309m 5744 S 0.7 16.5 0:14.53 service-d 9471 jboss 20 0 3647m 301m 7108 S 0.7 16.1 0:16.46 service-f 8030 jboss 20 0 3103m 205m 5744 S 0.3 11.0 0:14.09 service-b 8388 jboss 20 0 3103m 304m 5736 S 0.3 16.2 0:14.30 service-c 9110 jboss 20 0 3103m 383m 5744 S 0.3 20.4 0:19.91 service-e
Every service has its own process name in top!
So far, I have not discovered any drawback for this solution.
