KVM, Qemu: Welche I/O-Scheduler verwenden
Update 20100318: Mehr Tuning-Informationen für die KVM gibt es hier: http://www.linux-kvm.org/page/Tuning_KVM .
Update 20090403: Ich denke, das sich das unten stehende, so nicht halten läßt. Die Sache mit dem noop-Scheduler verhält sich teilweise sehr gut, teilweise aber auch ziemlich übel, in dem z.B. der pgflush-Daemon ziemlich viel Systemzeit beansprucht und der I/O-Durchsatz ziemlich in die Knie geht. Das ändert sich schlagartig, sobald man auf den Deadline-Scheduler umschaltet. Auf den getesteten Systemen scheint die Benutzung des Deadline-Schedulers in Host und Guest die beste Kombination zu sein. Man kann das ja selber mal ausprobieren, in dem man den I/O-Scheduler im laufenden Betrieb wechselt z.B.
echo "deadline" > /sys/block/vda/queue/scheduler
Man sollte dann aber schon eine Anwendung oder einen Test fahren, der gut was auf die Platte schreibt und das auch möglichst konstant macht. Oder besser: Man verwendet bonnie++ . Ein eher syntetischer Test für I/O-Durchsatz aber ein guter Ausgangspunkt.
Text vom 20090330: Diese gar nicht so uninteressante Frage kam jetzt schon des Öfteren auf der KVM Mailingliste hoch. Letztendlich ist man sich einig, das das Gastsystem mit elevator=noop gestartet werden sollte. Per Default setzen ja heute die meisten Distributionen den Completely Fair Scheduler-I/O (CFQ) ein. Für den Host selbst ist das vielleicht ok, wenn im Gast elevator=noop als Kernelparameter z.B. im Grub übergibt. Es macht auch nicht wirklich Sinn, wenn sich die I/O-Scheduler im Gast und im Host Gedanken machen müssen, wie denn die Daten am Besten auf die Platte kommen sollen. Wenn ich die Mails der KVM-Entwickler/-User aber richtig interpretiere, dann bevorzugen sie doch eher den deadline Scheduler für den Host. Mit dem habe ich auch sehr gute Erfahrungen gemacht im Serverbereich. Ich finde - aber das ist jetzt meine subjektive Meinung - das der CFQ sich besser für den Desktopbereich eignet als für Serveranwendungen.
Erstellt am 08:00PM Mrz 30, 2009 in Tipps | Permalink Kommentare[0]