TeamCity 8.1.2 on OSX - consuming a lot of CPU while idle
I have a barebones TeamCity 8.1.2 installation on my MacbookPro (OSX 10.9.2 Java 1.6 / 1.7), it's functioning as the server + agent. I setup 1 project with 1 build (bash script) using Github (no commit hooks though) to do Unity3d command line builds.
After I configured my project & build steps I noticed that the java process from teamcity was using 50-70% CPU while idling. I did some googling and nothing came up so I decided to post here.
start command output:
Taylors-MacBook-Pro:TeamCity taylor$ ./bin/runAll.sh start
Using CATALINA_BASE: /Applications/TeamCity
Using CATALINA_HOME: /Applications/TeamCity
Using CATALINA_TMPDIR: /Applications/TeamCity/temp
Using JRE_HOME: /System/Library/Frameworks/JavaVM.framework/Home
Using CLASSPATH: /Applications/TeamCity/bin/bootstrap.jar:/Applications/TeamCity/bin/tomcat-juli.jar
Starting TeamCity build agent...
Java executable is found in '/System/Library/Frameworks/JavaVM.framework/Home'.
Starting TeamCity Build Agent Launcher...
Agent home directory is /Applications/TeamCity/buildAgent
Current Java runtime version is 1.7
Lock file: /Applications/TeamCity/buildAgent/logs/buildAgent.properties.lock
Using no lock
Done [81064], see log at /Applications/TeamCity/buildAgent/logs/teamcity-agent.log
this is the process that is using the cpu:
501 81052 1 0 1:51PM ttys003 1:56.88 /System/Library/Frameworks/JavaVM.framework/Home/bin/java -Djava.util.logging.config.file=/Applications/TeamCity/conf/logging.properties -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -server -Xmx512m -XX:MaxPermSize=270m -Dlog4j.configuration=file:/Applications/TeamCity/bin/../conf/teamcity-server-log4j.xml -Dteamcity_logs=../logs/ -Djava.awt.headless=true -Djava.endorsed.dirs=/Applications/TeamCity/endorsed -classpath /Applications/TeamCity/bin/bootstrap.jar:/Applications/TeamCity/bin/tomcat-juli.jar -Dcatalina.base=/Applications/TeamCity -Dcatalina.home=/Applications/TeamCity -Djava.io.tmpdir=/Applications/TeamCity/temp org.apache.catalina.startup.Bootstrap start
the start and stop logs from /Applications/TeamCity/buildAgent/logs/* and /Applications/TeamCity/logs/*
https://gist.github.com/tayl0r/11398005
I'm assuming this is not supposed to happen. Any ideas what it might be? How can I debug this further?
I tried switching my JRE_HOME to java 1.7 (from java 1.6) but there was no change.
I'm a programmer but have never done anything with Java so I don't quite know where to start debugging this. The misbehaving process seems to be Tomcat, which I know is the java application server, but I don't know how to dig deeper.
Please sign in to leave a comment.
Please attach thread dump (Administration->Diagnostics)
Attached.
Attachment(s):
threadDump-2014-04-29_19.08.22.txt.zip
According to thread dump, TC is idle. However, it takes time for TC to start and load all dependencies, etc (like 1-2 minutes). How long did it work before you stopped it?
I wait 10+ minutes because I assumed it did some stuff at startup.
http://screencast.com/t/Faa7FvAa4z
It's definitely doing *something*. With TC running, OSX says I have 3 hours 10 minutes battery life remaining. When I stop TC, the battery life jumps to 4 hours. The CPU temps also go up while TC is running. So it must be doing something!
As far as I can see, one thread is really doing something. Please do the following:
1) Enable debug-all logging under Administration-Diagnostics and let it work for couple of minutes after server is completely started. And then send the whole log folder (zipped) to us.
2) Do several thread dumps (via save thread dump) with interval of 10-15 seconds.
Please don't forget to turn off debug logging after that - otherwise it will flood the log.
Thanks!
Thanks a lot for your help btw. Here you go!
Attachment(s):
buildAgent_logs.zip
teamCity_logs.zip
I suspect there's something with system thread "AWT-AppKit", but I need to be sure.
Can you please do the following:
1) Start TC and let it run for a couple of minutes
2) clone https://github.com/silvansky/threadmon and compile it via make
3) sudo ./threadmon <tc_pid>
// this will print cpu usage per thread.
4) jstack <tc_pid> >> td_java.txt
// this will give us real thread PIDs, not TC fake ones.
Also, did all these problems happen, when TC installation was clean (i.e. no projects, etc.)?
Unfortunately I can't answer that question. I only noticed the CPU usage after I added the project. Can I "archive" and then delete the project to test this?
I looked at the threadmon & jstack output but I can't make sense of it. The threadmon thread ids dont seem to match anything from jstack. Supposedly the "nid" field should be the hex encoded thread id, but those don't seem to match anything from threadmon.
Here's the output:
Attachment(s):
td_java.txt.zip
It turns out, there's no direct matching between tid and nid generated by jstack and OS pids and tids. This is sad. Let me find a way to get these TIDs.
That was my conclusion as well after doing some googling. I guess on linux you can match it up but not OSX.
I was unable to find an easier way rather than asking you to run a profiler. Luckily, it comes with JDK and called jvisualvm. Please start it, attach to TC process and go to Sampler tab.
Then, please, click on CPU button and let it grab some information. There are two tabs - CPU samples (methods) and Thread CPU time. I would need information from both. I haven't found a way to dump the information to txt file, so screenshots would be enough
Thanks!
No problem. Here are the screenshots. It seems like it's the "Agent messages processing threads". Maybe they're just tuned too aggressively for non-production applications.
Attachment(s):
visualvm-sampler-cpu_samples.png
visualvm-sampler-thread_cpu_time.png
Thanks. Please try replacing TC/webapps/ROOT/WEB-INF/lib/server.jar with the one from the link: ftp://ftp.labs.intellij.net/pub/.teamcity/mac-cpu-try/server.jar and let me if it changes anything.
Wow, looks like that fixed it. Now's its using about the same amount of CPU as a normal running & idle app.
Thank you for your help on the issue. That was a useful knowledge for us.
By the way, it's not the final fix, but a workaround and try to understand the problem (for us). Most likely, the final fix would be included into 8.1.3.
Understood. I'll be happy to try out new server jar files or give you additional debug info if you want.
Thanks again! Jetbrains is the best! Now if you guys would make a proper C# editor that worked with Unity =)