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 <[email protected]>:

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 <[email protected]> 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 <[email protected]>
wrote:

Stefan Schumacher <[email protected]> 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 <[email protected]> wrote:

On Wed, 19 Oct 2022 16:35:46 +0200, Sven Hartge <[email protected]>
wrote:

Stefan Schumacher <[email protected]> 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)