Sourcetree 2.7 (144): High CPU load on Mac OS High Sierra 10.13.2

Viewing page 2 of 2

43 answers

Comments for this post are closed

Community moderators have prevented the ability to post new answers.

Post a new question

2 votes
Ling Li
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
February 19, 2018

I have the same issue on my Mac OS X El Capitan / 10.11.4, with SourceTree 2.7(152). I've downgraded to 2.6.3(134) and the cpu usage drops back down. 

2 votes
Pavlo Kapynos
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
January 22, 2018

I have the same problem. Over 100% CPU Time. I have to Kill the Process all the time. Version 2.7 (152). MAC OS X El Capital 2.5 GHz Intel Core i7, 16GB DDR3

2 votes
smartcat
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
December 27, 2017

Also noticed about high CPU usage. To fix this temporary need restart sourcetree.

Process `/usr/libexec/nsurlstoraged` taking too many cpu time, after that Source tree may crash.

2 votes
bgannin
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
December 11, 2017

We've had a couple reports about this and will investigate shortly. Thanks for the info.

Brian Ganninger
Senior Mac Developer, Sourcetree

Warrick Bayman January 4, 2018

Also experiencing this, but only when the interface is visible. If Sourcetree is running, but no windows are open, then it will eventually lower it's CPU usage. But open the main window, and back up to between 100% and 130%.

Screen Shot 2018-01-04 at 15.37.23.png

Matej Vitásek January 12, 2018

This is still happening with the latest build (152).

Warrick Bayman January 12, 2018

Build 150 fixed it for me. 152 also still good on my side.

Tom Drewes
Contributor
January 12, 2018

I've installed build 152 - and while it seems a bit better, there is still what seems like a high idle CPU around 60%. Additionally, I noticed spindump firing up after running SourceTree. The log file indicated a high rate of idle wakeups:

 

Date/Time:       2018-01-12 14:22:36.973266 -0500

OS Version:      Mac OS X 10.13.2 (Build 17C205)

Architecture:    x86_64

Report Version:  19

 

Command:         Sourcetree

Path:            /Applications/SourceTree.app/Contents/MacOS/Sourcetree

Version:         2.7 (152)

Parent:          launchd [1]

PID:             6935

 

Event:           wakeups

Wakeups:         45001 wakeups over the last 6 seconds (7027 wakeups per second average), exceeding limit of 150 wakeups per second over 300 seconds

Action taken:    none

Duration:        6.40s

Steps:           3

 

Hardware model:  MacBookPro11,5

Active cpus:     8

 

Fan speed:       3539 rpm

 

 

Powerstats for:  Sourcetree [6935]

UUID:            BDA3F21B-4C84-312A-93C9-F5FAD260A32E

Start time:      2018-01-12 14:22:40 -0500

End time:        2018-01-12 14:22:42 -0500

Microstackshots: 3 samples (100%)

Primary state:   1 samples Frontmost App, Kernel mode, Effective Thread QoS User Interactive, Requested Thread QoS User Interactive, Override Thread QoS Unspecified

User Activity:   0 samples Idle, 3 samples Active

