Hallo Debian-Users,

Ich habe eine Matomo-Installation auf einer VM, die unter Proxmox also KVM läuft. Von cron.daily werden um 6:25 unter anderem das Automysqlbackup gestartet und das führt dann nach circa 1 Minute zu einem TCP-Timeout des Webservers. Ich habe bereits testweise die Anzahl an vCPUs verdoppelt und
die Priorität des mysqldump-Prozesses auf +19 gesetzt, aber das hat keine Verbesserung gebracht. Es ist offensichtlich ein IO-Problem. Die
Festplatten der VMs liegen auf einem DELL-Storage und sind über ein SAN mit 10Gbits Glasfaser angebunden.

Ich versuche im Moment zu einem anderen Scheduler zu wechseln, der ionice unterstützt, damit ich mysqldump entsprechend runterpriorisieren kann.

Problem: Die Kernel Commandline evelevator=cfq funktioniert nicht mehr,
laut dmesg ist sie deprecated. Ich habe nun versucht den Scheduler erstmal
nur temporär zu wechseln und mich dann darum zu kümmern, die Änderung permanent zu machen. Es folgt die Ausgabe der Shell:

echo cfq | tee /sys/block/sda/queue/scheduler
cfq
tee: /sys/block/sda/queue/scheduler: Das Argument ist ungültig
Das scheint ein ungewöhnliches Problem zu sein, bei den meisten Seiten ist noch nicht mal angekommen, daß die Kernel-Commandline-Option veraltet ist.

Wie ändere ich im laufenden Betrieb den Scheduler? Ist CFQ Bestandteil des Standard-Debian11-Kernels? Wie mache ich diese Änderungen danach permanent?

Viele Grüße
Stefan

<div dir="ltr">Hallo Debian-Users,<div><br></div><div>Ich habe eine Matomo-Installation auf einer VM, die unter Proxmox also KVM läuft. Von cron.daily werden um 6:25 unter anderem das Automysqlbackup gestartet und das führt dann nach circa 1 Minute zu
einem TCP-Timeout des Webservers. Ich habe bereits testweise die Anzahl an vCPUs verdoppelt und die Priorität des mysqldump-Prozesses auf +19 gesetzt, aber das hat keine Verbesserung gebracht. Es ist offensichtlich ein IO-Problem. Die Festplatten der
VMs liegen auf einem DELL-Storage und sind über ein SAN mit 10Gbits Glasfaser angebunden.<br></div><div><br></div><div>Ich versuche im Moment zu einem anderen Scheduler zu wechseln, der ionice unterstützt, damit ich mysqldump entsprechend
runterpriorisieren kann. </div><div><br>Problem: Die Kernel Commandline evelevator=cfq funktioniert nicht mehr, laut dmesg ist sie deprecated. Ich habe nun versucht den Scheduler erstmal nur temporär zu wechseln und mich dann darum zu kümmern, die
Änderung permanent zu machen. Es folgt die Ausgabe der Shell:</div><div><br></div><div>echo cfq | tee /sys/block/sda/queue/scheduler <br>cfq<br>tee: /sys/block/sda/queue/scheduler: Das Argument ist ungültig<br></div><div>Das scheint ein ungewöhnliches
Problem zu sein, bei den meisten Seiten ist noch nicht mal angekommen, daß die Kernel-Commandline-Option veraltet ist.</div><div><br></div><div>Wie ändere ich im laufenden Betrieb den Scheduler? Ist CFQ Bestandteil des Standard-Debian11-Kernels? Wie
mache ich diese Änderungen danach permanent? </div><div><br></div><div>Viele Grüße</div><div>Stefan</div><div><br></div></div>

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi!

Stefan Schumacher - 18.10.22, 13:20:58 CEST:

Problem: Die Kernel Commandline evelevator=cfq funktioniert nicht
mehr, laut dmesg ist sie deprecated. Ich habe nun versucht den
Scheduler erstmal nur temporär zu wechseln und mich dann darum zu
kümmern, die Änderung permanent zu machen. Es folgt die Ausgabe der
Shell:

echo cfq | tee /sys/block/sda/queue/scheduler
cfq
tee: /sys/block/sda/queue/scheduler: Das Argument ist ungültig
Das scheint ein ungewöhnliches Problem zu sein, bei den meisten Seiten
ist noch nicht mal angekommen, daß die Kernel-Commandline-Option
veraltet ist.

