oriolus a écrit 12 commentaires

Voilà je viens vous tenir au courant après plusieurs jours de troobleshooting…

Lors de mon dernier post je m'étais arrêté à lancer une défragmentation.

La défragmentation "Windows" se bloquait à 7% et provoquait un "kernel panic" sur la machine physique.

J'ai téléchargé "Defraggler" lui progressait mais pour arriver aux 100% de 100 Go ça a pris 10 jours (peut-être la plus longue défragmentation de l'histoire de l'informatique :D)
Cette défrag m'a montré que j'avais un fichier de LOG (LDF) de SQL server de 16 Go, j'ai donc pris le risque d'effacer ce fichier (j'ai un backup de ma DB). Une fois effacé cela a amélioré un tout petit peu les performances (surtout au niveau du buffer). J'ai donc fait le tour et viré quelques "gros fichiers" qui ne servaient pas.

Au final j'ai constaté que lorsque j'écrivais sur le disque le load du CPU monte et rend la machine impossible à utiliser.

Nouvelle situation "hardware" ==> Disque de 100Go, 65Go de libre, 2 Go de RAM.

J'ai donc fait quelques tests:

J'ai copié un fichier de 5 Go du disque dur vers un disque réseau, ça a pris 20 minutes pour le transfert et le load est monté très peu.

J'ai ensuite copié ce fichier du disque réseau sur le disque dur, cela a pris une nuit complète, le lendemain matin j'en étais à 70%, le load parti en live et la machine incontrôlable.

J'ai donc copié ce fichier d'un répertoire A vers un répertoire B sur le même disque. Résultat pire que les 2 premiers test.

J'ai mis le cache mode à "0" et refait les mêmes tests, le résultat est le même sauf que le load monte un peu moins mais ça rend impossible l'utilisation de la machine.

J'ai même fait le test avec un fichier de 200Mo d'un folder A vers un folder B du même disque dur, ça a pris 1h30 pour la copie.

Vendredi mon boss m'a sommé de réinstaller ce serveur (je vais plus me faire ch… avec une VM mais je vais faire l'installation sur une machine physique à part).

Je vais garder la VM pour tenter de faire quelques test à mes heures perdues car j'aimerai savoir ce qui pourri cette VM !!

Voilà pas beaucoup d'éléments supplémentaires mais je tenais à vous tenir informé et clôturer pour le moment ce sujet !!

Merci pour vos conseils et idées.

C'est un backup d'un seul dossier, la taille est normale, c'est le backup de la base de données client (qui a 10 ans) donc la taille est normale.

