Forum Linux.debian/ubuntu KVM & Buffers

Posté par  .
Étiquettes :
2
5
août
2012

Bonsoir à tous,

Je vous explique mon soucis… J'ai un serveur (Dell Power Edge 2950) avec 8Go de RAM.

Sur ce serveur est installé une Debian 64 bits (Squeeze avec les dernières mises à jour).
Tourne sur le serveur physique: KVM et un serveur Ldap.

Il y a 5 VM qui tournent sur le serveur physique ==> 2 Win 2003 (64 bit), 2 Fedora core 5 et une Debian (Squeeze)

  • Les Fedora Core 5 servent pour un soft spécifique qui ne supporte pas autre chose que cet OS. ==> 256 Mo de RAM chacune.
  • La Debian sert de Repository (pour télécharger des scripts internes en perl)==> 256 Mo de RAM
  • Une Win 2003 sert de serveur de monitoring en SNMP ==> 1Go de RAM
  • La dernière Win 2003 est celle qui me pose problème ==> 1Go de RAM

Sur cette VM win 2003 tourne un SQL Server, je fais les backups de la DB avec "Cobian Backup 11" et mon soucis est que lors du Backup mais plus précisément lors du transfert du fichier (8.5Go) vers notre serveur de stockage, le Buffers de la machine physique se rempli de toutes la RAM "free" jusqu'à ce qu'il ne reste que 45-50 Mo de libre… Cela produit un blocage de toutes les VM.

Habituellement j'ai entre 4 et 5 Go de RAM de libre et dès que le backup transfère les fichiers le LOAD du CPU monte à 150% et le buffer se rempli. Le serveur physique ne plante pas mais impossible de se connecter aux VM en remote desktop et via la commande "virt-viewer", j'arrive à me connecter mais un simple déplacement du curseur de la souris prend des plombes.

Autre chose également, sur la machine Windows rien d'anormal dans le task manager, le load ne monte pas, la ram reste normale, rien d'anormal.

J'ai d'abord pensé qu'en installant le driver "VirtIO" pour la carte réseau ça arrangerait mon affaire mais ça n'a absolument rien changé.

Lorsque je vide le buffer (avec la commande sync) sur la machine physique, le buffer est vide, la mémoire libre remonte à 4-5Go mais la machine Windows reste hyper lente et la seule manière pour moi de récupérer la VM windows est de la rebooter. Une fois redémarrée le buffer reste stable et la machine windows redevient contrôlable.

Petite précision n°1, lorsque le backup ne tourne pas, le buffer monte également mais de manière tout à fait lente (genre 500 ko toutes les minutes), c'est vraiment lors du backup que ça grimpe de manière exponentielle jusqu'au maximum possible. (par coup de 50Mo par sec).

