Hello,
Tu peux aussi le virer. À part "locate" qui ne fonctionnera plus, ça
n'aura pas d'impact sur ton système.
Xav
Le jeudi 04 juillet 2019 à 10:16 +0200, Yves Martin a écrit :
> 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
>
>
