Probleme de ralentissement a répétition

Support Debian
#1

Bonjour,

Je vais commencer par présenter la machine :
C’est un serveur LAMP (donc une machine distante) tournant sous Squeeze. Le kernel est le suivant 2.6.32-5-686-bigmem. Il y a des services en plus, comme un serveur de jeu, une application vocale un serveur de mail, et quelques systèmes de supervision.

Le problème est le suivant, il y a de très gros ralentissement (une espèce de freeze de plusieurs secondes) qui provoquent la coupure de beaucoup de connexions actives sur le serveur (tant sur le jeu, que sur des téléchargements gérés par apache).

M’étant mis à la recherche d’une solution, dans les fichier /var/log/error j’ai constaté un nombre faramineux de ceci:

Oct 29 08:17:01 ****.dedibox.fr kernel: [11952075.267691] audit(:0): major=252 name_count=0: freeing multiple contexts (1) Oct 29 08:17:01 ****.dedibox.fr kernel: [11952075.267736] audit(:0): major=340 name_count=0: freeing multiple contexts (2) Oct 29 08:17:01 ****.dedibox.fr kernel: [11952075.267779] audit(:0): major=340 name_count=0: freeing multiple contexts (3) Oct 29 08:17:01 ****.dedibox.fr kernel: [11952075.269026] audit(:0): major=340 name_count=0: freeing multiple contexts (4) Oct 29 08:17:01 ****.dedibox.fr kernel: [11952075.269070] audit(:0): major=340 name_count=0: freeing multiple contexts (5) Oct 29 08:17:01 ****.dedibox.fr kernel: [11952075.269112] audit(:0): major=340 name_count=0: freeing multiple contexts (6) Oct 29 08:17:01 ****.dedibox.fr kernel: [11952075.269158] audit(:0): major=340 name_count=0: freeing multiple contexts (7) Oct 29 08:17:01 ****.dedibox.fr kernel: [11952075.269201] audit(:0): major=340 name_count=0: freeing multiple contexts (8) Oct 29 08:17:01 ****.dedibox.fr kernel: [11952075.269244] audit(:0): major=340 name_count=0: freeing multiple contexts (9) Oct 29 08:17:01 ****.dedibox.fr kernel: [11952075.269287] audit(:0): major=340 name_count=0: freeing multiple contexts (10) Oct 29 08:17:01 ****.dedibox.fr kernel: [11952075.269330] audit(:0): major=340 name_count=0: freeing multiple contexts (11) Oct 29 08:17:01 ****.dedibox.fr kernel: [11952075.269373] audit(:0): major=340 name_count=0: freeing multiple contexts (12) Oct 29 08:17:01 ****.dedibox.fr kernel: [11952075.269417] audit(:0): major=340 name_count=0: freeing multiple contexts (13) Oct 29 08:17:01 ****.dedibox.fr kernel: [11952075.269460] audit(:0): major=340 name_count=0: freeing multiple contexts (14) Oct 29 08:17:01 ****.dedibox.fr kernel: [11952075.269503] audit(:0): major=340 name_count=0: freeing multiple contexts (15) Oct 29 08:17:01 ****.dedibox.fr kernel: [11952075.269546] audit(:0): major=340 name_count=0: freeing multiple contexts (16) Oct 29 08:17:01 ****.dedibox.fr kernel: [11952075.269589] audit(:0): major=340 name_count=0: freeing multiple contexts (17) Oct 29 08:17:01 ****.dedibox.fr kernel: [11952075.269632] audit(:0): major=340 name_count=0: freeing multiple contexts (18) Oct 29 08:17:01 ****.dedibox.fr kernel: [11952075.269675] audit(:0): major=340 name_count=0: freeing multiple contexts (19) Oct 29 08:17:01 ****.dedibox.fr kernel: [11952075.269718] audit(:0): major=340 name_count=0: freeing multiple contexts (20) Oct 29 08:17:01 ****.dedibox.fr kernel: [11952075.269761] audit(:0): major=340 name_count=0: freeing multiple contexts (21) Oct 29 08:17:01 ****.dedibox.fr kernel: [11952075.269805] audit(:0): major=340 name_count=0: freeing multiple contexts (22) Oct 29 08:17:01 ****.dedibox.fr kernel: [11952075.269848] audit(:0): major=340 name_count=0: freeing multiple contexts (23) Oct 29 08:17:01 ****.dedibox.fr kernel: [11952075.269891] audit(:0): major=340 name_count=0: freeing multiple contexts (24) Oct 29 08:17:01 ****.dedibox.fr kernel: [11952075.269934] audit(:0): major=340 name_count=0: freeing multiple contexts (25) Oct 29 08:17:01 ****.dedibox.fr kernel: [11952075.269977] audit(:0): major=340 name_count=0: freeing multiple contexts (26) Oct 29 08:17:01 ****.dedibox.fr kernel: [11952075.270020] audit(:0): major=340 name_count=0: freeing multiple contexts (27) Oct 29 08:17:01 ****.dedibox.fr kernel: [11952075.270063] audit(:0): major=340 name_count=0: freeing multiple contexts (28) Oct 29 08:17:01 ****.dedibox.fr kernel: [11952075.270106] audit: freed 28 contexts

