Puncte:3

Starea Git este foarte lentă pe un singur computer

drapel do

Nu sunt sigur dacă aceasta este o problemă ubuntu sau o problemă git...

Am doua PC-uri

  • unul este un VM ubuntu (numiți-l VM PC)
  • celălalt este un PC Ubuntu (numiți-l Build PC)

Ambele rulează Ubuntu 18.04.

Ambele rulează pe același hardware (mașină fizică diferită - dar aceeași construcție hardware).

Am o structură repo foarte mare, dar când alerg time git submodule foreach --recursive git status Am momente extrem de diferite:

  • Build PC: ~40s
  • PC VM: ~9s

Dacă doar o fac starea git la nivelul superior primesc ~ 2 s pe Build PC și ~ 0,5 s pe VM PC.

Ambele rulează aceeași versiune git 2.17.1 - de fapt cele două Ubuntu unde se instalează folosind aceleași scripturi de instalare - deci sunt foarte asemănătoare.

Principala diferență este că Build PC are 3 fizice 1 NVmem și 2xSSD-uri:

  1. Sistem de operare de 256 GB (NVM)
  2. 1TB sw repos (repo-ul aflat în teste este aici)
  3. 1TB alte repoziții

În timp ce pe VM este totul pe un singur SSD în imaginea discului cutie virtuală (are aproximativ 500 GB)

Nu sunt sigur de unde să încep depanarea acestei probleme, așa că m-am gândit să încep pe acest forum :)

Actualizați

Am încercat acest lucru pe OS SSD de pe PC-ul Build și am obținut în continuare rezultatul mai lent.... deci nu este o problemă cu al 2-lea/3-a SSD sau cu modul în care sunt montate...

Actualizare 2

Pe cele două mașini diferite - se testează cu același repo exact (clonat în același mod de la aceeași telecomandă). Cea Build PC este o clonă mai recentă - dar aș sper că depanarea numărului va fi aceeași. Iată rezultatele de la: git numărare-obiecte -v:

VM PC

număr: 281
dimensiune: 1184
în pachet: 1698
pachete: 2
Dimensiune pachet: 112961
ambalabil cu prune uscate: 0
gunoi: 0
dimensiune-gunoi: 0

Construiește PC

număr: 0
dimensiune: 0
în pachet: 1972
pachete: 1
Dimensiune pachet: 112994
ambalabil cu prune uscate: 0
gunoi: 0
dimensiune-gunoi: 0

valori foarte diferite... Nu sunt sigur ce înseamnă asta. Așa că am eliminat și re-clonat repo-ul VM PC pentru a vedea dacă o clonă proaspătă face altceva. Iată acele valori:

număr: 0
dimensiune: 0
în pachet: 1972
pachete: 1
Dimensiune pachet: 112994
ambalabil cu prune uscate: 0
gunoi: 0
dimensiune-gunoi: 0

Am reluat starea git test și a obținut exact aceleași rezultate - unde PC-ul VM a fost mult mai rapid

Actualizare 3

Alergă într-adevăr ciudat: timp GIT_TRACE_PERFORMANCE=1 git st pe Build PC imprimă o încărcătură de depanare - dar rulează la fel de repede ca PC-ul VM (< 1s). Dar dacă mai rulez ceva, durează mult mai mult:

  • timp GIT_TRACE_PERFORMANCE=1 git st ~0,5s
  • timp GIT_TRACE_PERFORMANCE=1 git st 2> /dev/null ~2s
  • timp git st ~2s
drapel uz
Jos
Rulați `git count-objects -v` pe ambele depozite și spuneți-ne dacă sunt comparabile.
code_fodder avatar
drapel do
@jos Am rulat acele teste și am actualizat în descrierea întrebării de mai sus. Cifrele au ieșit diferit, deși sunt același repo. Așa că am eliminat și re-clonat repo-ul VM PC (pentru că era o clonă veche) și apoi numerele erau aceleași.Dar vremurile erau la fel. În mod curios, pot face ca Build PC să ruleze rapid dacă folosesc `GIT_TRACE_PERFORMANCE`, dar nu și dacă redirecționez ieșirea către /dev/null... foarte ciudat!

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.