Cherche cache disque efficace

Le
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

Toutes les idées sont les bienvenues !

Merci d'avance
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
Stephane CHAZELAS
Le #23393781
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
Paul Gaborit
Le #23393881
À (at) Thu, 26 May 2011 13:24:10 +0200,
Alain Montfranc
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 -
Emmanuel Florac
Le #23398931
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
Le #23399121
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)
Alain Montfranc
Le #23399111
Paul Gaborit a utilisé son clavier pour écrire :
À (at) Thu, 26 May 2011 13:24:10 +0200,
Alain Montfranc
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 #23399381
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
Le #23401751
À (at) Sat, 28 May 2011 18:59:01 +0200,
Alain Montfranc
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 -
Publicité
Poster une réponse
Anonyme