I've just installed Github for Windows on my Windows 8.1 machine and it appears to work fine except that my machine performance drops down dramatically.
Looking at task manager I see that ssh-agent.exe is using a constant 25% CPU (no doubt 100% of one of my cores) and the disk usage is at 100%.
I have had a look on the Internet but can't find any reference to what might be causing this.
Any ideas what might be causing this and how to resolve it?
UPDATE:
I can kill the process and GitHub for Windows appears to keep working but the ssh-agent.exe process starts up again as soon as I close and restart Github for Windows.
Further to moggizx's comment in one of the other answers, I found this was influenced by SourceTree too.
The instance of ssh-agent.exe with the high CPU actually gets terminated when you close SourceTree. Restarting SourceTree does cause another ssh-agent process to be spawned, but the CPU is then idle.
We've seen this happen on occasion due to a race condition between ssh-agent and anti-virus software competing over resources. Do you have any anti-virus software installed? Would you be able to temporarily turn it off and see if the problem persists? We'd be very keen to dig deeper into this if you could reach out to support#github.com.
I found the same issue, my solution was to add the file and the process C:\Program Files\Git\usr\bin\ssh-agent.exe to exclusion list in Windows Defender on Windows 10.
The reason this happens is most likely that your git repository is huge. Probably you have mistakenly instantiated it in a folder where you have an enormous amount of files. So git loops over them constantly and thus takes up alot of processing power needlessly. You can try and delete your .git folder(s) and this should stop.
Try and initialize your git repo in a folder where you exclusively use your projects.
I would still consider this to be a sort of bug, because we should be notified if this happens(we shouldn't need to find out by opening task manager).
Related
Three weeks ago, I ditched Sublime in favour of Visual Studio Code. Everything was going great till the program started taking upwards of 30 seconds to start up (launch, show visual feedback) and another 20 or so to boot up (fill in syntax colours, load extensions, and stop stuttering). In the worst instances, it takes minutes to boot up (I used a stopwatch).
At first, I guessed that extensions cost me a lot in start-up time, so I uninstalled most of them. After that, I added 2GB of RAM to my system, moved my CPU to another laptop (smaller chassis, less PPI), swapped my HDD to an SSD, and reinstalled Windows. I didn't make these changes to help VS Code's start/boot time but for other reasons. But even after all these upgrades, VS Code's start-up time seems to increase as time goes by (even without changes to my "Workbench"). Is this normal? What makes it so?
My PC setup is: Core i5 520M # 2.4 Ghz, 6GB DDR3 RAM, 128GB Micron SSD.
My VS Code setup has five extensions installed, about thirteen lines in settings.json (including autoSave, JetBrains Mono font, colour themes for Light and Dark mode), and syncs settings to my Microsoft/GitHub account.
Since you've mentioned a DDR3 RAM I assume your system is quite old and 520M i5 CPU is really old (It's a 1st gen processor). Do you have similar problems with any other applications or is it just VSCode?
If you are confident that your system is not the problem you can try this;
As others have noted, It is based on Electron so under the hood you have Node & Chromium. You cannot have high expectations from something built on Electron which is known for it's notorious memory footprints. However, 30 seconds startup time is still long. It takes roughly 5-6 seconds in my machine to load and become fully functional, with 9 extensions installed (which are quite large extensions btw).
Another note here is that even when you uninstall a VSCode plugin/extension the directory of that extension never gets removed, VSCode just marks them as Obsolete in a JSON file and keeps the directories for whatever reason. You could try uninstalling & reinstalling, which might help. A simple uninstall will not be of much help since VSCode has cache & configuration directories that are not typically removed upon an uninstall. You'd have to manually remove them. If you are on a Windows machine check
C:\Users\<your name>\.vscode,
C:\Users\<your name>\AppData\Local\Microsoft and
C:\Program Files\Microsoft VS Code
for any leftovers related to VSCode and remove them.
The reason for this to wipe the previous install without any trace (you'll lose all your customizations since they are stored & kept in these directories even after uninstalls, so that when you reinstall, VSCode can access & load your previous configurations which makes your life easier btw)
Try reinstalling after. If you are on a UNIX system look up the equivalent directories, remove the leftovers and do a clean reinstall. Hope this helps.
One of a very kind volunteers helped to get M2Crypto almost to the shape that it builds on Windows. We use Appveyor CI for testing (I am a Linux guy, so I don't even have an access to a Windows machine), everything works well, when it does, but it is quite unreliable. M2Crypto is using swig and downloading it for every job seems quite unreliable. Any ideas how to make choco more reliable?
Or, would it be possible to restart just one job (not whole commit), so that when this happens, I could get passing commit with restarting a job?
Thank you for great service.
I would recommend Caching chocolatey packages.
Restarting a single job in the matrix is still not implemented.
so I have a problem. I accidentally deleted Eclipse folder and I wanted to install Eclipse again. But when I run installation it freezes the moment I run it, and I have to exit it...please help me
It would be informative to observe and mention any system error during installation attempt. By the way, I hope you are installing the right version for your operating system and more so, you have the recommended system requirement like RAM size, processor speed. I suggest:
Restart your system.
Use a system tool like Advanced System Care (free) and scan your system.
Well, I don't know what happened but I tried to install it 2 times, it freezed and didn't work. When I tried third time it worked. :D So yeah. Magic.
I had the same issue. Everytime I tried to install Eclipse, the installer froze at some point. Turned out it was a problem with the firewall. I tried the installation over a hotspot from my phone and it worked.
Might not be the problem for you, but I thought I leave this here, as I was trying for quite a while and almost gave up.
I spent several days trying to solve this, so I'm going to post both the question and answer for the next person.
In CentOS 7, mounting a folder shared by Windows 7 with the following command:
mount -t cifs //MyWindowsPC/SharedFolder $MOUNTPOINT -o user=$USER,uid=$USER,gid="`id -g "$USER"`",cache=none
resulted in Input/Output errors using parallel make (make -j), but not with sequential make. The files that gcc/g++ were unable to read changed with each attempt and occasionally gcc/g++ would note that the error was not reproducible. This led me on quite a wild goose chase as system logs showed very generic CIFS/VFS errors.
There is an issue on the Windows side of things. I tried a combination of suggestions from various websites. I haven't spent time to understand the solution, but I narrowed it down to just two Windows registry changes. I have tested that this fixes the problem on 5+ different Windows 7 machines sharing with several different CentOS 7 and CentOS 6.2 machines. Input/output errors disappear and accessing the share is fast. Here is the solution:
Go to Start and search for “regedit”. Open that and navigate to HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/services/LanmanServer/Parameters/. In that folder, change the “Size” parameter from 1 to 3 by right clicking it and selecting “modify”.
In the same folder, right click and select “new->DWORD (32 bit)”. Name it “SMB2” and ensure that it is set to zero (should be default).
Restart your windows machine and that should resolve issues compiling in the windows share.
I'm not sure that both changes are necessary, but I am sure that together they fix the problem.
All the developers in my team here have the same problem - when NetBeans is unpacking the index for Sonatype Repository the system becomes very, very slow. I hope that there is some parameter somewhere so we can reduce the priority of that process in order to make it "behave"?
UPDATE: Thanks to #sashoalm for reminding me about the disk I/O. I have noticed that the process does lots of disk I/O and that probably makes the system unresponsive.
It has a nasty habit of starting at the worst possible time, so we had to turn it off…
OK, I have found a solution. I am not particularly happy with it, but anything is better than nothing.
Luckily, I use Linux exclusively, so I simply reniced the java process that is taking all the system resources. A simple renice -p <java PID here> -n 10 did the job, and the whole system is now responsive as before.