Das für aktuelle Proxmox VE-Versionen verwendete Debian Bullseye
verwendet wie andere aktuellere Distributionen Multiqueue Block I/O.

Da gibt es den CFQ-Scheduler nicht. BFQ ersetzt ihn und ist meines
Wissens der einzige Multiqueue-I/O-Scheduler, der I/O-Prioritäten/ Kontrollgruppen kann.

Ein "cat scheduler" liefert im Übrigen die verfügbaren I/O-Scheduler,
der aktive ist mit eckigen Klammern umklammert.

Inwiefern der Wechsel auf einen anderen Scheduler hier wirklich Abhilfe bringt, steht natürlich nochmal auf einem anderen Blatt. Ich habe da
meine Zweifel, aber ohne ausführlichere Performance-Analyse lässt sich
dazu wenig sagen.

Ciao,
--
Martin

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hallo Martin, hallo Debian-Users,

Erstmal danke für die Info. Laut cat /sys/block/sda/queue/scheduler
habe ich im Moment [none], mit der Möglichkeit zu mq-deadline zu
wechseln. Das fällt also flach. Hat jemand eine Idee, wie ich ohne
ionice automysqlbackup ausbremsen kann? Ich habe von den Control
Groups gelesen und weiß, daß man damit Lese und
Schreibgeschwindigkeit limitieren kann, glaube aber, daß diese von der Komplexität her ziemlicher Overkill wären. Gibt es Alternativen, die
mit vertretbarem Aufwand umzusetzen wären? Ich habe das Problem
schließlich nur auf einer VM und will in die jetzt auch nicht Stunden
Arbeit versenken.

Viele Grüße
Stefan


Am Di., 18. Okt. 2022 um 14:28 Uhr schrieb Martin Steigerwald <martin@lichtvoll.de>:

Hi!

Stefan Schumacher - 18.10.22, 13:20:58 CEST:

Problem: Die Kernel Commandline evelevator=cfq funktioniert nicht
mehr, laut dmesg ist sie deprecated. Ich habe nun versucht den
Scheduler erstmal nur temporär zu wechseln und mich dann darum zu kümmern, die Änderung permanent zu machen. Es folgt die Ausgabe der Shell:

echo cfq | tee /sys/block/sda/queue/scheduler
cfq
tee: /sys/block/sda/queue/scheduler: Das Argument ist ungültig
Das scheint ein ungewöhnliches Problem zu sein, bei den meisten Seiten
ist noch nicht mal angekommen, daß die Kernel-Commandline-Option
veraltet ist.

Das für aktuelle Proxmox VE-Versionen verwendete Debian Bullseye
verwendet wie andere aktuellere Distributionen Multiqueue Block I/O.

Da gibt es den CFQ-Scheduler nicht. BFQ ersetzt ihn und ist meines
Wissens der einzige Multiqueue-I/O-Scheduler, der I/O-Prioritäten/ Kontrollgruppen kann.

Ein "cat scheduler" liefert im Übrigen die verfügbaren I/O-Scheduler,
der aktive ist mit eckigen Klammern umklammert.

Inwiefern der Wechsel auf einen anderen Scheduler hier wirklich Abhilfe bringt, steht natürlich nochmal auf einem anderen Blatt. Ich habe da
meine Zweifel, aber ohne ausführlichere Performance-Analyse lässt sich
dazu wenig sagen.

Ciao,
--
Martin

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi!

Stefan Schumacher - 19.10.22, 10:13:15 CEST:

Erstmal danke für die Info. Laut cat /sys/block/sda/queue/scheduler
habe ich im Moment [none], mit der Möglichkeit zu mq-deadline zu
wechseln.

Scheduler lassen sich je nach Kernel-Konfiguration als Module nachladen.

Das Modul für den Budget Fair Queueing Scheduler (BFQ) heißt "bfq".

Ciao,
--
Martin

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Stefan Schumacher <stefanschumacheratwork@gmail.com> wrote:

Erstmal danke für die Info. Laut cat /sys/block/sda/queue/scheduler
habe ich im Moment [none], mit der Möglichkeit zu mq-deadline zu
wechseln.

