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?

2 comments
Comment actions Permalink

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)

0
Comment actions Permalink

What is your OS and TC version? Also, please attach several thread dumps

0

Please sign in to leave a comment.