4 ms·

I hope you get more employees and/or funding, because 15 seconds for an "Already up-to-date." git pull is the norm with your service.

• sytse 10y ago
  You're right, GitLab.com ssh access is way too slow. See https://gitlab.com/gitlab-com/infrastructure/issues/59#note_13486751 https://gitlab.com/gitlab-com/infrastructure/issues/59#note_... for my writeup. We'll prioritize this.
  • cocotino 10y ago
    Thank you very much, it's appreciated.
    • sytse 10y ago
      You're welcome, thanks for commenting back. Also, we added public monitoring to measure this http://monitor.gitlab.net/dashboard/db/gitlab-status?panelId=12&fullscreen http://monitor.gitlab.net/dashboard/db/gitlab-status?panelId... Relevant part from our initial look into this https://gitlab.com/gitlab-com/infrastructure/issues/59#note_13488035 https://gitlab.com/gitlab-com/infrastructure/issues/59#note_... "My gut feeling with all this is that the NFS server is the main bottleneck. It is maxing out all the time in CPU time dedicated to IO (check graph) and our last finding is also pointing in the direction that the way the LVM is setup (using linear) is not efficient at all, and it is generating a lot of overhead by fragmenting the actual filesystem for reads (on rewrites) and by concentrating all the writes into one single drive at time. The first test I want to make is to create the new NFS server, and add monitoring on that one to rule out completely the fact that the NFS server is the main bottleneck, hopefully this should happen today."