Je ne suis pas sur que ce soit la cause de tous ces ralentissement, mais j’ai quand même constaté que c’était déclenché par exemple par l’exécution de commandes via cron (mais pas seulement malheureusement).

Mon problème n’est peut être pas lié à debian, mais je ne m’en sors pas pour identifier l’origine du problème.

Merci d’avance pour tout (et pour le reste aussi).

#2

bonjour,
utilise top ou htop pour voir ce qui monopolise les ressources pendant le freeze (CPU et mémoire)

#3

Quel jeux :think: ?

#4

le jeu est ragnarok.
j’ai lancé atop (pas trouvé de manière simple pour que top se log dans un fichier).

Cependant, j’ai munin (je l’ai désactivé, vu qu’il utilise cron) comme système de supervision (processus, mémoire, “réseaux”, accès au disque). Mais il n’y avait apparemment rien de significatif.

#5

En faisant une recherche sous les termes “freeing multiple contexts audit”, je suis tombé sur ce texte :

[quote]hi,

The motivation behind the patch below was to address messages in
/var/log/messages such as:

Jan 31 10:54:15 mets kernel: audit(:0): major=252 name_count=0: freeing
multiple contexts (1)
Jan 31 10:54:15 mets kernel: audit(:0): major=113 name_count=0: freeing
multiple contexts (2)

I can reproduce by running ‘get-edid’ from:
john.fremlin.de/programs/linux/read-edid/.

These messages come about in the log b/c the vm86 calls do not exit via
the normal system call exit paths and thus do not call
’audit_syscall_exit’. The next system call will then free the context for
itself and for the vm86 context, thus generating the above messages. This
patch addresses the issue by simply adding a call to 'audit_syscall_exit’
from the vm86 code.[/quote]

Source : redhat.com/archives/linux-a … 00092.html

Autrement dit, tu as une application qui fait un appel système et qui devrait le quitter en utilisant la commande “audit_syscall_exit”, mais elle ne le fait pas. Donc les threads s’accumulent, consomment de plus en plus de mémoire vive, et lorsqu’un appel à la commande “audit_syscall_exit” est fait, elle purge tous les threads encore ouverts. Donc effectivement si tu as énormément de threads ouverts, il n’est pas impossible que lors de l’appel à cette fonction le système rame un peu le temps qu’il purge tout.

Il faudrait essayer de trouver d’où vient ce problème. Dans le post que j’ai trouvé ça vient de “vm86” qui est un programme qui fournit un support pour faire des appels x86 en mode réel. Comme tu utilises un noyau 686-bigmem, il n’est pas impossible qu’il y ait un bug à ce niveau là. J’imagine qu’avec un noyau 686 classique ou x64 ce problème pourrait disparaître.
J’imagine que ça peut également venir d’une machine virtuelle, je n’en serais pas étonné.

Il serait bon de faire un rapport de bug. L’idéal serait de trouver au moins l’application qui fait ces appels systèmes, ça permettrait de délimiter le problème.

