Saturation Mémoire physique jusqu'au crash

Support Debian
#1

Bonjour,

Sur un PC i386 AMD3800+/1GB RAM/Debian Lenny:

Serveur de messagerie (Postfix, Spamassassin, PostGrey, Clamav) - partitions codées (Luks - y compris Swap) - RAID 1 logiciel (2 HDD 80GB SATA)

Très faible charge (serveur perso; 2 BAL)

–> Le taux d’occupation de la mémoire physique augmente jusqu’à saturation, et crash avec obligation de hard reboot. :confused:

Quel processus pourrait être incriminé ?

Comment investiguer efficacement dans les logs a posteriori pour un dépistage de panne sur l’historique ?

Merci par avance.

#2

Regarde avec un top ce qui prend la mémoire, tu as un processus qui a une fuite mémoire visiblement.unionfs-utils

#3

Voilà ce que retourne un ‘top’ trié par taux d’occupation mémoire :

(après 12h de prod!)

Tasks: 105 total,   2 running, 103 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:    906556k total,   646568k used,   259988k free,   115588k buffers
Swap:  2923808k total,        0k used,  2923808k free,   251380k cached

  PID  PPID    TIME+  %CPU %MEM  PR  NI S  VIRT SWAP  RES  UID COMMAND
 3739     1   0:09.70  0.0  7.8  18   0 S 82556  11m  68m  106 clamd
 3737  3431   0:05.37  0.0  3.8  15   0 S 36828 2608  33m 1002 spamd
 3738  3431   0:00.50  0.0  3.2  15   0 S 31928 2500  28m 1002 spamd
 3431     1   0:00.31  0.0  3.1  15   0 S 30412 2624  27m    0 spamd
 3426  3422   0:00.56  0.0  2.8  16   0 S 31420 6456  24m  107 amavisd-new
 3425  3422   0:00.66  0.0  2.7  16   0 S 31416 6512  24m  107 amavisd-new
 3422     1   0:00.02  0.0  2.6  18   0 S 29732 5780  23m  107 amavisd-new
 5834  4139   0:00.73  0.0  1.3  15   0 S 24412  12m  11m   33 apache2
 4799  4139   0:00.78  0.0  1.2  15   0 S 24180  12m  10m   33 apache2
 4797  4139   0:00.65  0.0  1.2  15   0 S 24660  13m  10m   33 apache2
 4798  4139   0:00.69  0.0  1.2  15   0 S 23860  13m  10m   33 apache2
 4801  4139   0:00.81  0.0  1.0  15   0 S 22060  12m 9112   33 apache2
 5823  4139   0:00.81  0.0  1.0  15   0 S 22076  12m 9112   33 apache2
 4800  4139   0:00.05  0.0  1.0  15   0 S 22812  13m 8796   33 apache2
#4

Continue de surveiller mais je me demande si tu n’as pas eu affaire à un afflux de spam qui a entrainé une progusion de processus spamassassin et de clamav. As tu jeter un oeil dans les logs de ton serveurs de courrier à l’heure du crash? Ces logs n’ont rien dit?

#5

Question naïve : c’est normal qu’il y ait autant de processus “apache2” ? leur nombre ne croit pas avec le temps par hasard ?(j’en sais fichtre rien mais bon autant de apache2 comme ca ca m’a l’air étrange)

#6

Je m’étonne aussi de la présence de ces instances apache2 multiples; je vais vérifier leur prolifération éventuelle.

Un ps -aux ne relève aucun point saillant, mais une multitude de processus finalement peu consommateurs de ressources mémoire pris individuellement ou même par groupes…

Je ne vois pas ce qui peut provoquer cet élévation progressive et inéluctable du taux d’occupation de la mémoire physique.

Je vais auditer…

Pour ce qui est des attaques Spam, je sais que je n’ai rien eu à déplorer dans ce domaine récemment.

Existe-t-il un outil d’audit de la mémoire capable de suivre dans le temps l’état et de produire des logs/stats/grafs?

Merci.

#7

pour les apaches c’est normal, ils lancent un certain nombre de processus dès le début (défaut 8) pour être rapide à la réponse.

Je te suggère de faire un script genre

#!/bin/sh
while /bin/true ; do
ps axv >> /var/logmemoire
sync
sleep 300
done

et de le lancer en tache de fond

#8

OK bien vu le script; je vais tenter.

Du reste, je note toujours le même phénomène, mais pas de prolifération de processus en particulier… ni d’enflement remarquable de l’un d’entre eux.

Est-ce que 1GB vous semble une taille mémoire acceptable pour faire tourner ces services : postfix/spamassassin/postgrey/clamav/amavis
courier-imapd/apache2/procmail/fetchmail/ssh

? (sachant que moins de 100 mails transitent par le serveur/jour)…

Merci.

#9

reste que de “chiffrer” le swap … Pas un peut parano, non ?

#10

Ca fait partie du cahier des charges … Toutefois, la SWAP n’est que très rarement utilisée, sachant que la MP est utilisée en permanence à 80/90%

#11

C’est largement suffisant, j’ai 4 fois moins de mémoie pour 10 fois plus de mails + Web avec 1 million de hits par an + ssh + pop3

[quote] 17:03:09 up 156 days, 2:57, 5 users, load average: 2.37, 1.49, 0.89
96 processes: 92 sleeping, 4 running, 0 zombie, 0 stopped
CPU states: 98.1% user, 1.9% system, 0.0% nice, 0.0% idle
Mem: 256992K total, 252392K used, 4600K free, 3916K buffers
Swap: 326028K total, 133564K used, 192464K free, 69836K cached

PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND
21854 root 14 0 58244 56M 1016 R 48.4 22.6 1:08 clamscan
21864 root 15 0 58496 57M 1016 R 48.4 22.7 1:08 clamscan
21884 root 15 0 1116 1116 888 R 2.3 0.4 0:00 top
21673 francois 9 0 2052 2008 1816 S 0.3 0.7 0:00 sshd
[/quote]

Par contre, j’ai du limiter le nombre de fils de spamassassin à 3 et d’instance de clamscan à 2 (c’est surtout ça qui est important). Il arrive qu’il y ait une file d’attente d’une dizaine de mails voire plus dans exiscan mais la machine (Celeron 300Mhz) n’est pas à genoux. Tu peux voir une gestion de crise (des dizaines de millers de mails en flux permanent sur 3 jours) ici: http://forum.debian-fr.org/viewtopic.php?f=1&t=12016

[edit: Hum, j’augmente un peu le swap qd même, tiens…]