flashydave
flashydave

Reputation: 71

git pull very slow (not the ssh transfer part) on Windows 2003 server

I have a problem with a specific server that I would appreciate help with debugging.

Running git version 1.7.10.msysgit.1 installed as part of git extensions 2.3.1 Windows 2003 Standard R2 SP2. cwRsync (based on Cygwin 1.7) also installed. Trend AV running (have no perms to change this as it is a work machine). The server is a VMWare VM and is reasonably loaded.

The main problem is that git pull (either from git extensions or git bash) takes several minutes even for a very small repository (600k & 26 files). CPU load goes up to near 100% (on 1 CPU) for the duration. Task Manager attributes this load to "System". Memory and CPU for git.exe stays constant (and low).

In general git was originally very slow to do anything on the server. I improved that significantly by changing $PS1 to remove __git_ps1. After this git clone, git push, local git ops are still rather sluggish (5-10 seconds each) but at least it is just about usable. (I am linux based 90% of my time so expect blazing speeds!)

Packet capturing during the git pull shows that the SSH communication occurs 80% through the process and lasts just a few seconds (as you might expect on a good system). Functionally git pull completes successfully with no error reported.

Manually using ssh to log in or pull files appears OK using plink, original ssh (as bundled) ssh 4.6p1 openSSL 0.9.8e or up to date replacement ssh 5.9p1 openSSL 0.9.8s This sort of discounts any network or SSH related aspect.

There is nothing in the system logs or git extension logs indicating any errors.

I looked at de-frag on the 2 installed disks. Both need de-fragging (10% and 14%), one 90% full the other has some reasonable space. I dont have permission to de-frag but I tried cloning the repo onto both 2 disks with no significant difference in the fault.

I was suspicious of Trend AV (but cant change this to eliminate it) but have run the same tests using the same repository on another server and this is blindingly fast.

I was suspicious of git possibly scanning $HOME (the account has a load of external shares under NetHood subdir) but running the same tests under a separate account with nothing in NetHood made no difference.

I understand this is not a product issue but I have run out of ideas. Given I am trying to persuade the company concerned to migrate to git - issues like this on a corporate server don't exactly help my argument!

Thanks Dave

Upvotes: 4

Views: 3626

Answers (3)

Sagi
Sagi

Reputation: 1159

I had the same issue, upgrading msysgit to the latest version (1.9.5 Preview 20141217) solved the issue.

Upvotes: 0

VonC
VonC

Reputation: 1326782

Help is on the way, with commit d637d1b (for git 1.9.x/2.0, Q2 2014):

Improvements to our hash table to get it to meet the needs of the msysgit fscache project, with some nice performance improvements.

git status and git clone should get a boost from this new hasmap API.

Upvotes: 1

Frank
Frank

Reputation: 31

This seems to be caused by msysgit using an ancient OpenSSH version. I think this guy here solved your problem: http://darrell.mozingo.net/2011/09/29/painfully-slow-clone-speeds-with-msysgit-gitextensions/ I didn't yet follow his instructions, so I have to report back on whether this worked for me.

Upvotes: 3

Related Questions