Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

Cherche cache disque efficace

7 réponses
Avatar
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

7 réponses

Avatar
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
Avatar
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/&gt;
Avatar
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.
Avatar
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)
Avatar
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
Avatar
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
Avatar
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/&gt;