La dernière solution qui s'impose à moi est de réinstaller cette machine Windows mais avant d'en arriver là je me suis dit que poser la question sur un forum me permettrait peut-être de trouver la solution plutôt que réinstaller l'OS et que ça refonctionne sans savoir pourquoi du jour au lendemain cette machine est partie en vrille.

  • # swap virtuel qui vient encombrer le reel

    Posté par  . Évalué à 2.

    soit 8Go de ram, occupé par :
    - 2Go pour 2 windows
    - 512Mo pour 2 FedoraCore
    - 256Mo pour une debian
    2,768Go d'occupé.

    mais quand tu fait ton backup ta machine windows n'a peut-etre plus assez de RAM
    du coup, elle va swapper => utiliser le disque virtuel, qui lui utilise le disque reel
    et donc ralentir toutes les machines.

    regarde deja en allouant plus de RAM à ton windows et en retestant avec le backup.

    • [^] # Re: swap virtuel qui vient encombrer le reel

      Posté par  . Évalué à 2.

      echo 0 >/proc/sys/vm/swappiness

      • [^] # Re: swap virtuel qui vient encombrer le reel

        Posté par  . Évalué à 1.

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

        • [^] # Re: swap virtuel qui vient encombrer le reel

          Posté par  . Évalué à 1.

          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").

      • [^] # Re: swap virtuel qui vient encombrer le reel

        Posté par  . Évalué à 2.

        sauf que la machine qui swap, dans un premier temps c'est son windows virtuel au moment du backup
        donc swappiness n'aura aucun effet

    • [^] # Re: swap virtuel qui vient encombrer le reel

      Posté par  . Évalué à 1.

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

      • [^] # Re: swap virtuel qui vient encombrer le reel

        Posté par  . Évalué à 1.

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

        • [^] # Re: swap virtuel qui vient encombrer le reel

          Posté par  . Évalué à 2.

          qu'il monte n'est pas trop le probleme, ca peut monter sans jamais atteindre le max de la machine
          la vraie question est : "est-ce que ca plante pareil avec 2Go qu avec 1Go ?" "et avec 4Go ?"

          • [^] # Re: swap virtuel qui vient encombrer le reel

            Posté par  . Évalué à 1.

            "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.

    • [^] # Re: swap virtuel qui vient encombrer le reel

      Posté par  . Évalué à 1.

      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.

  • # Deadline

    Posté par  (site web personnel) . Évalué à 1. Dernière modification le 06 août 2012 à 08:08.

    Il est recommandé pour la virtualisation d'utiliser l'ordonnanceur d'I/O deadline (sur ton hôte).
    Cela permettra de favoriser les écritures.
    En écriture en concurrence sur 20 VMs avec dBench je passe de moins de 1Mo/s à 8Mo/s par VM.
    Attention cependant aux effets de bord, si ton Windows passe son temps à écrire tes lectures seront fortement pénalisée.
    Sinon pourquoi ne désactive tu pas le swap sur ton windows ?

    Is it a Bird? Is it a Plane?? No, it's Super Poil !!!

    • [^] # Re: Deadline

      Posté par  . Évalué à 1.

      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

      • [^] # Re: Deadline

        Posté par  (site web personnel) . Évalué à 1.

        http://fr.wikipedia.org/wiki/Deadline_scheduler

        Pour voir ton ordo courant : cat /sys/block/[drive]/queue/scheduler
        et pour le changer en live echo deadline > /sys/block/[drive]/queue/scheduler
        Si ça convient tu peux le configurer par défaut dans ton /etc/default/grub (si tu es sous debian/ubuntu) en ajoutant elevator=deadline sur la variable GRUB_CMDLINE_LINUX_DEFAULT (ce qui devrait donner si tu n'as rien touché GRUB_CMDLINE_LINUX_DEFAULT="quiet splash elevator=deadline"), puis update-grub (en sudo/root)

        Is it a Bird? Is it a Plane?? No, it's Super Poil !!!

        • [^] # Re: Deadline

          Posté par  . Évalué à 1.

          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 !

      • [^] # Re: Deadline

        Posté par  . Évalué à 3.

        je ne vois rien d'exceptionnel, ou alors je ne sais pas lire un top.

        • 122% de CPU, bah si tu as un dual core, il en reste encore 78%, c'est donc normal (d'ailleurs on voit bien que le "load average" n'est pas violent

        • memoire : 52Mo libre, rien d'exceptionnel non plus

        • il n'y a guere que le buffer, ou en 5 minutes tu en consommes 500Mo,
          faut voir comment le logiciel de backup fonctionne pour trouver ses petits avant de faire ses mises à jour de backup

        • [^] # Re: Deadline

          Posté par  . Évalué à 1.

          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 :)

          • [^] # Re: Deadline

            Posté par  . Évalué à 3.

            vu que le top de la machine physique est "normal"
            et que ca marchait encore la semaine derniere, il faut aller chercher ailleurs,
            je vais poser une question bete, le backup se fait en local ou sur un disque externe ? sur un disque reseau ?
            il te reste de la place dans la VM, sur le disque, pour poser les fichiers temporaires le temps du backup ?

            • [^] # Re: Deadline

              Posté par  . Évalué à 1.

              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é.

              • [^] # Re: Deadline

                Posté par  . Évalué à 3.

                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.

                Je comprends pas un backup sur le bureau (donc sur le disque C). Si tu fais un backup du disque système c'est fortement probable que cela fasse swapper ! D'ailleurs le "swap" Windows (sauf si ça a changé) c'est un fichier sur la partition système… Il faut faire de nombreuse exclusions de fichiers quand on fait ce genre de sauvegarde.

                Il est aussi tout à fait possible que j'ai rien compris au problème :)

                • [^] # Re: Deadline

                  Posté par  . Évalué à 1.

                  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…

                  • [^] # Re: Deadline

                    Posté par  . Évalué à 2.

                    un backup d'un seul dossier non,
                    un backup du systeme sur lui meme, c'est risqué car tu va backuper ton backup

                    apres, il faut peut-etre chercher ailleurs, si tous les systemes sont ralentis, backup ou pas, c'est peut-etre un probleme d'acces sur les disques durs, un disque defecteux tentant plusieurs fois de faire ses acces avant de passer au suivant.

                    et ca, ca arrive sans prevenir.

                    Regarde aussi pourquoi ta base de données fait 8Go, y a peut-etre de la maintenance à faire dedans
                    Regarde aussi si ton systeme de stockage et ton systeme de fichier peut encaisser un fichier de 8Go

                    • [^] # Re: Deadline

                      Posté par  . Évalué à 0.

                      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)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.