Linux avec 256 Go de mem / 48 cœurs - La machine commence à se débattre / s'étouffer avec des tonnes de mémoire restantes

Machine: Dell r815, CentOS 5.4, 256 Go de RAM, 4 x 12 cœurs.

Nous avons une application qui a un fichier de 275 Go. Il effectue un tri sur place sur 20 Go de données à la fois, c'est-à-dire qu'il échange des bits et les remplace dans le même fichier. Tout fonctionne bien.

Il y a un dernier passage qui lit ensuite tout le fichier et fait un tri de fusion sur les différents morceaux de 20 Go, et les sort dans un tout nouveau fichier.

Ce processus semble fonctionner correctement pendant un certain temps et il finit par débusquer environ 50 Go sur le disque. Quelque temps après cela, la machine ENTIÈRE commence à paniquer.

Commandes simples comme ps -ef, ls -al, accrochez depuis longtemps et apparaissent comme prenant 100% du CPU (qui est juste un noyau).

En regardant les statistiques de la mémoire top, je vois qu'il utilise environ 120 Go de RAM (donc 128 Go gratuits) et 120 Go sous la section "en cache".

Quelqu'un a-t-il déjà vu ce genre de comportement? Le même processus fonctionne bien sur une machine avec 64 Go de mémoire - donc je pense que cela est lié au montage de RAM que j'ai dans la machine.

(Au moment où nous parlons, je lance le test sur cette machine avec tout sauf 64 Go - pour exclure un problème matériel).

Suis-je peut-être absent de certains paramètres vm /etc/sysctrl.conf?

Merci!

Votre question m'a rappelé quelque chose que j'ai lu récemment:

http://jcole.us/blog/archives/2010/09/28/mysql-swap-insanity-and-the-numa-architecture/

Cela explique comment les architectures NUMA (comme vous pouvez le trouver, disons, dans un système AMD à 48 cœurs) affectent l'allocation et l'échange de mémoire. Je ne sais pas si c'est ce que vous rencontrez, mais cela semblait suffisamment similaire pour que cela vaille la peine d'être lu.

Même si ce n'est pas la réponse, cela rend la lecture fascinante.

Donc, cela semblait être un bug du noyau dans 64 bits Centos 5.4 ET 64 bits Fedora 14. Après avoir installé Centos 5.5, le problème a disparu.

Désolé, je n'ai pas de meilleure réponse pour tout le monde ...

Vous pouvez essayer d'ajouter une ligne à /etc/sysctl.conf pour spécifier que l'échange ne doit être utilisé qu'en cas de nécessité absolue.

swappiness = 0

Vous savez peut-être déjà que ce fichier définit les paramètres globaux, il est donc nécessaire de prendre en compte l'impact de cette modification sur les autres applications en cours d'exécution dans l'environnement.

Où est votre espace temporaire. C'est souvent sur tempfs. Tempfs tire son espace de la mémoire sauvegardée par l'espace de swap, donc si vous vous retrouvez avec trop de choses dans tempfs, cela déclenchera les swap I / O.

Compte tenu de la taille des données que vous fusionnez, je m'attendrais à une permutation lorsque vous atteindrez la fusion finale.

La répartition de votre stockage d'échange sur plusieurs disques peut être utile.

Bien que vous n'ayez peut-être pas recours au swap, vous pouvez toujours être lié aux E / S. L'info ls le suggère.

Je regarderais la sortie de dstat -dfpour afficher les statistiques du disque, ou dstat -af(oui, ce sera un bajillion de colonnes; c'est ce qui se passe lorsque vous avez 48 cœurs et affichez l'utilisation du processeur sur chacun d'eux) si vous voulez tout voir.

Je serais surpris si tous les CPU étaient occupés (le tri par fusion n'est pas une tâche gourmande en CPU), mais vous ne dites rien de votre système d'E / S. Si vous avez peu de disques et un tas de fichiers, vous pourriez être en train de battre le disque en cherchant chaque fichier pour garder le tri de fusion alimenté.