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
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
Poser une question
[...]
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
Alain Montfranc
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 -
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/20...veaux-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.
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)
En l'occurence, la base n'est utilisée qu'en lecture c'est domage ;-)
Je vais regarder ça mais en attendant je garde le ramdisk (simple et
efficace)
Oui