Team city using 50% of a CPU night and day.
Most of the time team city is not running build, but all the time it is using around 50% of a CPU. How can I diagnose this to find out why? Is this normal? Can it be reduced?
Please sign in to leave a comment.
By taking repeated stack traces I see this stack race repeatedly (for each of the 6 repos we have)
"TC: 18:42:55 getCurrentState: "ThreadAffinity" {instance id=112, parent internal id=3, parent id=OpenHft_ThreadAffinity, description: "git@github.com:OpenHFT/Java-Thread-Affinity.git#refs/heads/master"}; 18:42:55 Loading VCS changes for "ThreadAffinity" {instance id=112, parent internal id=3, parent id=OpenHft_ThreadAffinity, description: "git@github.com:OpenHFT/Java-Thread-Affinity.git#refs/heads/master"}; 18:42:55 Task started; VCS Periodical executor 10835" prio=10 tid=0x00007f9488001000 nid=0x3d2f waiting on condition [0x00007f9487af8000]
java.lang.Thread.State: TIMED_WAITING (sleeping)
at java.lang.Thread.sleep(Native Method)
at jetbrains.buildServer.buildTriggers.vcs.git.GitVcsSupport.getRemoteRefs(GitVcsSupport.java:375)
at jetbrains.buildServer.buildTriggers.vcs.git.GitVcsSupport.getRemoteRefs(GitVcsSupport.java:336)
at jetbrains.buildServer.buildTriggers.vcs.git.GitVcsSupport.getCurrentState(GitVcsSupport.java:129)
at jetbrains.buildServer.buildTriggers.vcs.git.GitVcsSupport.getCurrentState(GitVcsSupport.java:121)
at jetbrains.buildServer.buildTriggers.vcs.git.GitCollectChangesPolicy.getCurrentState(GitCollectChangesPolicy.java:98)
at jetbrains.vcs.api.services.impl.RepositoryStateServiceProvider$1.getCurrentState(RepositoryStateServiceProvider.java:6)
at jetbrains.buildServer.vcs.impl.VcsRootInstanceImpl.getCurrentState(VcsRootInstanceImpl.java:117)
at jetbrains.buildServer.vcs.impl.VcsChangesStatesCollector.getCurrentState(VcsChangesStatesCollector.java:12)
at jetbrains.buildServer.vcs.impl.VcsChangesStatesCollector.access$100(VcsChangesStatesCollector.java:31)
at jetbrains.buildServer.vcs.impl.VcsChangesStatesCollector$2.run(VcsChangesStatesCollector.java:0)
at jetbrains.buildServer.util.NamedThreadFactory.executeWithNewThreadName(NamedThreadFactory.java:102)
at jetbrains.buildServer.vcs.impl.VcsChangesStatesCollector.doCollectStates(VcsChangesStatesCollector.java:22)
at jetbrains.buildServer.vcs.impl.VcsChangesStatesCollector.collectStatesForAllRoots(VcsChangesStatesCollector.java:17)
at jetbrains.buildServer.vcs.impl.VcsChangesInterval.getLoadChangesIntervals(VcsChangesInterval.java:37)
at jetbrains.buildServer.vcs.impl.VcsChangesFetcher.loadChangesNoLocking(VcsChangesFetcher.java:33)
at jetbrains.buildServer.vcs.impl.VcsChangesSyncFetcher.loadChangesNoLocking(VcsChangesSyncFetcher.java:28)
at jetbrains.buildServer.vcs.impl.VcsChangesLoaderImpl.tryLoadChanges(VcsChangesLoaderImpl.java:33)
at jetbrains.buildServer.serverSide.impl.VcsModificationChecker$1$1.run(VcsModificationChecker.java:1)
at jetbrains.buildServer.util.NamedThreadFactory.executeWithNewThreadName(NamedThreadFactory.java:102)
at jetbrains.buildServer.serverSide.impl.VcsModificationChecker$1.run(VcsModificationChecker.java:2)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
What is your OS and TC version? Also, please attach several thread dumps