Je pense qu’en attendant, pour résoudre ton problème, tu pourrais essayer de créer un petit programme qui ferait appel à la fonction “audit_system_exit” que tu appellerais chaque minute à l’aide de “cron”, histoire de purger ton système très régulièrement et donc de ne plus avoir ces ralentissements.

D’ailleurs, est-ce que les horodatages des messages “freeing multiple contexts” sont rapprochés ? Si oui alors on risque de ne pas pouvoir résoudre le problème en faisant un simple appel régulier à la fonction “audit_system_exit”. :confused:

#6

Oui cluxter, j’avais trouvé ceci, mais je n’en avais pas compris les tenants et les aboutissants. Donc en gros ce que ça m’indique c’est que ça n’est pas la cause, mais plutôt les effet du à un problème de thread qui ne se ferment pas?

Le problème c’est que en regardant ce que j’ai log via atop (avant pendant et après), il n’y a pas de mémoire libéré. (si vous voulez j’ai plusieurs autres log, mais il n’y a rien de plus)

Je vais tester la solution que tu propose et voir si il y a moyen de la mettre en oeuvre. Même si lorsque je en désactive pas certains systèmes, j’ai un cron qui se lance toutes les 3 minutes et qui vide la mémoire chaque fois.

Ps: je concède que sur les “log”, apache est lancé de nombreuses fois, je vais en vérifier la configuration. Par contre, pour ce qui est de sa sécurisation (par exemple slow lorris qui pourrais justement causer les effets présents), je suis au point.

2s avant

[code]ATOP - **** 2011/10/31 13:16:59 1 seconds elapsed
PRC | sys 0.03s | user 0.03s | #proc 181 | #zombie 0 | #exit 0 |
CPU | sys 1% | user 3% | irq 0% | idle 398% | wait 0% |
cpu | sys 1% | user 1% | irq 0% | idle 98% | cpu000 w 0% |
cpu | sys 0% | user 1% | irq 0% | idle 99% | cpu002 w 0% |
CPL | avg1 0.00 | avg5 0.00 | avg15 0.00 | csw 2100 | intr 1438 |
MEM | tot 3.9G | free 123.5M | cache 2.9G | buff 18.9M | slab 38.0M |
SWP | tot 8.0G | free 7.9G | | vmcom 7.2G | vmlim 9.9G |
NET | transport | tcpi 476 | tcpo 243 | udpi 82 | udpo 232 |
NET | network | ipi 560 | ipo 477 | ipfrw 0 | deliv 558 |
NET | eth0 0% | pcki 548 | pcko 1056 | si 332 Kbps | so 8338 Kbps |
NET | lo ---- | pcki 8 | pcko 8 | si 6 Kbps | so 6 Kbps |

PID SYSCPU USRCPU VGROW RGROW RDDSK WRDSK ST EXC S CPU CMD 1/5
28084 0.01s 0.01s 0K 0K 0K 0K – - S 2% ts3server_linu
31932 0.02s 0.00s 0K 0K 0K 12K – - R 2% atop
23127 0.00s 0.01s 0K 0K 0K 0K – - S 1% apache2
32021 0.00s 0.01s 0K 0K 0K 0K – - S 1% map-server_sql
23116 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
23370 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
23125 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
23118 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
23110 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
26153 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
23586 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
26155 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
25034 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
28297 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
26159 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
23112 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
26151 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
26157 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
24787 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
31302 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
23129 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
31860 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
31858 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
26163 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
23372 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
31856 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
31862 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
31864 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
31866 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
31868 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
23102 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
8263 0.00s 0.00s 0K 0K 0K 0K – - S 0% mysqld
20047 0.00s 0.00s 0K 0K 0K 0K – - S 0% named
7111 0.00s 0.00s 0K 0K 0K 0K – - S 0% lfd
3903 0.00s 0.00s 0K 0K 0K 0K – - S 0% char-server_sq
30287 0.00s 0.00s 0K 0K 0K 0K – - S 0% bash
21682 0.00s 0.00s 0K 0K 0K 0K – - S 0% bash
21785 0.00s 0.00s 0K 0K 0K 0K – - S 0% bash
30395 0.00s 0.00s 0K 0K 0K 0K – - S 0% bash
27610 0.00s 0.00s 0K 0K 0K 0K – - S 0% atop
476 0.00s 0.00s 0K 0K 0K 0K – - S 0% miniserv.pl
30281 0.00s 0.00s 0K 0K 0K 0K – - S 0% sshd
4763 0.00s 0.00s 0K 0K 0K 0K – - S 0% miniserv.pl
21676 0.00s 0.00s 0K 0K 0K 0K – - S 0% sshd
[/code]