Power Source:    0 samples on Battery, 3 samples on AC

  2 NSApplicationMain + 804 (AppKit) [0x7fff54ee0f1a]

    2 -[NSApplication run] + 764 (AppKit) [0x7fff54f11d6d]

      2 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 3044 (AppKit) [0x7fff556b2b4c]

        2 _DPSNextEvent + 2085 (AppKit) [0x7fff54f1cf5f]

          2 _BlockUntilNextEventMatchingListInModeWithFilter + 64 (HIToolbox) [0x7fff56c51914]

            2 ReceiveNextEventCommon + 613 (HIToolbox) [0x7fff56c51b96]

              2 RunCurrentEventLoopInMode + 286 (HIToolbox) [0x7fff56c51e26]

                2 CFRunLoopRunSpecific + 483 (CoreFoundation) [0x7fff57939d23]

                  1 __CFRunLoopRun + 1654 (CoreFoundation) [0x7fff5793a626]

                    1 _kernelrpc_mach_port_insert_member_trap + 10 (libsystem_kernel.dylib) [0x7fff7f37f762]

                  1 __CFRunLoopRun + 2427 (CoreFoundation) [0x7fff5793a92b]

                    1 __CFRunLoopDoTimers + 346 (CoreFoundation) [0x7fff5794332a]

                      1 __CFRunLoopDoTimer + 1822 (CoreFoundation) [0x7fff57943afe]

                        1 __CFRepositionTimerInMode + 135 (CoreFoundation) [0x7fff5790e1b7]

                          1 __CFArmNextTimerInMode + 621 (CoreFoundation) [0x7fff5790e66d]

                            1 <User mode>

  1 _pthread_wqthread + 1387 (libsystem_pthread.dylib) [0x7fff7f4c41ca]

    1 _dispatch_worker_thread3 + 101 (libdispatch.dylib) [0x7fff7f2016ed]

      1 _dispatch_root_queue_drain + 515 (libdispatch.dylib) [0x7fff7f201941]

        1 _dispatch_source_invoke + 620 (libdispatch.dylib) [0x7fff7f202018]

          1 _dispatch_continuation_pop + 472 (libdispatch.dylib) [0x7fff7f212e76]

            1 _dispatch_client_callout + 8 (libdispatch.dylib) [0x7fff7f1ffd50]

              1 ??? (Sourcetree + 2746683) [0x102eb693b]

                1 ??? (Sourcetree + 2747263) [0x102eb6b7f]

                  1 ??? (Sourcetree + 2747605) [0x102eb6cd5]

                    1 ??? (Sourcetree + 732931) [0x102ccaf03]

                      1 ??? (Sourcetree + 731468) [0x102cca94c]

                        1 ??? (Sourcetree + 729390) [0x102cca12e]

                          1 ??? (Sourcetree + 1590826) [0x102d9c62a]

                            1 ??? (Sourcetree + 1590312) [0x102d9c428]

                              1 ??? (Sourcetree + 1589609) [0x102d9c169]

                                1 ??? (Sourcetree + 1588912) [0x102d9beb0]

                                  1 <User mode, Effective Thread QoS Default, Requested Thread QoS Default>

 

  Binary Images:

         0x102c18000 -        0x102fb3fff  com.torusknot.SourceTreeNotMAS 2.7 (152) <BDA3F21B-4C84-312A-93C9-F5FAD260A32E> /Applications/SourceTree.app/Contents/MacOS/Sourcetree

      0x7fff54edb000 -     0x7fff55d38fff  com.apple.AppKit 6.9 (1561.20.106) <7A71ACCF-2DF5-3557-BB22-3A9FC9F71CCF> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit

      0x7fff56c22000 -     0x7fff56f27ff7  com.apple.HIToolbox 2.1.1 <ADBE7A1B-0402-369C-A6F3-494E8CACD619> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox

      0x7fff578b5000 -     0x7fff57d55fff  com.apple.CoreFoundation 6.9 (1450.16) <23F8373A-FA3F-37A2-BA5B-70061BFCCD21> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation

      0x7fff7f1fe000 -     0x7fff7f237ff7  libdispatch.dylib (913.30.4) <7D0E3183-282B-3FEE-A734-2C0ADC092084> /usr/lib/system/libdispatch.dylib

      0x7fff7f36d000 -     0x7fff7f392ff7  libsystem_kernel.dylib (4570.31.3) <D2E842AA-3B8D-31BF-8234-8C1BE11CFE32> /usr/lib/system/libsystem_kernel.dylib

      0x7fff7f4c1000 -     0x7fff7f4ccfff  libsystem_pthread.dylib (301.30.1) <ABA848E1-6978-3B42-A3A7-608B2C36FA93> /usr/lib/system/libsystem_pthread.dylib
Matej Vitásek January 15, 2018

Still happening to me in build 152 after upgrading from mac OS Sierra to High Sierra.

Warrick Bayman January 16, 2018

I spoke too soon. 152 still has this problem.

Nate Chrysler February 7, 2018

Hi @bgannin I'm also experiencing this problem on build 152. The last few days I've noticed my CPU even sitting as high as 100%. As far as I can tell from using Activity Monitor's "Sample Process" tool, it's all in the NS drawing API, and primarily occurs when I have a repository workspace window open (not just the repo browser). And restarting SourceTree only brings it down from 100% to nearer 30-40%.

It's been almost 2 months since your above message. Can you please provide an update? This issue makes it tough to work without being plugged into the wall outlet, since it drains the battery.

bgannin
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
February 7, 2018

Now that we've wrapped up 2.7 and 2.7.1 we're able to dedicate the next release focused solely on performance and reliability across the board.

Nate Chrysler February 7, 2018

Thanks for the update - I look forward to the upcoming releases.

fernando_shayani
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
February 21, 2018

V 158 still with the issue

