[systemd] "Out of memory"
Publié : lun. 17 févr. 2014, 12:55
Hej !
Petite mise en situation: j'ai un petit serveur chez OVH (Kimsufi basique) qui tourne sous Archlinux (64bits). Jusqu'à présent, je fais mes mises à jour régulièrement. Par contre, le noyau est celui fourni par OVH (3.2.13-xxxx-grs-ipv6-64) qui lui ne se met pas à jour via les dépôts.
Aujourd'hui, je décide de m'en occuper, et récupère la dernière version en date (toujours via OVH): 3.10.23-xxxx-grs-ipv6-64. La manip' est simple (récupérer l'image du noyau, le System.map associé et faire un grub-mkconfig). Au reboot, tout semble bien se passer, le système démarre bien sur le nouveau noyau, Apache se lance correctement, la BDD aussi... Par contre, un tour dans les logs pour vérifier que rien ne se viande en cachette m'indique ceci:
Après vérification, ce problème n'apparaissait pas avant la mise à jour du noyau.
Premier réflexe: quelle est la mémoire dispo ?
Ok, pas de souci de ce coté là...
Le disque:
Plein de place libre ici aussi. Un petit tour sur google me donne deux autres commandes à tester:
À priori mysql pompe le plus de mémoire. Mais si je ne me trompe pas, la valeur est en ko, ce qui donne donc à peu près 139Mo de consommé. Pas spécialement inquiétant donc.
Enfin:
Serait-ce un problème avec une limite donnée par le noyau ? J'en sais rien, d'où ma demande ici: qu'est ce qui ne va pas ? Surtout qu'il n'y a pas d'autre problème visible (en tout cas pour l'instant...).
Merci
Petite mise en situation: j'ai un petit serveur chez OVH (Kimsufi basique) qui tourne sous Archlinux (64bits). Jusqu'à présent, je fais mes mises à jour régulièrement. Par contre, le noyau est celui fourni par OVH (3.2.13-xxxx-grs-ipv6-64) qui lui ne se met pas à jour via les dépôts.
Aujourd'hui, je décide de m'en occuper, et récupère la dernière version en date (toujours via OVH): 3.10.23-xxxx-grs-ipv6-64. La manip' est simple (récupérer l'image du noyau, le System.map associé et faire un grub-mkconfig). Au reboot, tout semble bien se passer, le système démarre bien sur le nouveau noyau, Apache se lance correctement, la BDD aussi... Par contre, un tour dans les logs pour vérifier que rien ne se viande en cachette m'indique ceci:
Code : Tout sélectionner
Feb 17 11:50:27 ks3287976 systemd[3689]: Out of memory.
Feb 17 11:50:27 ks3287976 systemd[3689]: Failed to fully start up daemon: Cannot allocate memoryPremier réflexe: quelle est la mémoire dispo ?
Code : Tout sélectionner
free -m
total used free shared buffers cached
Mem: 1976 501 1474 1 16 205
-/+ buffers/cache: 280 1695
Swap: 513 0 513Le disque:
Code : Tout sélectionner
df -h
Filesystem Size Used Avail Use% Mounted on
/dev/root 9.8G 4.5G 4.9G 49% /
devtmpfs 988M 0 988M 0% /dev
tmpfs 989M 0 989M 0% /dev/shm
tmpfs 989M 1.5M 987M 1% /run
tmpfs 989M 0 989M 0% /sys/fs/cgroup
tmpfs 989M 4.0K 989M 1% /tmp
/dev/sda2 914G 123G 745G 15% /home
Code : Tout sélectionner
ps --sort -rss -eo rss,pid,command | head
RSS PID COMMAND
142760 3267 /usr/bin/mysqld --pid-file=/run/mysqld/mysqld.pid
16732 2091 /usr/lib/systemd/systemd-journald
13632 3481 /usr/bin/httpd -k start
13388 3479 /usr/bin/httpd -k start
12768 3722 /usr/bin/httpd -k start
11404 3724 /usr/bin/httpd -k start
11216 3474 /usr/bin/httpd -k start
11096 3465 /usr/bin/php /usr/share/webapps/tt-rss/update.php --daemon
10028 3488 /usr/bin/python2 /usr/bin/fail2ban-server -b -s /var/run/fail2ban/fail2ban.sock -p /var/run/fail2ban/fail2ban.pid -xEnfin:
Code : Tout sélectionner
ulimit -a
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 20
file size (blocks, -f) unlimited
pending signals (-i) 15802
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 1024
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 15802
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimitedMerci