Notre GitLab se ralentit fréquemment

Question

Notre GitLab (CE) fonctionne souvent lentement depuis quelques jours. Nous avons un crochet pour l'IC avec Jenkins. Nous avions installé le GitLab par OmniAuth. Je n'ai plus d'idées à ce sujet car nous n'avons rien fait de nouveau dans nos instances.

Nous sommes les débutants de l'environnement GitLab. Nous travaillons dans le GitLab depuis décembre 2016 et nous n'avons jamais rencontré ce genre de problème auparavant. J'espère que je vais résoudre ce problème avec vous. Veuillez m'aider à résoudre le problème.

Suivez l'image ci-dessous pour nos détails Gitlab.

Comment pourrais-je surmonter de cette question?

Answer 1

Ce ne sont que quelques suggestions telles quelles, offertes sans garantie, mais elles peuvent vous aider à résoudre le problème.

rasoir

Occam Vous avez mentionné que ces questions semblent avoir tout juste commencé plus récemment. Cela signifie que le VERY FIRST lieu de regard est ce qui a peut-être changé au moment où ces problèmes se sont produits. Si vous avez un contrôle de changement pour votre infrastructure, commencez par là. Assurez-vous absolument que personne n'a changé quoi que ce soit au moment où ces problèmes ont commencé à se produire. Vérifiez vos journaux pour tous les avertissements qui ont commencé à apparaître. Si votre système d'exploitation a un journal de sécurité ou enregistre les modifications de configuration, vérifiez-les. Si vous n'avez pas une bonne visibilité/capacité d'audit dans votre environnement, cela peut être difficile, mais si vous pouvez identifier quelque chose qui a changé au même moment où ces problèmes ont commencé à se produire, c'est le plus souvent votre problème.

Spécificité

Il peut être utile pour vous de décrire ce que vous entendez par là obtenir lent. Est-ce une opération spécifique qui est lente? Ou est-ce toute l'activité? Si c'est quelque chose de spécifique, comme déclencher un travail Jenkins, alors vous pouvez commencer à isoler votre recherche là-bas.

Il peut également être utile d'exécuter top sur votre serveur pour obtenir une image de ce qui peut être à l'origine des problèmes. Il peut y avoir un processus spécifique en cours d'exécution sur la machine qui domine tout le reste et mange toutes les ressources.

Matériel

La première chose que je voudrais vérifier est de vous assurer que votre configuration matérielle correspond aux directives «exigences matérielles de sur le site Web de gitlab ce: https://docs.gitlab.com/ce/install/requirements.html#requirements Sur la base de ce que vous avez posté, la CPU et mémoire Votre système semble adéquat pour plusieurs milliers d'utilisateurs, donc je vais supposer que ce n'est pas un problème, mais si vous avez des milliers d'utilisateurs, j'ajouterai quelques informations à ce sujet. Votre configuration de disque (autre que la taille) n'est pas présentée dans les informations ci-dessus, donc nous ne savons pas si cela est suffisant ou non.

Je recommande d'exécuter vmstat sur le serveur (puisque c'est GitLab, je suppose que cela fonctionne sous Linux, car ils ne recommandent pas les installations Windows) pour obtenir des informations de base sur ce qui se passe. La commande vmstat vous donnera plusieurs colonnes d'informations. Tout à gauche, il devrait y avoir une colonne «r».C'est la "file d'attente d'exécution", ou le nombre de processus qui attendent d'être exécutés sur un CPU. Si la valeur de cette colonne est grande par rapport au nombre de cœurs du système, vous avez probablement un goulot d'étranglement de l'UC. La colonne suivante, 'b', est les processus qui sont bloqués. Si c'est important, vous n'avez probablement pas de goulot d'étranglement au niveau du processeur. A droite, il y a des colonnes CPU: nous, sy, id, ou quelque chose comme ça. Ces colonnes sont une ventilation de l'endroit où la CPU passe son temps, soit dans le code de l'application (us), dans le code du système d'exploitation (sy), ou en attente (id). Les nombres de pourcentage élevés en nous indiquent généralement que vous exécutez sainement ou avez un goulot d'étranglement du processeur. Les nombres de pourcentage élevés dans sy vont généralement indiquer une sorte de conflit, peut-être un problème de configuration, comme avoir trop de threads de travail configurés pour le nombre de processeurs que vous avez. Un pourcentage élevé dans id indique généralement que le système ne fait pas grand-chose, ou ne peut pas faire grand chose car il attend quelque chose comme un disque ou une base de données externe. Par conséquent, si les colonnes 'b' et/ou 'id' de votre sortie vmstat ont des nombres élevés, nous pouvons envisager la possibilité d'un goulot d'étranglement d'E/S. Voici quelques articles d'introduction sur l'évaluation de Linux IO pour les goulots d'étranglement qui pourraient vous aider à déterminer si c'est le cas: https://bartsjerps.wordpress.com/2011/03/04/io-bottleneck-linux/ http://www.linux-mag.com/id/2001/ Ces articles devraient vous aider à déterminer si vos disques ne sont pas assez rapides . Une chose à noter, si vous voyez ce qui semble être un goulot d'étranglement de l'unité centrale (valeurs élevées, valeurs élevées), assurez-vous que cette situation a un sens pour le nombre d'utilisateurs que vous avez. Le goulot d'étranglement du processeur peut être causé par un problème de virtualisation, ou par un problème du système d'exploitation entraînant un mauvais fonctionnement du processeur, et pas seulement par le fait que le processeur lui-même soit insuffisant.

Topologie

Une chose mentionnée dans les exigences de gitlab ce que je lien ci-dessus est qu'il est recommandé de ne pas runner gitlab ce sur la même case que lui-même gitlab ce. C'est quelque chose que je dirais vrai pour tout logiciel de CI fonctionnant avec GitLab. Si vous exécutez GitLab Runner ou Jenkins dans la même boîte que GitLab, vous devriez envisager de les déplacer sur leur propre matériel.

Si vous avez des milliers d'utilisateurs, vous voudrez peut-être contacter GitLab eux-mêmes et avoir des conseils sur la façon de mettre en place un cluster d'entreprise et à quoi il ressemble. Il y a des gens qui sont experts dans les configurations matérielles spécifiques qui ont du sens pour une très grande installation de GitLab, et je n'en suis pas un. Cependant, si vous n'avez pas un grand nombre d'utilisateurs, le matériel dont vous disposez n'est probablement pas le problème.

Software

Si vous utilisez des choses comme vmstat et iostat et vous ne trouvez pas tout goulot d'étranglement matériel spécifique, il peut y avoir un problème de configuration. Assurez-vous que vous avez configuré un bon nombre de Licorators, afin que la boîte puisse utiliser correctement votre matériel.

goulots d'étranglement externes

Assurez-vous que des choses comme la vitesse du réseau sur le serveur sont suffisantes pour ses besoins. Assurez-vous que les utilisateurs qui tentent d'atteindre le serveur ne sont pas gênés par un réseau mal configuré. Si vous utilisez OmniAuth, assurez-vous que le fournisseur fonctionne correctement. Par exemple, si vous utilisez une authentification externe et que celle-ci ne fonctionne pas correctement, vous aurez également de mauvaises performances dans GitLab. Ceux-ci sont particulièrement importants à regarder si vous ne voyez pas beaucoup d'utilisation du matériel en utilisant les méthodes ci-dessus.