Nous avons 2 serveurs BM en 3.0.24, l’un avec souscription, l’autre sans. Ce dernier a récupéré les 850 comptes de messagerie hébergés sur un serveur Linux/Postfix/Dovecot la semaine dernière.
Les mails arrivent correctement sur le serveur, par contre nous constatons une extrême lenteur lors de la récupération des mails par POP3 ou IMAP (pas testé via EAS): un mail avec 2 pièces jointes totalisant une taille de moins de 5Mo met 20 minutes à être récupéré.
Ce serveur est virtualisé sous VMWare, a 4 vCPUS et 12 Go de RAM. Aujourd’hui il est principalement utilisé pour la messagerie; il y a très peu d’appareils mobiles, et pas d’utilisation de la partie collaborative (contacts, agenda). Il est monitoré entre autres par Cacti, et les graphes ne montrent aucune surcharge CPU ou RAM.
Nous avons passé le serveur à 16Go de RAM, sans que cela améliore le délai de récupération des mails. Nous avons modifié la configuration des services de Cyrus pour doubler les maxchild (passage à 400 pour imap et 100 pour pop3), sans succès.
Un bmctl memory remonte des valeurs identiques à 12 ou 16Go de RAM:
# bmctl memory
Memory used for 1066: 99912384
Memory used for 1039: 218332584
Memory used for 1069: 67803304
Memory used for 1024: 75805288
Memory used for 1059: 321402528
Memory used for 616: 129558768
Memory used for 1192: 160091864
Memory used for 617: 545909136
Memory used for 620: 53755008
Memory used for 626: 47988816
Memory used for 624: 150023872
Memory used for 629: 146624472
Memory used for 667: 604372304
Memory used for 1078: 108064872
Total Blue Mind JVM memory: 2729645200 (2603 MB)
Nous avons réalisé une trace de l’activité réseau, celle-ci semble montrer beaucoup de fragmentation, des DUP ACK et de la retransmission de paquets.
Auriez-vous une piste à nous suggérer pour la résolution de ces lenteurs, vraiment très pénalisantes?
problème intéréssant , et déjà eu sur d’autres infras pour hébergement applis web intranet de 3000 users , cela venait des baies de stockages NFS ne disposant pas de cache SSD (et disposant d’une mauvaise configuration, ne respectant pas les best practices, mais ce n’était pas la raison officielle)
Là pour creuser un peu,
quel est OS virtualisé, le type de carte réseau virtualisé, le type de stockage et le le type de liaison ?
Je pense à un problème I/O des dd virtualisé, une latence trop forte qui oblige la pile TCP/IP de regénérer les paquets …
Effectivement ça aurait pu être une piste. Nous avons déjà vérifié ce point-là, ayant déjà eu des problèmes de performance dans le passé avec une baie de stockage NetApp. Un esxtop ne montre pas de latence particulière sur le volume concerné.
L’OS client est une Debian 8 64bits de base, sur laquelle nous avons installé BlueMind. La VM est équipée de l’adaptateur vmxnet3 sur une patte physique en giga, le stockage est un volume hébergé sur une FAS2240, monté en NFS sur un lien 10GE.
NFS : le montage du lien sur l’ESX est en async ou sync ??
10GE ou pas, un montage en sync va ralentir d’autant les I/O qu’il y a d’accès … (et vu le nombre de User , cela commence à faire du bruit)
A titre personnel, je ne monte jamais sur mes ESX et Proxmox des liens NFS en sync … . En cas de problème éléctrique, ce qui est très rare, je n’ai jamais encore eu de perte de data ou corruption de volume.
Bonne appétit,
je regarderais les pilote coté Debian 8, je n’ai pas encore migré mes VMs vers cet OS
Sous ESXi, à part le faire à la mano en ssh dans /etc/fstab, c’est la seule solution
Par contre, sans toucher à l’ESXi, l’option peut être mis dans /etc/export du serveur NFS.
Pour nos petites infra-locale, ESXi sur un NAS HP, je te confirme que tous nos montages des volumes sont standard coté HOST ESX et en async coté serveur NFS. ( pour le reste, nos clusters Vsphère sont en iSCSI (en Jumbo Frame) donc pas de problème )
Sans cela, nos VM Windows étaient complètement lent dans la moindre manipulation, copies de fichiers extrêmement ralenties … et sans pour autant de “I/O wait” … .
(par contre, je suis d’accord avec toi pour la fonction “sync” pour valider la chaîne de data de bout en bout, mais en async en cas de problème éléctrique, les onduleurs sont là pour palier au panne éléctrique et en cas de coupure nous avons une chaîne ControlM d’arret des VM et serveurs physiques pour arréter automatiquement 95% de l’infra-structures)
Question de base : en dehors de BlueMind, depuis et dans la VM, l’accès aux fichiers et leurs copies sur le disque local te semble t’il aussi ralenti , même question avec un rsync over ssh … . Si la copie over ssh est bien plus longue que la copie direct localement, cela tendrait à prouver un bug coté pile TCP/IP …
La piste des pilotes pour Debian 8 semble se préciser…
J’ai repris le même type de matériel pour une VM de test sous Debian 8, avec uniquement des services basiques dessus (syslog, ssh): un transfert par scp plante de temps en temps (ça n’est pas déterministe), un dd localement finit à chaque fois avec des temps cohérents.
Je n’ai pas testé le e1000, car à une époque nous avions une VM qui l’utilisait et avec laquelle nous avions eu des problèmes. Cela dit, au vu des tests de transfert effectués, je vais essayer avec cet adaptateur.
Coté mémoire RAM de la VM, pas de problème, pour moi ton serveur bluemind est bien taillé …
C’est un problème particulièrement intéressant …
je réfléchi donc à d’autres pistes … (A cette heure, aussi tardive, mes idées se seraient pas très clair )
A tout hasard, ta baie de disque n’aurait pas un problème de raid …
Explication : tous mes serveurs privés (et de mon second boulot) sont tous montés dans des serveurs Proxmox en Raid Soft … Quand un disque est exclu et/ou son disque de spare prend le relais, le load de mes VMs s’envole ; et cela est particulière visible sur les VM blueMind …
Du coup, le serveur est moins réactif …
Quel est le load (et valeur d’un htop) de ta VM en ce moment ?
Sur le plan réseau local et physique, comment ton architecture est-elle monté ? Vlan, QoS, pare-feu, snort ???
Non pas encore… à un moment on a cru à un problème lié à l’IP du serveur, mais finalement en changeant l’IP, même symptôme…
Aujourd’hui le serveur est en Debian8 sur vSphere 5.5, ce qui apparemment n’est pas officiellement supporté; du coup on va downgrader l’OS client en Debian7, pour voir…
OS n° 8 du Debian ne veut pas dire grand chose, tout dépend :
de la version de noyau
de la version des utilitaires pré-compilé (de mémoire : linux-header-virtuel / linux-images-extra-virtual / open-vm-tools / …)
Moi, je préfère toujours faire de l’artisanat
installation native du système avec le noyan standard stable
Sous proxmox en KVM, je ne mets aucune surcouche dans la VM
Sous vSphere, en mettent les paquets sources su noyan, j’installe manuellement les sources tools-client de Vmware depuis l’ISO addons (comme sous windows d’ailleurs). Sans ses tools, le H.A. / backups / autres fonctionnalité ne fonctionne pas. Le shell d’installation compile et assemble lui-même les modules client VMtools au noyau …
Mon collègue travaillant sous vSphere 5.5, il manipule quelques VM sous Debian 8 et n’a aucun problème (vSphere sur C7000 de HP, avec des datastores en iSCSI)
Je suis d’accord avec toi, ça n’est pas tant la version de Debian qui importe, mais plus la version du noyau, des drivers et de leur interopérabilité avec VMWare et ses tools.
A l’installation de la VM j’ai suivi les recommandations de VMWare et installé les open-vm-tools. Avant de poster, j’avais fait un essai avec les VMWare tools fournis par le l’ISO de vSphere, sans amélioration.
A une époque nous avions une VM qui tournait avec une RedHat 9, Linux 2.4.20 (si si !), et lors du passage de VMWare 4 en VMWare 5, nous avions rencontré de très grosses latences globales, qui au final était dues à une mauvais “dialogue” entre le driver SCSI du système et le contrôleur SCSI VMWare.
Du coup, même si aucune incompatibilité entre VMWare 5.5 et Debian 8 n’est clairement affichée, on va downgrader le serveur pour être sûr d’avoir un système supporté.
Le test suivant sera de mettre le serveur directement sur internet pour s’affranchir de tout équipement réseau intermédiaire.
Et non, le problème n’est vraiment pas simple
Je te tiendrai informé de la suite des événements.
Après analyse par nos équipes, le problème était lié à l’IP du serveur, pour laquelle des règles (firewall ?) bloquait le débit.
En faisant un rebond de ce serveur vers un autre avant de sortir, tout fonctionnait normalement. Problème réseau donc !
)