IOSTAT : ça écrit d'accord, mais qui écrit sur mon disque ?

Le
Patrick
Bonjour à tous,

Je suis à la recherche du mystérieux écriveur de disque.
En effet, voici ce qui se passe sur un serveur : des écritures
"intempestives". Je copie-colle des iostat tronqués.


Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
sda 0.00 0.00 0.00 0 0
dm-0 0.00 0.00 0.00 0 0
dm-1 0.00 0.00 0.00 0 0
[]

Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
sda 2.02 0.00 44.44 0 88
dm-0 0.00 0.00 0.00 0 0
dm-1 2.02 0.00 16.16 0 32
[]

Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
sda 0.00 0.00 0.00 0 0
dm-0 0.00 0.00 0.00 0 0
dm-1 0.00 0.00 0.00 0 0

[]


Et je n'arrive pas à les tracer.
( dm-1 est le volume LVM monté sur /usr )

Un lsof ne me donne que des libs chargées par syslog, sshd
Donc, auriez-vous une idée de comment tracer qui est le process qui fait
cette écriture ? (un hook sur open() ou write() dans le noyau ça existe.. ?)

J'ai beau chercher sur google je ne trouve rien de probant.
Et je ne pense pas que ce soit une action extérieure car sinon le lv de
/var/log s'activerait aussi, pas seulement /usr.

PS: j'ai des fortes présomptions sur le fait que ce soit une lecture sur
/usr et non pas une écriture en tant que telle, et que l'écriture soit
le "atime" vu que /usr n'est pas monté en noatime

PPS: linux debian etch, toute vierge installée par debootstrap, kernel
2.6.20.7.

Patrick
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Fabien LE LEZ
Le #1906794
On Mon, 03 Dec 2007 07:41:34 +0100, Patrick :

(un hook sur open() ou write() dans le noyau ça existe.. ?)


http://inotify-tools.sourceforge.net/
http://inotify.aiken.cz/?section=incron&page«out&lang=en

Patrick
Le #1906793
On Mon, 03 Dec 2007 07:41:34 +0100, Patrick :

(un hook sur open() ou write() dans le noyau ça existe.. ?)


http://inotify-tools.sourceforge.net/
http://inotify.aiken.cz/?section=incron&page«out&lang=en



Et qui nécessite donc de faire une écoute sur chaque répertoire?

# find /usr -type d | wc -l
1022

Enfin l'algo a le mérite d'exister et de n'être pas *trop* compliqué:
http://mail.gnome.org/archives/dashboard-hackers/2004-October/msg00022.html

Et de marcher si les race-conditions à faible probabilité sont négligées:
http://mail.gnome.org/archives/dashboard-hackers/2004-October/msg00029.html


Merci pour le pointeur en tout cas.

Patrick


Matthieu Moy
Le #1906792
Patrick
On Mon, 03 Dec 2007 07:41:34 +0100, Patrick :

(un hook sur open() ou write() dans le noyau ça existe.. ?)


http://inotify-tools.sourceforge.net/
http://inotify.aiken.cz/?section=incron&page«out&lang=en



Et qui nécessite donc de faire une écoute sur chaque répertoire?


Avec dnotify, quelque chose comme :

$ dnotify . -r -e echo {}

devrait faire l'affaire (je connais pas trop dnotify, bizarement, chez
moi, si je fais ça dans / ou /usr/, je me retrouve avec une erreur
« dnotify: cannot open directory `blablabla' - Too many open files »)

--
Matthieu



Fabien LE LEZ
Le #1906791
On Mon, 03 Dec 2007 09:03:33 +0100, Matthieu Moy :

(je connais pas trop dnotify, bizarement, chez
moi, si je fais ça dans / ou /usr/, je me retrouve avec une erreur
« dnotify: cannot open directory `blablabla' - Too many open files »


Ben, c'est logique, non ?
Si tu fais ça, tu demandes à dnotify de surveiller une grande quantité
de répertoires. Il commence à mettre des hooks un peu partout, mais
au bout d'un moment, le système sature.

Lea GRIS
Le #1906788
Bonjour à tous,