Pendant

[code]ATOP - **** 2011/10/31 13:17:01 1 seconds elapsed
PRC | sys 0.02s | user 0.03s | #proc 181 | #zombie 0 | #exit 0 |
CPU | sys 1% | user 2% | irq 1% | idle 396% | wait 0% |
cpu | sys 0% | user 2% | irq 1% | idle 97% | cpu000 w 0% |
cpu | sys 1% | user 0% | irq 0% | idle 99% | cpu002 w 0% |
CPL | avg1 0.00 | avg5 0.00 | avg15 0.00 | csw 1861 | intr 1468 |
MEM | tot 3.9G | free 123.4M | cache 2.9G | buff 18.9M | slab 38.0M |
SWP | tot 8.0G | free 7.9G | | vmcom 7.2G | vmlim 9.9G |
NET | transport | tcpi 507 | tcpo 250 | udpi 24 | udpo 24 |
NET | network | ipi 531 | ipo 273 | ipfrw 0 | deliv 530 |
NET | eth0 0% | pcki 491 | pcko 838 | si 258 Kbps | so 8492 Kbps |
NET | lo ---- | pcki 9 | pcko 9 | si 495 Kbps | so 495 Kbps |

PID SYSCPU USRCPU VGROW RGROW RDDSK WRDSK ST EXC S CPU CMD 1/5
32021 0.01s 0.02s 0K 0K 0K 0K – - S 3% map-server_sql
31932 0.01s 0.01s 0K 0K 0K 8K – - R 2% atop
23116 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
23370 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
23125 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
23118 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
23110 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
26153 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
23586 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
26155 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
25034 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
28297 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
26159 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
23112 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
26151 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
23127 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
26157 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
24787 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
31302 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
23129 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
31860 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
31858 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
26163 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
23372 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
31856 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
31862 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
31864 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
31866 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
31868 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
23102 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
8263 0.00s 0.00s 0K 0K 0K 0K – - S 0% mysqld
28084 0.00s 0.00s 0K 0K 0K 0K – - S 0% ts3server_linu
20047 0.00s 0.00s 0K 0K 0K 0K – - S 0% named
7111 0.00s 0.00s 0K 0K 0K 0K – - S 0% lfd
3903 0.00s 0.00s 0K 0K 0K 0K – - S 0% char-server_sq
30287 0.00s 0.00s 0K 0K 0K 0K – - S 0% bash
21682 0.00s 0.00s 0K 0K 0K 0K – - S 0% bash
21785 0.00s 0.00s 0K 0K 0K 0K – - S 0% bash
30395 0.00s 0.00s 0K 0K 0K 0K – - S 0% bash
27610 0.00s 0.00s 0K 0K 0K 0K – - S 0% atop
476 0.00s 0.00s 0K 0K 0K 0K – - S 0% miniserv.pl
30281 0.00s 0.00s 0K 0K 0K 0K – - S 0% sshd
4763 0.00s 0.00s 0K 0K 0K 0K – - S 0% miniserv.pl
21676 0.00s 0.00s 0K 0K 0K 0K – - S 0% sshd[/code]

2s après

