Consommation mémoire

Bonjour,

J’ai mis à jour nos deux serveurs BM hier soir en dernière version. Au passage petit bug d’affichage ? La version est la 3.0.9, la 3.0.10 ne s’est pas installée.

J’ai un pic mémoire depuis le redémarrage du serveur hier alors que j’ai upgradé sa config : 4 coeurs, 6gb de ram.

Mon second serveur est dans la même configuration et ne rencontre pas de soucis de la sorte.

Je joins une capture de la montée de consommation mémoire.

http://pix.toile-libre.org/upload/img/1405603929.png

Y’a il un fichier de log à checker ou autre ?

Merci de votre aide.

Bonjour Manu,

et en rejouant le /setup , cela donne quoi ???

Si il est a jour, il devrait vous le dire …

Pour info, beaucoup de chose est en cache-ram pour la réactivité … . Mes divers VM ont tous 6Go de RAM, 5 Go est perpétuellement utilisé par les process Java …

Bonjour Poustiquet,

En rejouant le setup, pas de changements.
La ou je suis étonné c’est la douce montée en ram depuis la maj. J’ai un second serveur qui ne subit pas ces montées de ram.

Bon pas le même nombre d’utilisateurs mais ils ne sont qu’une petite dizaine sur le premier. Comment sont dimensionnés les serveurs comptant des centaines d’utilisateurs ?

Très surprenant …

Dans ta licence, tu as une ligne

deb http://LOGIN:PASSWD@pkg.blue-mind.net/[verison]/[distrib]/closed/ ./

Vérifie que les packages updates sont bien accessible à cette adresse à partir de ton serveur … .

Le cache local de ton système de repository doit comporter les mêmes versions que ceux du serveur …
A titre d’exemple … dans Deb , les deb téléchargés se retrouvent dans “/var/cache/apt/archives” …

Coté monté en RAM,
depuis la 3.0.8, bm-pimp a fait son apparition …
Il faudrait demander aux dev si il y a une relation dynamique sur le gestion de la ram par rapport au besoin (lancement régulier de bm-pimp par exemple …) …
Maintenant, cela ne me choque pas, j’ai aussi des variations de la RAM sur mes divers servers … (en dents de scies sur les 6 derniers mois) … Elle est là aussi pour cela !

Effectivement, un couac - possibilité de doublonnage des RDV depuis les PDA dans certaines conditions - sur la 3.0.10 nous a obligé a sortir la 3.0.11 et pour éviter que trop de monde ne soit impacté nous avons bloqué les mises à jour en 3.0.10.

La 3.0.11 est disponible depuis hier soir.

Pour la RAM, à priori, je dirais que ce n’est pas anormal. Peut-être vos utilisateurs sur le premier serveurs sont plus actifs ?
bm-pimp permet simplement d’ajuster la RAM allouée à chaque JVM en fonction de la RAM disponible sur le serveur.

La gestion de la RAM en java implique un effet palier. Dès le départ, on a besoin de pas mal de RAM (4Go minimum), mais par la suite, cette quantité n’augmente pas de façon exponentielle. On arrive a tenir avec ~500 utilisateurs sur 12Go.

Bonjour et merci pour vos réponses.

Le souci de la ram commence à se poser mais n’est pas gênant. J’ai fais un bmctl restart ce matin en arrivant et la conso mémoire à chutée, ce qui semble normal car je pense qu’elle va remonter jusqu’à se stabiliser en fonction des utilisateurs

http://pix.toile-libre.org/upload/img/1405927001.png

La ou c’est plus étrange et je ne l’avais pas vu de suite, c’est le conso CPU. J’ai profité de la mise à jour pour arrêter le serveur et y ajouter 2 coeurs. Le load average à littéralement explosé. Le bmctl restart n’a pas vraiment solutionné le souci

Sur la capture suivante on voit bien la montée en charge à partir de fin Juin (upgrade v2.0.latest vers 3.0.8) et ensuite mi-juillet, upgrade vers la 3.09. Vous auriez des idées sur l’origine possible ?

Merci.

http://pix.toile-libre.org/upload/img/1405926876.png

Combien d’utilisateurs as tu ?
Le load m’étonne beaucoup. (C’est peut-être un faux positif.)

Ci-dessous le load de l’un de mes serveurs avec 45 utilisateurs en production, connectés en permanence sur Webmail et Smartphone

http://pix.toile-libre.org/upload/img/1405929206.jpg

[PS : le load est issu d’une VM avec 4 cores - 6 Go de RAM - un datastore sur disque SATA classique]

C’est bien ça qui m’étonne oui, j’ai une quinzaine d’utilisateurs sur le serveur, encore qu’en ce moment ça doit plus être 7/8 et la charge est juste énorme.

Et rien ne m’indique ce qui charge le système ainsi. Je l’arrêterais ce soir et le redémarrerais pour voir.