In einer VM ist "none" oftmals die beste Wahl, da der Kernel in der VM
keine Ahnung über die Queue und Struktur des Datenspeichers hat.

In der Vergangenheit haben Scheduler in VMs und außerhalb der VM sehr
oft gegeneinander gearbeitet, so dass es Best Practice war und ist, in
der VM einfach nur "none" (oder früher "deadline") als Scheduler zu
haben.

S°

--
Sigmentation fault. Core dumped.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Wed, 19 Oct 2022 16:35:46 +0200, Sven Hartge <sven@svenhartge.de>
wrote:

Stefan Schumacher <stefanschumacheratwork@gmail.com> wrote:

Erstmal danke für die Info. Laut cat /sys/block/sda/queue/scheduler
habe ich im Moment [none], mit der Möglichkeit zu mq-deadline zu
wechseln.

In einer VM ist "none" oftmals die beste Wahl, da der Kernel in der VM
keine Ahnung über die Queue und Struktur des Datenspeichers hat.

In der Vergangenheit haben Scheduler in VMs und außerhalb der VM sehr
oft gegeneinander gearbeitet, so dass es Best Practice war und ist, in
der VM einfach nur "none" (oder früher "deadline") als Scheduler zu
haben.

Ich habe mir mal eine Ubuntu- und eine Debian-VM in der Hetznercloud
gestartet, beide haben als Scheduler mq-deadline gesetzt. Wo kann ich
über diese Best Practice nachlesen?

Was ist denn der Debian-Weg um den IO-Scheduler zu setzen?
/etc/default/grub und die passende Kommandozeilenoption?

Grüße
Marc
--
-------------------------------------- !! No courtesy copies, please !! ----- Marc Haber | " Questions are the | Mailadresse im Header Mannheim, Germany | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Marc Haber - 09.01.23, 18:09:24 CET:

In einer VM ist "none" oftmals die beste Wahl, da der Kernel in der
VM keine Ahnung über die Queue und Struktur des Datenspeichers hat.

In der Vergangenheit haben Scheduler in VMs und außerhalb der VM sehr
oft gegeneinander gearbeitet, so dass es Best Practice war und ist,
in der VM einfach nur "none" (oder früher "deadline") als Scheduler
zu haben.

Ich habe mir mal eine Ubuntu- und eine Debian-VM in der Hetznercloud gestartet, beide haben als Scheduler mq-deadline gesetzt. Wo kann ich
über diese Best Practice nachlesen?

In meinem Kurs :)

Vereinzelt auch in der Kernel-Dokumentation:

https://www.kernel.org/doc/html/latest/block/blk-mq.html?
highlight=mq+deadline

https://www.kernel.org/doc/html/latest/block/index.html

So ganz vollständig oder zumindest übersichtlich ist das jedoch nicht. Möglicherweise auch an anderen Stellen im den Weiten des Netzes.
Allerdings ist wie in der Kernel-Dokumentation da auch nicht alles auf
dem neuesten Stand.

Wobei "mq-deadline" dem "none" schon relativ nahe kommt. Und bereits in
der Vergangenheit in Bezug auf die alten "Single Queue"-Schedulern gab
es unterschiedliche Ansichten. So hat ja Ubuntu auf den deadline
umgeschwenkt, während andere Distributionen, so wie ich mich erinnere
lange Zeit auch Debian, standardmäßig den cfq hatte. Bei zumindest
einigen XFS-Entwicklern war der cfq nicht so beliebt. Denn da gibt es mindestens drei größere Versionen von. Da gab es so ein Spiel: XFS-
Entwickler passten XFS an, damit es mit cfq besser klappt, und dann
haben cfq-Entwickler den wieder so geändert, dass es nicht so gut
klappte¹.

Grundsätzlich halte ich es mit der Regel, mich auf die Intelligenz zu verlassen, die am nächsten an der Hardware ist. So weiß OnTAP auf einer
NetApp einfach mehr über die eingesetzten Festplatten oder SSDs, die
Größe und den Aufbau von NV-RAM/Flash-Caches als das oben drüber
laufende Linux. Ähnliches gilt für einen Hypervisor. Der ist näher an
der Hardware als die VM. Und die üblichen intelligenten SATA/NVMe-SSDs
machen mit den Daten ja ohnehin so in etwa das, was sie wollen. Zum
Glück klappt das in der Regel so einigermaßen und zumindest meine BTRFS- Dateisysteme sind der Meinung, dass die Daten Bit für Bit noch stimmen
:)

