iops / io-read/write limiting for LXC?

Hi,

Wenn ich mich richtig errinere funktioniert das mit den v1 der control-groups nicht immer so wie es der Admin/User erwartet, denn die meiste IO geht ja über die Kernel caches und nicht direkt auf die Disk, und der IO controller konnte nur letzteres minimieren. Da das meiste IO gepuffert wird wäre es also kaum nützlich.

CGroup v2 macht dass besser, @wbumiller ist gerade dran den support für cgroup v2 in pve-container zu integrieren, denn mit dem Linux Kernel seit 5.3 (IIRC) wird nun von den v2 cgroups alles unterstützt was wir so benötigen.
 
OK, wolfgang noticed me that I used German in the English forum, seems that the first coffee hadn't kicked in yet..

Anyway, it mostly boils down to:

cgroup1 accounts for and controls only direct IOs, i.e., filesystem metadata IOs (both read and write), and buffered reads. This leaves other types of IOs, such as buffered IO (which is often the majority in many use cases), unaccounted for and uncontrollable.

cgroup2 allows comprehensive control and accounting of all IOs per-cgroup: buffered, filesystem metadata, swap, and direct IOs, making IO control a far more effective component of a resource utilization strategy.
Click to expand...
-- https://facebookmicrosites.github.i...oller.html#cgroup2-io-controller-enhancements
 
The limits from cgroupv2 definitely work better, but keep in mind that they will only work for block device based storages: LVM, LVM-Thin, iSCSI, RBD, and Directory depending on where the directory lies. Network storages work differently and ZFS is its own magic.
 
thank you for your reply;
so basically - if I want replication - I need zfs; if I want certain I/O-limits, I need LVM/anything else; I guess ceph is somewhere inbetween here :)

I don't know how openvz did it, but there were iolimits on containers (sorry).

I guess we'll have to be creative.
 
You must log in or register to reply here.
Top Bottom