Understanding java app CPU usage under Linux

[Chuck Bearden]

I'm fairly new to Java. I have several long-running instances of UIMA
[1] running on a Linux server. Together they peg all four CPUs, but I
notice that there is a much higher proportion of system load to user
load than I am accustomed to seeing with CPU-intensive applications.
Is this typical for Java apps (perhaps much of the overhead of the JVM
appears as system CPU usage)? Both PostgreSQL and an NLP concept
extractor are part of the app, but I haven't noticed this behavior
with them when I run them apart from Java.

Seems like an elementary question, but I haven't found a clear answer
so far. Thanks in advance for any information,
Chuck

[1] <http://uima.apache.org/>

 

[Tom Anderson]

I'm fairly new to Java. I have several long-running instances of UIMA
[1] running on a Linux server. Together they peg all four CPUs, but I
notice that there is a much higher proportion of system load to user
load than I am accustomed to seeing with CPU-intensive applications. Is
this typical for Java apps (perhaps much of the overhead of the JVM
appears as system CPU usage)?

I don't think so. When the java processes i work with peg the CPUs, it's
almost all user time. That's from both application-level overload (eg the
code is chasing round vast pointer structures for obscure reasons) and
more virtual-machineys stuff (thrashing in garbage collection).

Maybe time for some strace?

tom

 

[Chuck Bearden]

I'm fairly new to Java.  I have several long-running instances of UIMA
[1] running on a Linux server.  Together they peg all four CPUs, but I
notice that there is a much higher proportion of system load to user
load than I am accustomed to seeing with CPU-intensive applications. Is
this typical for Java apps (perhaps much of the overhead of the JVM
appears as system CPU usage)?

I don't think so. When the java processes i work with peg the CPUs, it's
almost all user time. That's from both application-level overload (eg the
code is chasing round vast pointer structures for obscure reasons) and
more virtual-machineys stuff (thrashing in garbage collection).

Maybe time for some strace?

I ran the pipeline for several minutes with strace -c -f strace.out,
and the aggregated system time results for the 64-bit mode showed 94%
of the time spent in futex. The top 5 in 64-bit mode were:

94.01 4145.689579 60053 69034 10805 futex
3.50 154.438827 9427 16382 8176 wait4
2.47 108.887005 8862 12287 clone
0.02 0.691896 8 83191 read
0.00 0.065482 2 37288 sched_yield

In 32-bit mode:

65.47 277.727778 277727778 1 restart_syscall
23.73 100.662130 13324 7555 5908 getegid32
10.72 45.467978 22554 2016 chroot
0.03 0.120708 0 1613645 pread64
0.02 0.091825 1 182737 read

Does the the 94% in futex look suspicious to the Java or system hands?

For the record, the system I am working on shows the following from
lsb_release -a

LSB Version: :core-3.1-amd64:core-3.1-ia32:core-3.1-
noarch:graphics-3.1-amd64:graphics-3.1-ia32:graphics-3.1-noarch
Distributor ID: CentOS
Description: CentOS release 5.4 (Final)
Release: 5.4
Codename: Final

The JDK is java-1.6.0-openjdk-1.6.0.0.x86_64. The concept extractor
(MetaMap) is a 32-bit app.

Chuck