Je dois faire tourner un systeme pour une demo (avant achat serveur).
Pb, la seule machine a disposition est un vieux PC avec un disque
pourris et l'appli est mal écrite et fait énormément d'acces disques
(php + mysql)
Comme le corpus de fichier est assez limité, je m'attendais à ce que
mon Linux (Fedora 14) monte les fichiers en mémoire (il reste 1 Go
libre) et ne fasse que peu d'acces disques physiques
Mais non, ce crétin n'arrete pas de faire des IOs*
Pour valider ce point, j'ai monté un ramdisk et copié les fichiers PHP
et la base mysql dessus et les performance sont excellentes
D'où ma question : ecomment faire en sorte que les acces disques soient
un peu plus optimisés (ce qui tiens sur mon ramdisk peut aussi tenir en
cache, non ?)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Stephane CHAZELAS
2011-05-26, 13:24(+02), Alain Montfranc:
Bonjour
Je dois faire tourner un systeme pour une demo (avant achat serveur). Pb, la seule machine a disposition est un vieux PC avec un disque pourris et l'appli est mal écrite et fait énormément d'acces disques (php + mysql)
Comme le corpus de fichier est assez limité, je m'attendais à ce que mon Linux (Fedora 14) monte les fichiers en mémoire (il reste 1 Go libre) et ne fasse que peu d'acces disques physiques
Mais non, ce crétin n'arrete pas de faire des IOs*
Pour valider ce point, j'ai monté un ramdisk et copié les fichiers PHP et la base mysql dessus et les performance sont excellentes
D'où ma question : ecomment faire en sorte que les acces disques soient un peu plus optimisés (ce qui tiens sur mon ramdisk peut aussi tenir en cache, non ?)
Des options particulières à vérifier ?
Une surcouche/module noyau à ajouter...
[...]
Je me suis posé la meme question recemment (pour optimiser un live-linux sur un usb flashdrive).
Le probleme en l'occurrence etait surtout lié aux applications faisant des fsync ou des open() avec O_SYNC, O_DIRECT...
Sur une per-application basis, tu peux utiliser eatmydata (https://launchpad.net/libeatmydata): LD_PRELOAD wrapper qui disable tous ces sync.
Sinon, globalement, que j'ai testé et qui marche (mais j'ai du mal a imaginer qu'il n'y ait pas plus simple) est d'utiliser eatmydata qemu-nbd:
eatmydata qemu-nbd -c /dev/nbd0 /dev/original-device mount /dev/nbd0 ...
Tous les I/O passent par un process user-space, mais il y a deux niveaux de caching.
Sinon, il y a la solution d'utiliser une virtual machine kvm avec -drive file=/dev/original-device,cache=unsafe,if=virtio
-- Stephane
2011-05-26, 13:24(+02), Alain Montfranc:
Bonjour
Je dois faire tourner un systeme pour une demo (avant achat serveur).
Pb, la seule machine a disposition est un vieux PC avec un disque
pourris et l'appli est mal écrite et fait énormément d'acces disques
(php + mysql)
Comme le corpus de fichier est assez limité, je m'attendais à ce que
mon Linux (Fedora 14) monte les fichiers en mémoire (il reste 1 Go
libre) et ne fasse que peu d'acces disques physiques
Mais non, ce crétin n'arrete pas de faire des IOs*
Pour valider ce point, j'ai monté un ramdisk et copié les fichiers PHP
et la base mysql dessus et les performance sont excellentes
D'où ma question : ecomment faire en sorte que les acces disques soient
un peu plus optimisés (ce qui tiens sur mon ramdisk peut aussi tenir en
cache, non ?)
Des options particulières à vérifier ?
Une surcouche/module noyau à ajouter...
[...]
Je me suis posé la meme question recemment (pour optimiser un
live-linux sur un usb flashdrive).
Le probleme en l'occurrence etait surtout lié aux applications
faisant des fsync ou des open() avec O_SYNC, O_DIRECT...
Sur une per-application basis, tu peux utiliser eatmydata
(https://launchpad.net/libeatmydata): LD_PRELOAD wrapper qui
disable tous ces sync.
Sinon, globalement, que j'ai testé et qui marche (mais j'ai du
mal a imaginer qu'il n'y ait pas plus simple) est d'utiliser
eatmydata qemu-nbd:
eatmydata qemu-nbd -c /dev/nbd0 /dev/original-device
mount /dev/nbd0 ...
Tous les I/O passent par un process user-space, mais il y a deux
niveaux de caching.
Sinon, il y a la solution d'utiliser une virtual machine kvm
avec -drive file=/dev/original-device,cache=unsafe,if=virtio
Je dois faire tourner un systeme pour une demo (avant achat serveur). Pb, la seule machine a disposition est un vieux PC avec un disque pourris et l'appli est mal écrite et fait énormément d'acces disques (php + mysql)
Comme le corpus de fichier est assez limité, je m'attendais à ce que mon Linux (Fedora 14) monte les fichiers en mémoire (il reste 1 Go libre) et ne fasse que peu d'acces disques physiques
Mais non, ce crétin n'arrete pas de faire des IOs*
Pour valider ce point, j'ai monté un ramdisk et copié les fichiers PHP et la base mysql dessus et les performance sont excellentes
D'où ma question : ecomment faire en sorte que les acces disques soient un peu plus optimisés (ce qui tiens sur mon ramdisk peut aussi tenir en cache, non ?)
Des options particulières à vérifier ?
Une surcouche/module noyau à ajouter...
[...]
Je me suis posé la meme question recemment (pour optimiser un live-linux sur un usb flashdrive).
Le probleme en l'occurrence etait surtout lié aux applications faisant des fsync ou des open() avec O_SYNC, O_DIRECT...
Sur une per-application basis, tu peux utiliser eatmydata (https://launchpad.net/libeatmydata): LD_PRELOAD wrapper qui disable tous ces sync.
Sinon, globalement, que j'ai testé et qui marche (mais j'ai du mal a imaginer qu'il n'y ait pas plus simple) est d'utiliser eatmydata qemu-nbd:
eatmydata qemu-nbd -c /dev/nbd0 /dev/original-device mount /dev/nbd0 ...
Tous les I/O passent par un process user-space, mais il y a deux niveaux de caching.
Sinon, il y a la solution d'utiliser une virtual machine kvm avec -drive file=/dev/original-device,cache=unsafe,if=virtio
-- Stephane
Paul Gaborit
À (at) Thu, 26 May 2011 13:24:10 +0200, Alain Montfranc écrivait (wrote):
Je dois faire tourner un systeme pour une demo (avant achat serveur). Pb, la seule machine a disposition est un vieux PC avec un disque pourris et l'appli est mal écrite et fait énormément d'acces disques (php + mysql)
Comme le corpus de fichier est assez limité, je m'attendais à ce que mon Linux (Fedora 14) monte les fichiers en mémoire (il reste 1 Go libre) et ne fasse que peu d'acces disques physiques
Mais non, ce crétin n'arrete pas de faire des IOs*
Si les accès en base sont des écritures, cela me semble assez normal : un SGBD fait tout pour s'assurer que les écritures sont *réellement* effectués.
Sans en être sûr, il existe peut-être un ou plusieurs paramètres dans mysql qui permet d'augmenter la durée de rétention dans son journal avant le déclenchement des écritures effectives...
Sinon, reste évidemment les autre solutions évoquées (qui passent toutes d'une manière ou d'une autre par la simulation en mémoire des disques du la base).
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Thu, 26 May 2011 13:24:10 +0200,
Alain Montfranc <mort@aux.spammeurs> écrivait (wrote):
Je dois faire tourner un systeme pour une demo (avant achat
serveur). Pb, la seule machine a disposition est un vieux PC avec un
disque pourris et l'appli est mal écrite et fait énormément d'acces
disques (php + mysql)
Comme le corpus de fichier est assez limité, je m'attendais à ce que
mon Linux (Fedora 14) monte les fichiers en mémoire (il reste 1 Go
libre) et ne fasse que peu d'acces disques physiques
Mais non, ce crétin n'arrete pas de faire des IOs*
Si les accès en base sont des écritures, cela me semble assez normal :
un SGBD fait tout pour s'assurer que les écritures sont *réellement*
effectués.
Sans en être sûr, il existe peut-être un ou plusieurs paramètres dans
mysql qui permet d'augmenter la durée de rétention dans son journal
avant le déclenchement des écritures effectives...
Sinon, reste évidemment les autre solutions évoquées (qui passent toutes
d'une manière ou d'une autre par la simulation en mémoire des disques du
la base).
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Thu, 26 May 2011 13:24:10 +0200, Alain Montfranc écrivait (wrote):
Je dois faire tourner un systeme pour une demo (avant achat serveur). Pb, la seule machine a disposition est un vieux PC avec un disque pourris et l'appli est mal écrite et fait énormément d'acces disques (php + mysql)
Comme le corpus de fichier est assez limité, je m'attendais à ce que mon Linux (Fedora 14) monte les fichiers en mémoire (il reste 1 Go libre) et ne fasse que peu d'acces disques physiques
Mais non, ce crétin n'arrete pas de faire des IOs*
Si les accès en base sont des écritures, cela me semble assez normal : un SGBD fait tout pour s'assurer que les écritures sont *réellement* effectués.
Sans en être sûr, il existe peut-être un ou plusieurs paramètres dans mysql qui permet d'augmenter la durée de rétention dans son journal avant le déclenchement des écritures effectives...
Sinon, reste évidemment les autre solutions évoquées (qui passent toutes d'une manière ou d'une autre par la simulation en mémoire des disques du la base).
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
Emmanuel Florac
Le Thu, 26 May 2011 13:24:10 +0200, Alain Montfranc a écrit:
D'où ma question : ecomment faire en sorte que les acces disques soient un peu plus optimisés (ce qui tiens sur mon ramdisk peut aussi tenir en cache, non ?)
Tu peux utiliser un contrôleur RAID avec un cache en écriture (et une batterie de protection du cache), c'est très efficace. Autre option, si c'est la base de données qui travaille dur, une paire de SSD en RAID-1 fera l'affaire. Il y a des SSD efficaces et pas trop cher (120 euros pour 60 Go).
Tiens j'ai récemment posté un truc sur les SSDs : http://blogs.intellique.com/tech/2011/05/20#nouveaux-ssds
-- De longs désirs, une longue admiration sans espérance, voilà le moyen d'adorer les femmes, et de rendre l'amour une passion délicieuse! N. Rétif de la Bretonne.
Le Thu, 26 May 2011 13:24:10 +0200, Alain Montfranc a écrit:
D'où ma question : ecomment faire en sorte que les acces disques soient
un peu plus optimisés (ce qui tiens sur mon ramdisk peut aussi tenir en
cache, non ?)
Tu peux utiliser un contrôleur RAID avec un cache en écriture (et une
batterie de protection du cache), c'est très efficace. Autre option, si
c'est la base de données qui travaille dur, une paire de SSD en RAID-1
fera l'affaire. Il y a des SSD efficaces et pas trop cher (120 euros pour
60 Go).
Tiens j'ai récemment posté un truc sur les SSDs :
http://blogs.intellique.com/tech/2011/05/20#nouveaux-ssds
--
De longs désirs, une longue admiration sans espérance, voilà le moyen
d'adorer les femmes, et de rendre l'amour une passion délicieuse!
N. Rétif de la Bretonne.
Le Thu, 26 May 2011 13:24:10 +0200, Alain Montfranc a écrit:
D'où ma question : ecomment faire en sorte que les acces disques soient un peu plus optimisés (ce qui tiens sur mon ramdisk peut aussi tenir en cache, non ?)
Tu peux utiliser un contrôleur RAID avec un cache en écriture (et une batterie de protection du cache), c'est très efficace. Autre option, si c'est la base de données qui travaille dur, une paire de SSD en RAID-1 fera l'affaire. Il y a des SSD efficaces et pas trop cher (120 euros pour 60 Go).
Tiens j'ai récemment posté un truc sur les SSDs : http://blogs.intellique.com/tech/2011/05/20#nouveaux-ssds
-- De longs désirs, une longue admiration sans espérance, voilà le moyen d'adorer les femmes, et de rendre l'amour une passion délicieuse! N. Rétif de la Bretonne.
Alain Montfranc
Emmanuel Florac vient de nous annoncer :
Le Thu, 26 May 2011 13:24:10 +0200, Alain Montfranc a écrit:
D'où ma question : ecomment faire en sorte que les acces disques soient un peu plus optimisés (ce qui tiens sur mon ramdisk peut aussi tenir en cache, non ?)
Tu peux utiliser un contrôleur RAID avec un cache en écriture (et une batterie de protection du cache), c'est très efficace. Autre option, si c'est la base de données qui travaille dur, une paire de SSD en RAID-1 fera l'affaire. Il y a des SSD efficaces et pas trop cher (120 euros pour 60 Go).
Tiens j'ai récemment posté un truc sur les SSDs : http://blogs.intellique.com/tech/2011/05/20#nouveaux-ssds
Oui, le vrai serveur n'aura pas ces problèmes Là je n'ai qu'un vieux PC IDE, alors le RAID :-D
Finalement je vais garder la solution du Ramdisk (la base mysql n'est utilisée qu'en lecture)
Emmanuel Florac vient de nous annoncer :
Le Thu, 26 May 2011 13:24:10 +0200, Alain Montfranc a écrit:
D'où ma question : ecomment faire en sorte que les acces disques soient
un peu plus optimisés (ce qui tiens sur mon ramdisk peut aussi tenir en
cache, non ?)
Tu peux utiliser un contrôleur RAID avec un cache en écriture (et une
batterie de protection du cache), c'est très efficace. Autre option, si
c'est la base de données qui travaille dur, une paire de SSD en RAID-1
fera l'affaire. Il y a des SSD efficaces et pas trop cher (120 euros pour
60 Go).
Tiens j'ai récemment posté un truc sur les SSDs :
http://blogs.intellique.com/tech/2011/05/20#nouveaux-ssds
Oui, le vrai serveur n'aura pas ces problèmes
Là je n'ai qu'un vieux PC IDE, alors le RAID :-D
Finalement je vais garder la solution du Ramdisk (la base mysql n'est
utilisée qu'en lecture)
Le Thu, 26 May 2011 13:24:10 +0200, Alain Montfranc a écrit:
D'où ma question : ecomment faire en sorte que les acces disques soient un peu plus optimisés (ce qui tiens sur mon ramdisk peut aussi tenir en cache, non ?)
Tu peux utiliser un contrôleur RAID avec un cache en écriture (et une batterie de protection du cache), c'est très efficace. Autre option, si c'est la base de données qui travaille dur, une paire de SSD en RAID-1 fera l'affaire. Il y a des SSD efficaces et pas trop cher (120 euros pour 60 Go).
Tiens j'ai récemment posté un truc sur les SSDs : http://blogs.intellique.com/tech/2011/05/20#nouveaux-ssds
Oui, le vrai serveur n'aura pas ces problèmes Là je n'ai qu'un vieux PC IDE, alors le RAID :-D
Finalement je vais garder la solution du Ramdisk (la base mysql n'est utilisée qu'en lecture)
Alain Montfranc
Paul Gaborit a utilisé son clavier pour écrire :
À (at) Thu, 26 May 2011 13:24:10 +0200, Alain Montfranc écrivait (wrote):
Je dois faire tourner un systeme pour une demo (avant achat serveur). Pb, la seule machine a disposition est un vieux PC avec un disque pourris et l'appli est mal écrite et fait énormément d'acces disques (php + mysql)
Comme le corpus de fichier est assez limité, je m'attendais à ce que mon Linux (Fedora 14) monte les fichiers en mémoire (il reste 1 Go libre) et ne fasse que peu d'acces disques physiques
Mais non, ce crétin n'arrete pas de faire des IOs*
Si les accès en base sont des écritures, cela me semble assez normal : un SGBD fait tout pour s'assurer que les écritures sont *réellement* effectués.
En l'occurence, la base n'est utilisée qu'en lecture c'est domage ;-)
Sans en être sûr, il existe peut-être un ou plusieurs paramètres dans mysql qui permet d'augmenter la durée de rétention dans son journal avant le déclenchement des écritures effectives...
Je vais regarder ça mais en attendant je garde le ramdisk (simple et efficace)
Sinon, reste évidemment les autre solutions évoquées (qui passent toutes d'une manière ou d'une autre par la simulation en mémoire des disques du la base).
Oui
Paul Gaborit a utilisé son clavier pour écrire :
À (at) Thu, 26 May 2011 13:24:10 +0200,
Alain Montfranc <mort@aux.spammeurs> écrivait (wrote):
Je dois faire tourner un systeme pour une demo (avant achat
serveur). Pb, la seule machine a disposition est un vieux PC avec un
disque pourris et l'appli est mal écrite et fait énormément d'acces
disques (php + mysql)
Comme le corpus de fichier est assez limité, je m'attendais à ce que
mon Linux (Fedora 14) monte les fichiers en mémoire (il reste 1 Go
libre) et ne fasse que peu d'acces disques physiques
Mais non, ce crétin n'arrete pas de faire des IOs*
Si les accès en base sont des écritures, cela me semble assez normal :
un SGBD fait tout pour s'assurer que les écritures sont *réellement*
effectués.
En l'occurence, la base n'est utilisée qu'en lecture c'est domage ;-)
Sans en être sûr, il existe peut-être un ou plusieurs paramètres dans
mysql qui permet d'augmenter la durée de rétention dans son journal
avant le déclenchement des écritures effectives...
Je vais regarder ça mais en attendant je garde le ramdisk (simple et
efficace)
Sinon, reste évidemment les autre solutions évoquées (qui passent toutes
d'une manière ou d'une autre par la simulation en mémoire des disques du
la base).
À (at) Thu, 26 May 2011 13:24:10 +0200, Alain Montfranc écrivait (wrote):
Je dois faire tourner un systeme pour une demo (avant achat serveur). Pb, la seule machine a disposition est un vieux PC avec un disque pourris et l'appli est mal écrite et fait énormément d'acces disques (php + mysql)
Comme le corpus de fichier est assez limité, je m'attendais à ce que mon Linux (Fedora 14) monte les fichiers en mémoire (il reste 1 Go libre) et ne fasse que peu d'acces disques physiques
Mais non, ce crétin n'arrete pas de faire des IOs*
Si les accès en base sont des écritures, cela me semble assez normal : un SGBD fait tout pour s'assurer que les écritures sont *réellement* effectués.
En l'occurence, la base n'est utilisée qu'en lecture c'est domage ;-)
Sans en être sûr, il existe peut-être un ou plusieurs paramètres dans mysql qui permet d'augmenter la durée de rétention dans son journal avant le déclenchement des écritures effectives...
Je vais regarder ça mais en attendant je garde le ramdisk (simple et efficace)
Sinon, reste évidemment les autre solutions évoquées (qui passent toutes d'une manière ou d'une autre par la simulation en mémoire des disques du la base).
Oui
Emmanuel Florac
Le Sat, 28 May 2011 18:56:34 +0200, Alain Montfranc a écrit:
Oui, le vrai serveur n'aura pas ces problèmes Là je n'ai qu'un vieux PC IDE, alors le RAID :-D
Boah, j'ai toute une collection de 3Ware 9550 sur PCI-X, pour les amateurs :)
Finalement je vais garder la solution du Ramdisk (la base mysql n'est utilisée qu'en lecture)
Cas le plus favorable aux SSDs, soit dit en passant :)
-- Money is a barren Thing, and produces nothing, but by Compact, transfers that Profit, that was the Reward of one Man's Labour, into another Man's Pocket. John Locke
Le Sat, 28 May 2011 18:56:34 +0200, Alain Montfranc a écrit:
Oui, le vrai serveur n'aura pas ces problèmes Là je n'ai qu'un vieux PC
IDE, alors le RAID :-D
Boah, j'ai toute une collection de 3Ware 9550 sur PCI-X, pour les
amateurs :)
Finalement je vais garder la solution du Ramdisk (la base mysql n'est
utilisée qu'en lecture)
Cas le plus favorable aux SSDs, soit dit en passant :)
--
Money is a barren Thing, and produces nothing, but by Compact,
transfers that Profit, that was the Reward of one Man's Labour, into
another Man's Pocket.
John Locke
Le Sat, 28 May 2011 18:56:34 +0200, Alain Montfranc a écrit:
Oui, le vrai serveur n'aura pas ces problèmes Là je n'ai qu'un vieux PC IDE, alors le RAID :-D
Boah, j'ai toute une collection de 3Ware 9550 sur PCI-X, pour les amateurs :)
Finalement je vais garder la solution du Ramdisk (la base mysql n'est utilisée qu'en lecture)
Cas le plus favorable aux SSDs, soit dit en passant :)
-- Money is a barren Thing, and produces nothing, but by Compact, transfers that Profit, that was the Reward of one Man's Labour, into another Man's Pocket. John Locke
Paul Gaborit
À (at) Sat, 28 May 2011 18:59:01 +0200, Alain Montfranc écrivait (wrote):
Paul Gaborit a utilisé son clavier pour écrire :
Si les accès en base sont des écritures, cela me semble assez normal : un SGBD fait tout pour s'assurer que les écritures sont *réellement* effectués.
En l'occurence, la base n'est utilisée qu'en lecture c'est domage ;-)
Donc, ce n'est pas la bonne explication... Peut-être que le moteur fait des IO juste pour vérifier que rien n'a changé dans la base sur disque. Mais cela n'explique pas un gros volume d'IO.
Sans en être sûr, il existe peut-être un ou plusieurs paramètres dans mysql qui permet d'augmenter la durée de rétention dans son journal avant le déclenchement des écritures effectives...
Je vais regarder ça[...]
À mon avis, puisque le base n'est que lue, ça ne servira à rien.
[...] mais en attendant je garde le ramdisk (simple et efficace)
Oui, il faut rester pragmatique ! ;-)
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Sat, 28 May 2011 18:59:01 +0200,
Alain Montfranc <mort@aux.spammeurs> écrivait (wrote):
Paul Gaborit a utilisé son clavier pour écrire :
Si les accès en base sont des écritures, cela me semble assez normal :
un SGBD fait tout pour s'assurer que les écritures sont *réellement*
effectués.
En l'occurence, la base n'est utilisée qu'en lecture c'est domage ;-)
Donc, ce n'est pas la bonne explication... Peut-être que le moteur fait
des IO juste pour vérifier que rien n'a changé dans la base sur
disque. Mais cela n'explique pas un gros volume d'IO.
Sans en être sûr, il existe peut-être un ou plusieurs paramètres dans
mysql qui permet d'augmenter la durée de rétention dans son journal
avant le déclenchement des écritures effectives...
Je vais regarder ça[...]
À mon avis, puisque le base n'est que lue, ça ne servira à rien.
[...] mais en attendant je garde le ramdisk (simple et efficace)
Oui, il faut rester pragmatique ! ;-)
--
Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>
À (at) Sat, 28 May 2011 18:59:01 +0200, Alain Montfranc écrivait (wrote):
Paul Gaborit a utilisé son clavier pour écrire :
Si les accès en base sont des écritures, cela me semble assez normal : un SGBD fait tout pour s'assurer que les écritures sont *réellement* effectués.
En l'occurence, la base n'est utilisée qu'en lecture c'est domage ;-)
Donc, ce n'est pas la bonne explication... Peut-être que le moteur fait des IO juste pour vérifier que rien n'a changé dans la base sur disque. Mais cela n'explique pas un gros volume d'IO.
Sans en être sûr, il existe peut-être un ou plusieurs paramètres dans mysql qui permet d'augmenter la durée de rétention dans son journal avant le déclenchement des écritures effectives...
Je vais regarder ça[...]
À mon avis, puisque le base n'est que lue, ça ne servira à rien.
[...] mais en attendant je garde le ramdisk (simple et efficace)
Oui, il faut rester pragmatique ! ;-)
-- Paul Gaborit - <http://perso.mines-albi.fr/~gaborit/>