Plus de mémoire vive pour vp-istex-fsmap #186

Salutations,

Dans le cas de corpus volumineux à analyser (10 millions de fichiers), notre outil d'analyse se heurte violemment à la limite des 32 Go de mémoire vive du serveur vp-istex-fsmap. Le processus d'analyse s'est arrêté environ à 6 millions de fichiers. Pour être confortable, serait il possible de passer le serveur vp-istex-fsmap à 64 Go de mémoire vive ?

je dois l’arrêter, le memory hot add n'est pas actif sur cette vm.
maintenant ?

Oui, pourquoi pas. ;)

as usual un juste milieu de 48Go a été configuré ;-)

La prochaine fois, on demandera 128 Go :-D

Désolé sylvain on aurait du aller sur downloadmoreram.com avant de poster la demande :P

Je réouvre, pour de gros corpus nous en sommes là :

La capacité mémoire est la limite. Ce qui en fait un problème sans limite.
On ajoute de la mémoire et on repousse le problème un peu plus loin en espérant que ça va suffire.
Est-ce qu'il est possible de maîtriser l'application pour qu'elle ne consomme pas plus qu'un seuil donné?

La mémoire est utilisée par redis qui fait office de queue,
L'ensemble d'un corpus est chargé dans redis et traité à la volée, si on avait plus de coeurs disponibles les taches de la queue seraient traités plus rapidement et donc la memoire n'augmenterait pas tant.
L'idée de surveiller le taux d'occupation de memoire vive est bonne et nous allons nous y pencher avec pourquoi pas un système de pause/resume mais nos traitement en seront forcément bien ralentis, disons que si il y a de la memoire dormante on est preneur .

J'ai ajouté 2 Go de mémoire, pour voir.

Bonjour,

On avait un petit warning lors du démarage de redis :

"WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot"

Il semble que cette option permette une diminution de la memoire utilisée dans des cas comme le nôtre, par contre je n'ai pas les droits root pour le faire .

Il y aurait aussi un autre paramétre possible pour un redis de cette taille en production niveau cpu :

"echo '3' > /sys/class/net/eth1/queues/rx-0/rps_cpus"

Ainsi que quelques options :

net.ipv4.tcp_sack=1 # enable selective acknowledgements
net.ipv4.tcp_timestamps=1 # needed for selective acknowledgements
net.ipv4.tcp_window_scaling=1 # scale the network window
net.ipv4.tcp_congestion_control=cubic # better congestion algorythm
net.ipv4.tcp_syncookies=1 # enable syn cookied
net.ipv4.tcp_tw_recycle=1 # recycle sockets quickly
net.ipv4.tcp_max_syn_backlog=NUMBER # backlog setting
net.core.somaxconn=NUMBER # up the number of connections per port
net.core.rmem_max=NUMBER # up the receive buffer size
net.core.wmem_max=NUMBER # up the buffer size for all connections

Je pense que ce sont des options à tester, cf http://shokunin.co/blog/2014/11/11/operational_redis.html

Serait-il possible pour quelqu'un ayant les droit sudo sur cette machine de faire la premiére étape ?

C'est fait.
Le reste aussi.

Merci, je relance le programme et on vous tient au courant ;)

Quelques warnings suite aux modifications ...

Sinon, une analyse a été lancé sur le corpus Springer et, dans les logs, on peut lire ceci :

A tout hasard, est ce qu'il y a une intervention de votre coté sur le serveur vp-istex-fsmap à ce moment là ?

modification de paramètres système :
le nombre limite de fichiers ouverts est monté à 10240 (reconnexion user nécessaire)
/proc/sys/net/core/somaxconn = 512
vm.overcommit_memory = 1

Pour redis, il n'y a pas de trace d'une quelconque intervention de notre part.

Merci pour les modifications. Je relance l'analyse du corpus Springer Journals (~ 7 millions de documents) pour tester tout cela. ;)

Hello,

Toujours les même messages, l'OS semble killer le process lorsqu'il prend trop de memoire, charge à nous de lui donner une limite mais les paramètres de configuration système ne semblent pas avoir été gardés

Les paramètres sont rétablis. Ils devraient être conservés pour les prochains démarrages.

Bonjour,
On a actuellement des soucis avec l'outil d'analyse de corpus Sisyphe et on soupçonne que ce soit lié aux soucis qu'ont eu Rémy et Mattias l'an dernier.
La chaîne de traitement s'arrête sans raison apparente et le seul message d'erreur qu'on obtient est le suivant. Je pense qu'il pourraît être provoqué par un kill sauvage d'un des process NodeJS.

{ Error [ERR_IPC_CHANNEL_CLOSED]: channel closed
    at ChildProcess.target.send (internal/child_process.js:590:16)
    at Promise (/applis/istex/home/sisyphe-master/src/overseer.js:90:15)
    at Promise._execute (/applis/istex/home/sisyphe-master/node_modules/bluebird/js/release/debuggability.js:303:9)
    at Promise._resolveFromExecutor (/applis/istex/home/sisyphe-master/node_modules/bluebird/js/release/promise.js:483:18)
    at new Promise (/applis/istex/home/sisyphe-master/node_modules/bluebird/js/release/promise.js:79:10)
    at Object.Overseer.send (/applis/istex/home/sisyphe-master/src/overseer.js:89:10)
    at getPatient.then.overseer (/applis/istex/home/sisyphe-master/src/dispatcher.js:132:27)
    at tryCatcher (/applis/istex/home/sisyphe-master/node_modules/bluebird/js/release/util.js:16:23)
    at Promise._settlePromiseFromHandler (/applis/istex/home/sisyphe-master/node_modules/bluebird/js/release/promise.js:512:31)
    at Promise._settlePromise (/applis/istex/home/sisyphe-master/node_modules/bluebird/js/release/promise.js:569:18)
    at Promise._settlePromiseCtx (/applis/istex/home/sisyphe-master/node_modules/bluebird/js/release/promise.js:606:10)

Du coup, ma demande est : pourriez-vous vérifier les paramètres que vous aviez modifié à l'époque ? Il me semble qu'ils n'ont pas été conservé.

J'ai rectifié trois paramètres pour lesquels la valeur ne correspond pas à sa valeur d'initialisation.

Merci Philippe ! On va refaire un test pour voir si c'est mieux

Bon, on a toujours le problème. C'est sans doute autre chose... Je ferme l'issue
Merci en tous cas