[JIRA] [core] (JENKINS-10401) jenkins using 100% CPU if trying to archive unexisting artifact

Sat, 31 May 2014 12:46:06 -0700

Lloyd Chang commented on Bug JENKINS-10401

Hi Daniel and Fabrice,

Intuitively and from experience, I feel and think described problem isn't specifically in core Jenkins codebase, but in configurations of

  • web server and servlet
  • Java virtual machine version and heap and garbage collection
  • sysctl and ulimit in Linux operating system
  • architecture of operating system: 32 or 64-bit
  • disk I/O speeds: 5400, 7200, 10000, 15000 rpm HD or SSD with faster speeds
  • multi-threading and total number of CPU(s) available

Fabrice, if you're still seeing the problem as described with current Jenkins version on your Linux systems, then I suggest looking outside of the Jenkins codebase. Earlier, you wrote, "(I did actually never see any linux version not having this problem)"

Since this issue was first created in 2011, since then, computing prices and operating system releases have changed. Per Moore's Law of computing hardware, I suggest that you consider faster hardware, a 64-bit operating system (instead of 32-bit). Linux wise: If you're using Debian, 6.0 squeeze has been superseded by 7.0 wheezy. As for Java, consider using Oracle 1.7 JDK -server with HotSpot VM using -XX:+AggressiveOpts because its performance has been tuned more aggressively when compared to Open JDK defaults. Also, consider Java VM garbage collection parameters -XX:+UseConcMarkSweepGC -XX:+UseParNewGC

Generically speaking, a 100% CPU spike for 1 or more CPU seems like Java garbage collection might be happening due to hundreds of thousands of files being opened and processed and using up Java heap memory (-Xmx). Adding to the complexity: If the system environment only has 1 out of 1 total CPUs being used by other threads, then Jenkins application main thread will seem slow. Specifically, here are configurations in Linux and Java to look for and tune the performance on your system(s).

Linux

  • /etc/security/limits.conf
  • /etc/sysctl.conf

Java

Debugging and profiling wise, if you see the 100% CPU issue, you could run:

  • jps for Java process IDs
  • jstack for a Java stacktrace of the threads, and see if garbage collection (gc) threads are running during high CPU usage
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira

--
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to