Dernièrement, j'ai remarqué des entrées comme celle-ci dans le kern.log
d'un de mes serveurs:
Feb 16 00:24:05 aramis kernel: swapper: page allocation failure. order:0, mode:0x20
J'aimerais savoir:
L'utilisation de swap est assez faible (moins de 10%), et jusqu'à présent, je n'ai remarqué aucun processus tué en raison d'un manque de mémoire.
Information additionnelle:
bogue Debian 666021 semble être un rapport de ce même problème. La suggestion est la suivante:
#change value for this boot
sysctl -w vm.min_free_kbytes=65536
#change value for subsequent boots
echo "vm.min_free_kbytes=65536" >> /etc/sysctl.conf
http://russ.garrett.co.uk/2009/01/01/linux-kernel-tuning/ explique comment modifier ce paramètre peut être utile, reproduit ici:
Cela indique au noyau d’essayer de garder 64 Mo de RAM libre à tout moment. C’est utile dans deux cas principaux:
Machines sans échange, où vous ne voulez pas que le trafic réseau entrant submerge le noyau et force un MOO avant qu'il n'ait le temps de vider les tampons.
machines x86, pour la même raison: l'architecture x86 ne permet que DMA transfère en dessous d'environ 900 Mo de RAM. Vous pouvez donc vous retrouver avec la situation bizarre d'une erreur OOM avec des tonnes de RAM gratuit.
J'ai appliqué ce paramètre sur ma machine x86 3.2.12-gentoo, mais je reçois toujours ces erreurs.
Il peut également être utile de vérifier vm.zone_reclaim_mode
: voir http://www.kernel.org/doc/Documentation/sysctl/vm.txt
Je viens de résoudre cette erreur sur un Lenovo NAS exécutant Debian 5 et le noyau 2.6.39.3 64 bits.
Les messages sont informatifs malgré leur aspect effrayant, selon https://www.novell.com/support/kb/doc.php?id=70028
Cependant, ils remplissaient ma partition racine très limitée (cet appareil a une partition racine de 50 Mo?!)
La solution pour moi était de définir vm.min_free_kbytes
de 65536
jusqu'à 16384
.
Par la suite, le système d'exploitation dispose toujours de 107 Mo de mémoire libre et de 2 Go de tampons. Cela n'a aucun sens, mais cela a arrêté toute la journalisation.