[code]ATOP - **** 2011/10/31 13:17:03 1 seconds elapsed
PRC | sys 0.03s | user 0.05s | #proc 181 | #zombie 0 | #exit 0 |
CPU | sys 2% | user 2% | irq 1% | idle 394% | wait 1% |
cpu | sys 1% | user 2% | irq 2% | idle 94% | cpu000 w 1% |
cpu | sys 2% | user 0% | irq 0% | idle 98% | cpu002 w 0% |
cpu | sys 0% | user 2% | irq 0% | idle 98% | cpu003 w 0% |
CPL | avg1 0.00 | avg5 0.00 | avg15 0.00 | csw 1892 | intr 1418 |
MEM | tot 3.9G | free 123.2M | cache 2.9G | buff 18.9M | slab 38.0M |
SWP | tot 8.0G | free 7.9G | | vmcom 7.2G | vmlim 9.9G |
DSK | sda | busy 0% | read 0 | write 40 | avio 0 ms |
NET | transport | tcpi 480 | tcpo 243 | udpi 42 | udpo 42 |
NET | network | ipi 525 | ipo 285 | ipfrw 0 | deliv 521 |
NET | eth0 0% | pcki 526 | pcko 838 | si 308 Kbps | so 8318 Kbps |
NET | lo ---- | pcki 19 | pcko 19 | si 16 Kbps | so 16 Kbps |

PID SYSCPU USRCPU VGROW RGROW RDDSK WRDSK ST EXC S CPU CMD 1/5
28084 0.01s 0.01s 0K 0K 0K 0K – - S 2% ts3server_linu
31932 0.02s 0.00s 0K 0K 0K 12K – - R 2% atop
23112 0.00s 0.01s 0K 952K 0K 0K – - S 1% apache2
24787 0.00s 0.01s 0K 4K 0K 0K – - S 1% apache2
32021 0.00s 0.01s 0K 0K 0K 0K – - S 1% map-server_sql
8263 0.00s 0.01s 0K 0K 0K 0K – - S 1% mysqld
23116 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
23370 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
23125 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
23118 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
23110 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
26153 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
23586 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
26155 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
25034 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
28297 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
26159 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
26151 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
23127 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
26157 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
31302 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
23129 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
31860 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
31858 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
26163 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
23372 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
31856 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
31862 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
31864 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
31866 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
31868 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
23102 0.00s 0.00s 0K 0K 0K 0K – - S 0% apache2
20047 0.00s 0.00s 0K 0K 0K 0K – - S 0% named
7111 0.00s 0.00s 0K 0K 0K 0K – - S 0% lfd
3903 0.00s 0.00s 0K 0K 0K 0K – - S 0% char-server_sq
30287 0.00s 0.00s 0K 0K 0K 0K – - S 0% bash
21682 0.00s 0.00s 0K 0K 0K 0K – - S 0% bash
21785 0.00s 0.00s 0K 0K 0K 0K – - S 0% bash
30395 0.00s 0.00s 0K 0K 0K 0K – - S 0% bash
27610 0.00s 0.00s 0K 0K 0K 0K – - S 0% atop
476 0.00s 0.00s 0K 0K 0K 0K – - S 0% miniserv.pl
30281 0.00s 0.00s 0K 0K 0K 0K – - S 0% sshd[/code]

#7

Salut,

Processus qui tournes …

:~$ ps ax --sort -vsz | head
Le processus donné en premier sera le coupable.

Afficher le mémoire utilisée …

Classement des processus par nombre de fichier ouvert …

#8

A mon avis, ce n’est pas parce qu’un processus consomme le plus de mémoire, que c’est forcément anormal. C’est plutôt le fait de vider une certaine quantité de mémoire “anormale” qui devrait poser problème. Même si sur les log indiqués, il n’y a rien a ce propos.

Mais merci pour la commande qui indique le nombre de fichier ouvert par processus.

#9

Rien d’anormal dans tes logs.
Le CPU n’est pas vraiment en surcharge!
Ni la mémoire.
Ce ne serais pas un pb de système de fichier. Par ex une synchro entre les disques physique et la mémoire cache ?

#10

Il va falloir être plus explicite sur ça. Je ne vois pas trop comment vérifier ça et ce que ça provoque.
J’avais aussi monitoré les accès disque via munin, mais … ben rien.

#11

quelques explications ici
linuxquestions.org/questions … an-606518/

#12

J’ai vidé le cache, il s’est petit a petit rechargé, mais les lag et les logs ont sont toujours inchangé :12

Suite a quelques recherches, j’ai identifié un processus zombie (relativement peu important). mais ça n’étais pas à l’origine du problème.

#13

Bien au final une réinstallation du système à “résolu” ce problème.
Merci de votre aide.