☰

Warum begrenzt cpu.cfs_quota_us die CPU-Bandbreite des LXC-Containers nicht?

tag-icon • tag-icon linux lxc cgroups
Warum begrenzt cpu.cfs_quota_us die CPU-Bandbreite des LXC-Containers nicht?

Ich möchte den Container auf 25 % der gesamten CPU-Bandbreite des Systems beschränken.
Hier ist mein Setup:

  • LXC Version 1.0.2
  • Kernel 3.2.45
  • Ein Benutzer hat eine Cgroup (foo) für einen LXC-Container erstellt
  • 40 verfügbare Kerne auf dem Host
  • der Host und der Container haben Standardwerte für jedes andere Cgroup-Subsystem außer:
  • /sys/fs/cgroup/cpu/lxc/foo/cpu.cfs_quota_us = 400000
  • /sys/fs/cgroup/cpu/lxc/foo/cpu.cfs_period_us = 100000
  • /sys/fs/cgroup/cpuset/lxc/foo/cpuset.cpus = 0-15

Die Quote habe ich nach folgender Formel berechnet:

(# of cpus available to container) * (cpu.cfs_period_us) * (.25) so 16 * 100000 * .25 = 400000

Ich habe gleichzeitig innerhalb und außerhalb des Containers eine einfache Stress-ng-Prüfung ausgeführt, um zu ermitteln, wie viele Vorgänge pro Sekunde innerhalb und außerhalb zulässig waren. Die Ergebnisse waren im Wesentlichen dieselben wie bei der Ausführung mit einer Quote von „-1“, also ohne Quote.

Außenlauf:

$ ./stress-ng  --cpu-load 50 -c 40 --timeout 20s --metrics-brief
stress-ng: info: [25649] dispatching hogs: 40 cpu  
stress-ng: info: [25649] successful run completed in 20.44s  
stress-ng: info: [25649] stressor      bogo ops real time  usr time  sys time   bogo ops/s   bogo ops/s  
stress-ng: info: [25649]                          (secs)    (secs)    (secs)   (real time) (usr+sys time)  
stress-ng: info: [25649] cpu              37348     20.18    380.56      0.58      1850.85        97.99

Innenlauf:

$ ./stress-ng --cpu-load 100 -c 16 --timeout 20s --metrics-brief  
stress-ng: info: [34256] dispatching hogs: 16 cpu  
stress-ng: info: [34256] successful run completed in 20.10s  
stress-ng: info: [34256] stressor      bogo ops real time  usr time  sys time   bogo ops/s   bogo ops/s  
stress-ng: info: [34256]                          (secs)    (secs)    (secs)   (real time) (usr+sys time)  
stress-ng: info: [34256] cpu              24147     20.03    205.20      0.17      1205.67       117.58

Basierend auf den Ops/s erhalte ich 39 %. Warum passiert das? Sollte es nicht durch begrenzt werden cpu.cfs_quota_us?

Vielen Dank für die Hilfe im Voraus.

Antwort1

Ich wollte die Antwort auf diese Frage posten, falls jemand anderes ein ähnlich verwirrendes Ergebnis sieht. Es sieht so aus, als hätte ich zwei Probleme:

  • Zur Schätzung der CPU-Bandbreite müssen Sie die Anzahl der CPUs auf dem Host verwenden, nicht die Anzahl der verfügbaren CPUs im CPU-Set der Kontrollgruppen:

    (# of cpus on the host) * (cpu.cfs_period_us) * (.25) so 40 * 100000 * .25 = 1000000

  • Mein stress-ng-Lauf innerhalb des Containers verwendete die CPU- und CPU-Set-Controller der /lxc/foo-Cgroup, während der stress-ng-Lauf außerhalb des Containers die /system/sshd.service-Cgroup verwendete.

Um meine reale Anwendung besser zu modellieren, hätte ich angeben sollen, welche Controller verwendet werden sollen, indem ichcgexec:

$ cgexec -g cpuset:/lxc/foo -g cpu:/lxc/foo ./stress-ng --cpu-load 100 -c 48 --times --timeout 10s --metrics-brief  
stress-ng: info: [6252] dispatching hogs: 48 cpu  
stress-ng: info: [6252] successful run completed in 10.36s  
stress-ng: info: [6252] stressor      bogo ops real time  usr time  sys time   bogo ops/s   bogo ops/s  
stress-ng: info: [6252]                          (secs)    (secs)    (secs)   (real time) (usr+sys time)  
stress-ng: info: [6252] cpu              11152     10.09    102.83      0.12      1105.60       108.32  
stress-ng: info: [6252] for a 10.36s run time:  
stress-ng: info: [6252]     414.46s available CPU time  
stress-ng: info: [6252]     102.85s user time   ( 24.82%)  
stress-ng: info: [6252]       0.12s system time (  0.03%)  
stress-ng: info: [6252]     102.97s total time  ( 24.84%)

verwandte Informationen