2 votes

GIT pull times out ?

J'ai récemment mis en place une petite VM de contrôle de révision turnkeylinux (qui a environ 256 Mo de RAM), et j'essaie de cloner l'un des dépôts que j'y ai poussé. Il est très rapide d'y pousser (via ssh) mais extrêmement lent d'en tirer.

Voici ce que j'obtiens si je laisse le temps à SSH de se terminer :

$ git pull
andrewm@1.2.3.4's password:
remote: Counting objects: 403, done.
Read from remote host 1.2.3.4: The connection was aborted
fatal: The remote end hung up unexpectedly
fatal: early EOF

J'ai tenté le clone comme suit :

> mkdir myProj
> cd myProj
> git init
> git remote add origin git+ssh://andrewm@1.2.3.4/srv/repos/git/myProj
> git pull

Lorsque j'envoie la commande de traction, il atteint presque instantanément 50 %, puis s'arrête. Il avance lentement de quelques pourcents supplémentaires (une tentative a atteint 66%) et finit par mourir si on le laisse suffisamment longtemps.

Ce repo est minuscule avec seulement une poignée de révisions jusqu'à présent. Ma version principale est beaucoup plus grande et sera également inutilisable si ce problème n'est pas identifié.

Une idée de la cause de ce ralentissement soudain ?

Update

Je viens de confirmer que la VM est également lente lorsqu'elle est connectée en utilisant le protocole git://. Il ne peut donc pas s'agir d'un problème avec ssh. Je mets à jour le titre de la question en conséquence.

1voto

Ronald Wildenberg Points 18258

Êtes-vous en mesure de cloner localement sur la VM à l'aide d'un fichier file: URL du référentiel du protocole ?

git clone file:///srv/repos/git/myProj /tmp/myProj-clone

En file: oblige les opérations locales à utiliser un protocole qui est très proche du protocole intelligent normal utilisé par l git: / ssh: /smart- http: URL distants. Plus précisément, il utilise un protocole basé sur les paquets au lieu de profiter de l'optimisation normale pour les opérations locales (lien dur/copie des objets du référentiel).

Il se peut que le serveur n'ait pas assez de mémoire pour générer le pack nécessaire à votre opération de tirage. Faire un essai, local, file: Le clonage/tirage basé sur la technologie - exercera les capacités de génération de paquets de votre VM sans faire glisser aucun composant de réseau pour compliquer le problème.

Il existe plusieurs variables de configuration qui contrôlent la génération des paquets :

  • pack.window
  • pack.depth
  • pack.windowMemory
  • pack.deltaCacheSize
  • pack.deltaCacheLimit

Vous pouvez peut-être régler votre référentiel pour qu'il génère ses paquets de manière moins gourmande en mémoire (l'efficacité de l'empaquetage en souffrira probablement).

Je pense que 256 Mo (pour le système d'exploitation et les applications ?), c'est trop peu pour que des applications (potentiellement) gourmandes en mémoire (comme les opérations d'empaquetage de Git) puissent fonctionner rapidement ou même correctement.

1voto

mreggen Points 2940

Connectez-vous à 1.2.3.4 et allez dans votre repo git et faites 'git repack' ; puis essayez un pull et voyez si cela a aidé.

0voto

Essayez de désactiver le TCP Segmentation Offloading sur le serveur-> ethtool -K eth0 tso off

0voto

Mikko Rantalainen Points 778

Il se peut que 256 Mo soient finalement trop peu de mémoire si vous n'avez pas (assez) d'espace de pagination et que l'OOM Killer se déclenche. Avez-vous vérifié dans les journaux du système VM si des programmes ont été tués ? Quelle est la taille du référentiel sur le disque (les .git pour les dépôts non nus) ?

Il convient de noter que le git est mis en œuvre de telle sorte que le plus gros objet (par exemple une image ISO) du référentiel doit être disponible dans la mémoire simultanément en tant que données décompressées et compressées [git] pour que les données puissent être transférées sur le câble (transfert de données git pack). Un seul blob binaire de 200 Mo fortement compressé (par exemple, une vidéo H.264) inclus dans le référentiel fera en sorte que les opérations de récupération/extraction/clonage de cette machine consommeront au minimum environ 400 Mo de mémoire. Si votre système ne dispose que de 256 Mo pour l'ensemble du système, vous aurez besoin d'environ 140 Mo supplémentaires pour git, plus toute la mémoire requise par le système d'exploitation à partir de l'espace de pagination. Si l'espace d'échange est suffisant, cela fonctionnera, mais ce sera très lent.

Git est fortement optimisé pour les systèmes qui peuvent conserver dans la mémoire vive au moins 10 des plus gros objets stockés dans le référentiel. Un système ne disposant que de 256 Mo de mémoire est suffisant si vous avez affaire à une grande collection de petits fichiers (par exemple, le noyau Linux), mais il s'arrêtera d'échanger des données si vous avez ne serait-ce qu'un seul gros fichier. Dans le cas d'un grand nombre de petits fichiers, le besoin en mémoire semble être d'environ 160 octets multipliés par le nombre d'objets dans le référentiel. Pour avoir une idée du nombre d'objets, lancez git count-objects -v et calculer la somme de count et in-pack . Plus vous avez in-pack moins git occupe d'espace disque.

Si vous souhaitez utiliser git pour un projet contenant d'énormes fichiers binaires et votre machine de dépôt git est limitée en mémoire, suivez le développement git pour "loose objects".

Source : http://git.661346.n2.nabble.com/pack-operation-is-thrashing-my-server-td684437.html

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X