Bonjour
Merci pour le conseil, je vais mesurer l'updatedb en particulier, même
si l'accounting ne rapporte que 500 MiB de lecture et 35 MiB
d'écriture.
Reste la question du volume IO reporté pour run-parts et cron...
Yves
On Thu, 2019-07-04 at 09:48 +0200, Patrice Karatchentzeff wrote:
> 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
