Solution 1 :
Je viens de regarder le vidage du journal oom et je remets en question l'exactitude de ce graphique. Remarquez la première ligne 'Node 0 DMA32'. Il est écrit free:3376kB , min:3448kB , et low:4308kB . Chaque fois que la valeur libre tombe en dessous de la valeur basse, kswapd est censé commencer à échanger des éléments jusqu'à ce que cette valeur revienne au-dessus de la valeur haute. Chaque fois que free tombe en dessous de min, le système se fige jusqu'à ce que le noyau le récupère au-dessus de la valeur min. Ce message indique également que l'échange a été complètement utilisé là où il est écrit Free swap = 0kB .
Donc, fondamentalement, kswapd s'est déclenché, mais le swap était plein, donc il ne pouvait rien faire, et la valeur pages_free était toujours inférieure à la valeur pages_min, donc la seule option était de commencer à tuer les choses jusqu'à ce qu'il puisse récupérer pages_free.
Vous avez définitivement manqué de mémoire.
http://web.archive.org/web/20080419012851/http://people.redhat.com/dduval/kernel/min_free_kbytes.html a une très bonne explication de la façon dont cela fonctionne. Voir la section "Mise en œuvre" en bas.
Solution 2 :
Débarrassez-vous du script drop_caches. En outre, vous devez publier les parties pertinentes de votre dmesg et /var/log/messages sortie montrant les messages OOM.
Pour arrêter ce comportement, cependant, je vous recommande d'essayer ce sysctl accordable. Il s'agit d'un système RHEL/CentOS 6 et fonctionne clairement avec des ressources limitées. Est-ce une machine virtuelle ?
Essayez de modifier /proc/sys/vm/nr_hugepages et voir si les problèmes persistent. Cela pourrait être un problème de fragmentation de la mémoire, mais voyez si ce paramètre fait une différence. Pour rendre le changement permanent, ajoutez vm.nr_hugepages = value à votre /etc/sysctl.conf et exécutez sysctl -p pour relire le fichier de configuration...
Voir également :Interpréter les messages d'"échec d'allocation de page" du noyau crypté
Solution 3 :
Il n'y a pas de données disponibles sur le graphique à partir du moment où le tueur de MOO démarre jusqu'à ce qu'il se termine. Je crois que dans le laps de temps où le graphique est interrompu, la consommation de mémoire augmente et il n'y a plus de mémoire disponible. Sinon, le tueur OOM ne serait pas utilisé. Si vous regardez le graphique de la mémoire libre après l'arrêt du tueur de MOO, vous pouvez voir qu'il descend à partir d'une valeur plus élevée qu'avant. Au moins, il a fait son travail correctement, libérant de la mémoire.
Notez que votre espace d'échange est presque entièrement utilisé jusqu'au redémarrage. Ce n'est presque jamais une bonne chose et un signe certain qu'il reste peu de mémoire libre.
La raison pour laquelle il n'y a pas de données disponibles pour cette période particulière est que le système est trop occupé par d'autres choses. Les valeurs "amusantes" dans votre liste de processus peuvent n'être qu'un résultat, pas une cause. Ce n'est pas inconnu.
Vérifiez /var/log/kern.log et /var/log/messages, quelles informations pouvez-vous y trouver ?
Si la journalisation s'est également arrêtée, essayez d'autres choses, videz la liste des processus dans un fichier toutes les secondes environ, de même que les informations sur les performances du système. Exécutez-le avec une priorité élevée afin qu'il puisse toujours faire son travail (espérons-le) lorsque la charge augmente. Bien que si vous n'avez pas de noyau préemptif (parfois indiqué comme un noyau "serveur"), vous n'aurez peut-être pas de chance à cet égard.
Je pense que vous constaterez que le ou les processus qui utilisent le plus de CPU% au moment où vos problèmes commencent en sont la cause. Je n'ai jamais vu rsyslogd ni mysql se comporter de cette façon. Les coupables les plus probables sont les applications Java et les applications pilotées par l'interface graphique telles qu'un navigateur.