IOSTAT : ça écrit d'accord, mais qui écrit sur mon disque ?
10 réponses
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.
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.
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
Patrick <pviet+news@azuria.net.nospam> writes:
On Mon, 03 Dec 2007 07:41:34 +0100, Patrick :
(un hook sur open() ou write() dans le noyau ça existe.. ?)
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 »)
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
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.
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.
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
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.
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
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.
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.
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.
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.
--{ 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 }--
--{ 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 }--
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
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
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" !
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
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)
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/
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
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
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...
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
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." in fr.comp.os.linux.configuration:
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
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." <tth@prout.stex.invalid> in fr.comp.os.linux.configuration:
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...
