Salut,
C'est ton updatedb. Il lit tout le disque et archive un ls -lR
général. En général, ça met à genoux une machine en I/O. Décale-le à
une heure moins gênante.
PK
Le jeu. 4 juil. 2019 à 09:43, Yves Martin <ymartin59@???> a écrit :
>
> Bonjour
>
> Des utilisateurs d'un autre fuseau horaire se sont plaint de lenteurs
> observées sur une application tournant sur Debian (9.9) entre 6h et 7h
> CEST, ce qui me fait bien entendu penser au "cron.daily" de 6h25.
>
> Le monitoring à 5 minutes montre bien une pointe à 70% à 6h30 (comparé
> à 5% à 6h25 et 10% à 6h35) et environ ~ 5000 pages en "swap out" et un
> load average à 3 sur 4 vCPUs - pas de quoi fouetter un chat.
>
> Je tourne "atop" dont je récupère le fichier du jour dans /var/log/atop
> et la seule "spécialité" que je trouve après avoir parcouru toutes les
> mesures, c'est la consommation "disque" de "run-parts" et "cron" !!
>
> Extrait à 06:30
> PID TID RDDSK WRDSK WCANCL DSK CMD
> 1171 - 540.5M 190.8M 1688K 45% run-parts
> 1366 - 517.4M 34280K 0K 34% updatedb.mloca
>
> Extrait à 06:40
> 547 - 1.2G 268.9M 1688K 63% cron
> €€€€€€
>
> Je comprendrais si je voyais logrotate, gzip... mais comment diable
> cron et run-parts ont bien pu lire 1.7 GiB et écrire 450 MiB en ~15
> minutes ?!?
>
> Merci d'avance pour vos lumières
> Cordialement,
> --
> Yves Martin
>
>
>
--
|\ _,,,---,,_ Patrice KARATCHENTZEFF
ZZZzz /,`.-'`' -. ;-;;,_ mailto:patrice.karatchentzeff@gmail.com
|,4- ) )-,_. ,\ ( `'-'
'---''(_/--' `-'\_)