Tom Drewes
Contributor
March 16, 2018

@bgannin:

I noticed that the issue that appears to be tracking this problem (or at least a similar one) is prioritized as "low": 

https://jira.atlassian.com/browse/SRCTREE-5306

An issue closed as a duplicate was marked as "highest":

https://jira.atlassian.com/browse/SRCTREE-5318

The severity rating is similarly downgraded from "major" to "minor".

Any chance this slipped under the PM radar and should have been re-prioritized higher? Or, if there's a different ticket open for this, could you advise on the issue number?

bgannin
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
March 16, 2018

The tickets are a bit out of sync… the morale of the story is we're currently working on it for the next update.

khuebner_bw
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
April 18, 2018

Still happening on 2.7.2 (168) - Is anyone really working on this? The program (as nice as it may be) as such is barely usable right now.

Nate Chrysler April 28, 2018

Hi @bgannin - I installed and launched 2.7.3 (169) filled with hope that this would be resolved. It seemed at first to be keeping a low CPU usage, and it did if I only used the Repository Browser window. But within moments of opening any repository's window it crept back to 100% and hovered there.

I like this app. I like that my team uses the same tool. I want to see this fixed.

Let's talk. Where's your research led so far?

Here's what I've found:

  • Closing all windows, and reopening the app with only the Repository Browser window open leads to normal, very low CPU usage
  • Working within a very tiny repository (i.e. 2 commits, 8 files) CPU usage will peak briefly/periodically around 10-15% and then drop to very low usage.
  • Working within a very large repository (i.e. hundreds of commits, thousands of files) CPU generally usage stays at 100%
    • Opening this window initially, not clicking on anything, and switching immediately to the Mac Activity Monitor, the CPU actually hovers around 50% for around a minute, then drops to very low usage.
    • Clicking back to this window and then back to Activity Monitor immediately SourceTree jumps to 100% CPU for 1-2 minutes, then drops to very low usage. Periodically spiking to 100% again even while in the background.
    • Once I start navigating around between views (File Status, History, various branches), it never seems to drop back below 100% usage, even if I focus on another application for a while. I suspect this is where most of the other users' reports are coming from, as it's pretty normal usage. It simply appears to be always at 100% usage.
    • Once the 100% CPU has started, closing the large repository's window, so that only the Repository Browser is open, does not stop the CPU load for a couple minutes. But once it does stop, it seems to act closer to when the app was launched with just the Repository Browser, but hovering periodically around 75% usage. This leads me to believe this is possibly a leaky object reference tied to a long-running refresh or redraw operation.

Tangentially, I noticed a while back that there was a sort of automatic filesystem refresh that was added. Before that, I believe it would refresh when I returned from another application, or when I manually requested it. Now it seems to do so even in the middle of reading through a diff (which can be somewhat annoying, but I digress). I mention it in case it's related. The brief spike I noticed in the tiny repository - if related to the longer spike in a large repository - could be caused by the same code. I'm picturing a possible cascade of collection or visual updates triggered from the filesystem refresh, that never quite finishes before the next auto-refresh is started.

Using the Mac Activity Monitor and the "Sample Process" utility on Sourcetree, it appears all the samples fall in NS and CoreFoundation calls from, for example, mach_msg_trap. I'm not an expert in the Mach kernel, so I can't add any further insight here. But I figured it was worth mentioning along with the observations above.

Lastly, are there any other suggestions you have to eliminate the CPU issue? Do we need to reinstall, clear a cache, upgrade git, downgrade, or anything else that you've tried that helped?

Thanks.

chris del May 31, 2018

This is still an issue.

mgorbunov1488
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
June 21, 2018

21 june, still 110 - 150% of CPU loading. Macbook always using fan, always hot, thanks for your soft. WTF? 

Deleted user July 10, 2018

How can this still be an issue? It was said to be investigated and a prioritized part of the upcoming releases over six months ago? 

 

Ive downgraded to 2.6.3 to solve this, there seems to be pretty little hope even for a timeline when this could be solved. Im starting to look into switching to Tower...

rbrollins July 25, 2018

Hey, as a hint for @bgannin, who may or may not even be paying attention, I learned that the CPU doesn't spike while the little gear menu in the top-right of the main bookmarks listing window is open. Opening that menu causes SourceTree to immediately drop down to typical idle CPU usage levels, and closing it makes SourceTree immediately spike back up to 100%.

Like # people like this
1 vote
Ana Retamal
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
October 26, 2018