Le bon vieux “top” te donne quoi ???
Je pense que ton système de stat ne garde que la tendance haute dans une période de temps…

Regarde mon graph Zabbix,
le ligne vert => le résultat du top , 90% du temps le servur ne fait rien.
Le zone jaune est la tendance => si je regarde le top , je m’aperçois bien que le load monte parfois entre 2 et 5 (en général, cela est du à l’envoi de grosse pièce jointe et leur gestion)

Bonjour Poustiquet,

Voici un top
http://pix.toile-libre.org/upload/img/1406012562.png

Aucune indication supplémentaire, enfin pas à mon niveau. On voit bien le load average est bien celui graphé dans Icinga.

La charge est élevée mais les 4 coeurs ne font rien de spécial. Peut être est ce mon plugin nagios qui est mal adapté ?

Oui vraiment bizarre ,

un load de 5 c’est invivable …

Que dit iotop ?
(je pense à un process java en boucle, j’ai déjà eu le cas sur un serveur avec un raid (logciel) cassé et en reconstruction …)

Ce qui m’étonne dans le top, c’est qu’il y a une charge de 5 (avec combien de core ?), mais 99.7% d’idle… C’est un peu antinomique tout ça…

Comme ça, je verrais bien un soucis au niveau matériel qui surchargerai le noyau. Que dit la commande dmesg ?
Si c’est une environnement virtualisé, il se peut que ce soit lié à une surcharge de la machine physique par une autre VM par exemple…

Coté virtualisation, avec un problème de disque (un raid dégradé ou en reconstruction) , les VMs ne s’en aperçoivent pas . (Proxmox sur raid Soft)

Par contre, j’ai eu les même symptômes sur un serveur physique, avec un raid logiciel dégradé. Et un collègue a eu le même problème sur un Raid matériel (LSI) sur son serveur DL380G6, non pas durant la panne de son Raid 5 mais durant la reconstruction du disque .

Ma foi, le load monte (faute à la queue I/O), mais l’applis est parfaitement stable et dynamique (vive le cache RAM) !!

Dommage, que je n’ai pas encore eu le temps de migrer mon serveur physique telegraphe.cloudma.fr sur une VM : j’aurai pu cassé le raid pour provoquer ce phénomène … . ]

Bonjour,

Les deux machines que nous possédons sont virtualisées sous Hyper-V. Une machine Ubuntu 12.04 LTS et une Debian Wheezy.

Voici un dmsg de la machine ubuntu : http://justpaste.it/gcwl Je ne veux pas pourrir le thread.

Les 2 VM on quasiment le même load, avec 4vCPU et 6Go de ram chacune.

J’ai vérifié le raid5 présent en local sur les hyperviseurs et pas de soucis en vue.

Merci pour les pistes.

Le dmesg ne dit rien de particulièrement anormal.

Votre machine physique a combien de CPU physiques (sans compter le hyperthread) ?

La machine dispose de 2 processeurs de ce type : http://ark.intel.com/fr/products/33087/Intel-Xeon-Processor-X5460-12M-Cache-3_16-GHz-1333-MHz-FSB

Donc 2 x 4 coeurs physiques et 32Go de ram. Avec 4 vm sur l’hyperviseur pour 19Go/32 de consommés.

J’ai de multiples snapshot pour la vm ayant le load le plus élevé, ça peut en être la cause, j’ai lu ci et là qu’Hyperv gérait assez mal de multiples captures instantanées.

A voir.

Possible effectivement, un de nos clients nous a remonté un peu le même problème avec leur VSphere. Si ils ont trop de snapshot en cours, ça fini par entraîner des lenteurs au niveau des VMs.

Pas de soucis coté Proxmox sur de LUN ISCSI monté en LVM, et des Storage direct …

Par contre, sur le seul serveur physique me restant, j’ai mis en Fail un des deux disques miroir de mon Raid (Logiciel) Mirroir , j’ai un Load entre 4 et 5 durant le Fail et la reconstruction …

Je n’ai pas eu le temps de mettre un place des stat plus précis sur iotop et atop, dommage. (A vrai dire, je ne pensas pas que le raid puisse se reconstruire si vite sur un serveur cours d’utilisation …

Bonsoir,

Intéressant la piste du stockage Poustiquet, ça rejoindrait indirectement l’histoire des snapshot, comme du stockage “dégradé”.

Je suis en train de passer la 3.0.11, je reboot et je vais voir.

Merci de vos indications.

Bonjour ici,

Hier soir j’ai supprimé plusieurs captures instantanées de l’hyperviseur sans réel changement.

A chaque suppression l’hyperviseur doit merger, cela prend donc beaucoup de temps. Je n’ai pas eut le temps de tout supprimer hier. Je continuerais plus tard.

Au reboot de la vm un message a attiré mon attention, j’ai pris une capture d’écran ci-dessous je ne sais pas si c’est lié (Message d’erreur NUMA)

http://pix.toile-libre.org/upload/img/1406271848.jpg