Notre serveur de fichier reçois chaque nuit près de 100Go de backup (backup config routeurs, switches, 15 serveurs Linux (/var, /etc, /home de tous les users) sans sourciller.

Quand le buffer est rempli, j'éteins la VM windows et le buffer redescent de 4Go.

On est donc bien d'accord que cette VM mange le buffer, ce qui n'est pas réellement le problème puisque tant qu'il reste 50Mo de RAM ça devrait fonctionner. Le problème est que je perds le contrôle de la machine.

Un ami m'a conseillé de faire un defrag du disque dur virtuel (après tout ça reste une machine windows :p) et ensuite virer l'ACPI du fichier de config de la VM, je vais donc tester ça fin de journée.

Un avis sur l'ACPI ?

Par rapport à ta remarque sur les disques durs je vais quand même checker au niveau du contrôleur RAID, il est vrai que ça peut lâcher du jour au lendemain (je pense que j'ai un PERC 5i tout neuf qui traine au stock, je vais le remplacer pour m'assurer que ce n'est pas ça)

Vu que le buffer montait lors du backup alors que ce backup ce passait sans soucis j'ai testé de faire le backup sur le disque dur lui même. Je me doutais bien que ça allait swapper mais bon un fichier de 8,5Go alors qu'il reste 35Go de place sur un serveur qui n'est pas chargé en application active même si ça swappe un peu ça ne devrait pas prendre 15h pour seulement transférer 1Go sur les 8,5…

Je voulais voir si c'était le transfert réseau qui posait problème…

Le disque dur fait 100 Go et il reste 36Go de libre(le backup fait 8,7 Go).

Le backup se fait sur un serveur de stockage donc sur un disque réseau.

Petite précision qui me revient à l'esprit:

Le backup sur le serveur de stockage se fait en 27 minutes donc relativement rapidement.
Par contre j'ai lancé un backup sur le bureau windows (donc sur le disque C) à 17h30 et le lendemain à 9h il était à peine à 10% du travail, ce qui correspondait bien lorsqu'on ma conseillé de regarder vers le swap.

Au tout départ avant de venir poster ici, je me focalisais sur l'I/O (je le garde quand même en tête) et je me suis dit qu'en installant le driver VirtIO ça arrangerait l'histoire (j'ai également fait la modification dans le fichier XML du guest en ayant pris soin de l'éteindre avant). Mais au final ça n'a rien changé.

ok il va falloir que j'étudie l'histoire… Je vais essayer de trouver du temps pour lire tout ça mais en plus de ce problème de VM nous sommes en pleine migration du management cette semaine, ça va pas être évident de tout faire !

Bah qu'il ne reste que 50 Mo de RAM disponible n'est pas un problème… Mon problème est que mon load cpu et ma mémoire sont graphés. Le buffer ne se remplissait pas la semaine passée. Le CPU monte toujours en load pendant le backup (entre 2h et 3h du mat) mais redescend une fois la backup terminé et la mémoire n'était pas affectée.

Depuis la semaine passée la mémoire sature et ma VM ne répond plus ou très très très lentement. Un remote Desktop n'est pas possible je dois passer par "virt-viewer" pour tenter de redémarrer la machine sans la "destroy", ce qui me prend une bonne heure vu la lenteur de la VM. Une fois la VM redémarrée et la mémoire vidée (sync)tout rentre dans l'ordre jusqu'au backup suivant.

Tout ceci implique que ma collègue n'arrive pas à joindre la base de données et ne peut donc pas faire sa facturation, ce qui est assez ennuyeux :)

Je ne sais pas ce qu'est l'ordonnanceur I/O.

La machine Windows ne sert qu'à gérer la base de données pour un programme de facturation. Cette base de données contient les informations client. Ce serveur n'est donc pas énormément sollicité en Read/Write. Seulement par une personne.

J'ai désactivé la SWAP de mon windows, j'ai redémarré le serveur, relancé le BACKUP et ça repart en live…

Le backup est en cours…

Petit aperçu de la commande TOP

top - 10:19:59 up 11 days, 15:56,  4 users,  load average: 0.02, 0.30, 0.50
Tasks: 174 total,   3 running, 171 sleeping,   0 stopped,   0 zombie
Cpu(s): 15.3%us, 14.6%sy,  0.0%ni, 67.9%id,  0.5%wa,  0.1%hi,  1.5%si,  0.0%st
Mem:   8185176k total,  7646360k used,   **538816k free**,  3336804k buffers
Swap:  2023416k total,    79896k used,  1943520k free,    57060k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                
15885 libvirt-  20   0 2258m 2.0g 3848 R  **122** 26.0  60:11.64 kvm                                                                    
 1965 libvirt-  20   0 1231m 1.0g 1896 S    8 12.7   1501:05 kvm                                                                    
 2011 libvirt-  20   0  444m 255m 1844 R    3  3.2 547:00.10 kvm                                                                    
 1979 libvirt-  20   0  452m 255m 1844 S    2  3.2 554:56.67 kvm                                                                    
 1950 libvirt-  20   0  467m 249m 1820 S    0  3.1 138:18.27 kvm                                                                    
17500 root      20   0  157m  14m 8124 S    0  0.2   0:10.91 virt-viewer                                                            
    1 root      20   0  8356  716  668 S    0  0.0   0:10.98 init     

Et à nouveau petit aperçu de la commande TOP quelques minutes plus tard:

top - 10:25:05 up 11 days, 16:01,  4 users,  load average: 0.07, 0.19, 0.39
Tasks: 172 total,   1 running, 171 sleeping,   0 stopped,   0 zombie
Cpu(s): 16.2%us, 15.2%sy,  0.0%ni, 66.8%id,  0.3%wa,  0.0%hi,  1.5%si,  0.0%st
Mem:   8185176k total,  8132664k used,    **52512k free**,  3820472k buffers
Swap:  2023416k total,    80780k used,  1942636k free,    46244k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                                
15885 libvirt-  20   0 2258m 2.0g 3848 S  123 26.0  66:14.17 kvm                                                                    
 1965 libvirt-  20   0 1231m 1.0g 1896 S    9 12.7   1501:33 kvm                                                                    
 2051 openldap  20   0  567m 9860 2620 S    3  0.1 160:30.13 slapd                                                                  
 2011 libvirt-  20   0  444m 255m 1844 S    3  3.2 547:07.70 kvm                                                                    
 1979 libvirt-  20   0  452m 255m 1844 S    2  3.2 555:04.09 kvm                                                                    
  978 root      39  19     0    0    0 S    0  0.0  55:02.50 kipmi0              

"est-ce que ca plante pareil avec 2Go qu avec 1Go ?" "et avec 4Go ?"

La réponse est "oui"

Je n'ai pas essayé avec 4Go puisqu'avec 2Go ça ne change rien et que la semaine passée le backup (qui faisait 8,3Go au lieu de 8,6 maintenant) se passait sans problème…

Après tu vas me dire qu'avant de mourir on était vivant mais bon si avec 1Go le backup de 8,3 se passe sans problème je ne pense pas que quadrupler la RAM va changer la donne.

J'ai appliqué la commande pour assigner une valeur de "0" au swappiness, j'ai lancé le backup mais ça ne change rien, au moment du transfert du fichier, le buffer s'emballe…

Petite précision pour être sûr que je me suis bien expliqué. Je parle bien de la partie "buffer" de la mémoire et non pas du cache de la mémoire Swap !

Le Swap de la machine physique se comporte normalement.

(toutes ses informations sont issues de la sortie de la commande "top").

J'ai monté la RAM de la VM Windows à 2Go mais ça ne change rien… Le buffer grimpe toujours à la même vitesse.

Ok j'avais déjà pensé à monter la RAM à 2Go…
Puis-je le faire via le fichier XML de la VM ? (virsh edit guestname)

Pour le moment la valeur du "swappiness" est de 80. Quelle serait la conséquence de mettre cette valeur à zéro ?