Hi everyone! Thanks for your feedback and for supporting Sourcetree.

The Sourcetree team, although small, is very dedicated to make Sourcetree a better product every day.

I'd like to add a personal note to those commenting  on the lines of "Thanks for the cake but it's disgusting": the team is really passionate about Sourcetree and it feels really disheartening to read all of these hate comments against a product they're working hard on and that are offering to you so it can help you do your work better, for free. Your comments, suggestions and ideas for improvements are all very welcome, and we're really happy that there's such a Community around Sourcetree and that users are so involved, but it doesn't help when they turn to destructive messages. We are all people, too, on the other side of the screen :) If you don't like the cake, you don't have to eat it.

At this point, I'll close this thread to new responses as recent messages are not contributing anything useful for the Community or for the dev team. If you have any questions about Sourcetree, please submit a new question, and if you find a bug you can report it at https://jira.atlassian.com/projects/SRCTREE/issues/.

Best regards,

Ana

1 vote
alexandre_ackermans October 25, 2018

Still using 2.6.3 as a workaround...... Hope it remains supported for a while. I'm surprised Atlasssian is not addressing the issue.Screenshot 2018-10-25 09.56.42.png

1 vote
ewilde-imperial October 25, 2018

Still not fixed in Sourcetree version 3.0 on Mac OS X Mojave, rolling back the older version again :(

Screenshot 2018-10-25 at 10.30.30.png

1 vote
tk-iddy
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
October 4, 2018

Problem still exists in October 2018.

Routine 60-180% CPU usage.

 

macOS High Sierra 10.13.16

MBP (2017) i7 with 16GB RAM, 256GB storage, and Radeon Pro 555.

Sourcetree 2.7.6 (177)

1 vote
Deleted user July 29, 2018

Please please fix this, even if the fix is to just set the default version to 2.6.3 this is ridiculous.

1 vote
HjoshM
Contributor
July 14, 2018

There is still no update to fix this since December 2017 or am I missing something?

The app on Mac OS X constantly freezes with the colorful spinning-beachball mouse cursor appearing every 2 seconds. And the CPU usage is through the roof. It's literally unusable...

Do you think they monitor this forum or is there a feedback/contact page where we can shout directly?

1 vote
Willem Stuursma-Ruwen
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
July 10, 2018

Please fix the CPU issues, my laptop is getting too hot to keep on my lap. 

1 vote
Dominik Palo
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
May 22, 2018

I've downgraded to the version 2.6.3 too and now it's ok. The version 2.7 is completely unusable - I and a few of my colleagues have big issues with High CPU loads when Sourcetree 2.7 is running... it consumes about 60-70% of CPU and drains out Mac battery like crazy. Please, fix it ASAP

1 vote
Steve Pascoe
Contributor
May 13, 2018

Here because of the same issue, High Sierra CPU usage off the charts with Sourcetree in activity monitor. A downgrade to 2.6.3 is looking good for now. Seems this issue began appearing when they introduced the feature of displaying activity from Bitbucket Pipelines (which i have a few active).

1 vote
ivanrigovsky NA
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
April 28, 2018

Same problem. Build 162

1 vote
Balázs Kovács
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
April 10, 2018

Please  fix the CPU and Memory issues, I'm constantly hovering over 40GB of memory used!!!

1 vote
alexander_shiltcev
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
March 7, 2018

Same issue for me with build #159. 113% CPU usage with only main window opened in SourceTree.

1 vote
Scott Colestock January 23, 2018

Same issue - SourceTree Version 2.7 152, High Sierra 10.13.2.  Cpu above 100% routinely.  I typically have 2-3 SourceTree windows open - but closing the "extras" and getting down to 1 window doesn't change the cpu consumption.  

Scott Colestock January 24, 2018

Per poster above - downgrading to 2.6.3 (134) works great.

Jonathan M
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
February 13, 2018

I really start wondering if they mine bitcoins in background... Version 152, still present, almost never going below 100%, raising as far as 270%, putting my machine on its knees...

Jonathan M
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
February 20, 2018

Still the same situation with the new 2.7.1 (159)...

0 votes
HjoshM
Contributor
July 29, 2018

Hi all, Does this problem also affect the Windows version, or is the latest Win download fine? I downgraded to 2.6.3 version for Mac and it is great. Now, I would like to know the one that I should download for Windows. Thanks

Comments for this post are closed

Community moderators have prevented the ability to post new answers.

Post a new question

TAGS
AUG Leaders

Atlassian Community Events