Je suis à la recherche du mystérieux écriveur de disque.
En effet, voici ce qui se passe sur un serveur : des écritures
"intempestives". Je copie-colle des iostat tronqués.


Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
sda 0.00 0.00 0.00 0 0
dm-0 0.00 0.00 0.00 0 0
dm-1 0.00 0.00 0.00 0 0
[...]

Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
sda 2.02 0.00 44.44 0 88
dm-0 0.00 0.00 0.00 0 0
dm-1 2.02 0.00 16.16 0 32
[...]

Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
sda 0.00 0.00 0.00 0 0
dm-0 0.00 0.00 0.00 0 0
dm-1 0.00 0.00 0.00 0 0

[...]


Et je n'arrive pas à les tracer.
( dm-1 est le volume LVM monté sur /usr )


Chaque accès en lecture engendre une écriture pour mise à jour de
l'horodatage d'accès "atime"

Essaye de monter des disques avec l'option noatime. Les cas où on a
besoin de connaître la date d'accès en lecture à un fichier sont très
rares. Mettre cette option sauve aussi pas mal d'accès au disque et
sauve la vie des mémoires flash si tu en a de montées.

--
Léa Gris

Thierry B.
Le #1906787
--{ Lea GRIS a plopé ceci: }--

Chaque accès en lecture engendre une écriture pour mise à jour de
l'horodatage d'accès "atime"

Essaye de monter des disques avec l'option noatime. Les cas où on a
besoin de connaître la date d'accès en lecture à un fichier sont très
rares.


D'ailleurs, quels sont ces cas ? J'ai appris par la LKML que
Mutt pouvait être impacté, et de mon coté, j'ai pensé à
Leafnode...


--
Beaucoup moins que la collection de saloperies avec des options à rallonge,
et devant être aboutés avec des bidules comme les pipes et autres trucs
abracadabrantesques qui ont fait la fortune de Unix.
--{ MT, in fcol.debats }--

Patrick
Le #1906786

Chaque accès en lecture engendre une écriture pour mise à jour de
l'horodatage d'accès "atime"

Essaye de monter des disques avec l'option noatime. Les cas où on a
besoin de connaître la date d'accès en lecture à un fichier sont très
rares. Mettre cette option sauve aussi pas mal d'accès au disque et
sauve la vie des mémoires flash si tu en a de montées.


Merci merci, j'étais au courant pour le atime, Cf. le PS sur mon premier
message. Ma question était de l'ordre de "mais qui va farfouiller dans
/usr ...", pas "comment empêcher les écritures" !

Patrick

Sebastien
Le #1906785

Je suis à la recherche du mystérieux écriveur de disque.
En effet, voici ce qui se passe sur un serveur : des écritures
"intempestives". Je copie-colle des iostat tronqués.
<SNIP>


Tu peux jeter un coup d'oeil à la commande pidstat(1), qui fait partie
du package sysstat (c'est celui qui contient iostat).
Si tu as:
1) une version récente de sysstat (7.1.5 mini)
2) une version récente du noyau (2.6.20 ou suivante) avec le support des
stats par processus (CONFIG_TASK_IO_ACCOUNTING),
alors tu peux essayer de lancer par exemple la commande suivante:

$ pidstat -d 2

qui affichera toutes les 2 secondes les processus effectuant des I/O
ainsi que les volumes lus/écrits par seconde.

Voir:
-> la page de manuel de pidstat(1)
-> le site de sysstat: http://pagesperso-orange.fr/sebastien.godard/

--
Sébastien (sysstat at orange dot fr)

Patrick
Le #1906783

1) une version récente de sysstat (7.1.5 mini)
2) une version récente du noyau (2.6.20 ou suivante) avec le support des
stats par processus (CONFIG_TASK_IO_ACCOUNTING),


En voila un outil qu'il est bien !
Il ne me reste plus qu'à évaluer son impact en performances... Vu que la
machine est en prod...

Patrick

Damien Wyart
Le #1906782
Essaye de monter des disques avec l'option noatime. Les cas où on
a besoin de connaître la date d'accès en lecture à un fichier sont
très rares.



* "Thierry B."
D'ailleurs, quels sont ces cas ? J'ai appris par la LKML que Mutt
pouvait être impacté, et de mon coté, j'ai pensé à Leafnode...


Pour ces cas, il y a la variante relatime.

--
DW


Publicité
Poster une réponse
Anonyme