[1] XFS FAQ, Q: "I want to tune my XFS filesystems for <something>"As of kernel 3.2.12, the default i/o scheduler, CFQ, will defeat much of the parallelization in XFS. " https://web.archive.org/web/20220902080136/ https://xfs.org/index.php/XFS_FAQ

Was ist denn der Debian-Weg um den IO-Scheduler zu setzen?
/etc/default/grub und die passende Kommandozeilenoption?

Das kommt drauf an, ob global für alle Geräte oder für unterschiedliche
Geräte getrennt. Für Festplatten, SATA- und NVMe-SSDs, für LUNs können unterschiedliche Einstellungen Sinn machen. Global geht über GRUB. Lokal
via udev-Regel oder sysfs. Ich hab hier beispielsweise für ein ThinkPad
T14 AMD Gen 1 für eine Samsung 980 Pro SSD nach Tests Folgendes
eingestellt:

% cat /etc/sysfs.d/block.conf
block/nvme0n1/queue/scheduler = none

https://www.kernel.org/doc/html/latest/block/switching-sched.html

Auch wenn ich ich das eher für eine Mikro-Optimierung halte, gerade
angesichts 32 GiB Hauptspeicher in diesem Laptop, das Linux oft genug
selbst für den Pagecache nicht mal komplett verbraucht². Die Latenzen
waren damit jedoch am geringsten.

Bei Festplatten macht cfq oder bfq laut meinen Messungen durchaus Sinn.

[2] Ich hab für das gebrauchte, jedoch im Grunde neuwertige Laptop wenig
mehr als die Hälfte des damaligen Neupreises für das reguläre, Nicht- Campus-Modell bezahlt. Da war das dann auch schon egal.

Ciao,
--
Martin

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Marc Haber <mh+debian-user-german@zugschlus.de> wrote:

On Wed, 19 Oct 2022 16:35:46 +0200, Sven Hartge <sven@svenhartge.de>
wrote:

Stefan Schumacher <stefanschumacheratwork@gmail.com> wrote:

Erstmal danke für die Info. Laut cat /sys/block/sda/queue/scheduler
habe ich im Moment [none], mit der Möglichkeit zu mq-deadline zu
wechseln.

In einer VM ist "none" oftmals die beste Wahl, da der Kernel in der VM >>keine Ahnung über die Queue und Struktur des Datenspeichers hat.

In der Vergangenheit haben Scheduler in VMs und außerhalb der VM sehr
oft gegeneinander gearbeitet, so dass es Best Practice war und ist, in
der VM einfach nur "none" (oder früher "deadline") als Scheduler zu
haben.

Ich habe mir mal eine Ubuntu- und eine Debian-VM in der Hetznercloud gestartet, beide haben als Scheduler mq-deadline gesetzt. Wo kann ich
über diese Best Practice nachlesen?

In ganz früheren Zeiten galt bei VMware dieses: https://kb.vmware.com/s/article/2011861

,----
| Testing has shown that NOOP or Deadline performs better for virtualized
| Linux guests. ESX uses an asynchronous intelligent I/O scheduler, and
| for this reason virtual guests should see improved performance by
| allowing ESX to handle I/O scheduling.
`----

Red Hat sagt auch, noop/none wäre das Beste für eine VM:

https://access.redhat.com/solutions/5427

,----
| If the hypervisor is known to do own I/O scheduling, then guests often
| benefit greatly from the noop I/O scheduler. It allows the
| host/hypervisor to optimize the I/O requests and prioritize based on
| it's view on the I/O from one or multiple guests.
`----

Mit mq-deadline und modernen Kernel kann das natürlich schon wieder
Cargo Culting sein, welches reevaluiert werden muss.

Was ist denn der Debian-Weg um den IO-Scheduler zu setzen?
/etc/default/grub und die passende Kommandozeilenoption?

sysfsutils und dann /etc/sysfs.d/scheduler.conf

S°

--
Sigmentation fault. Core dumped.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)