Worker Resource Limits und Timeouts sollten konfigurierbar sein

[larsbonczek]

Für diese Werte sollte es Einstellungen geben:

questionpy-server/questionpy_server/worker/pool.py

Line 72 in 8af6599

limits = WorkerResourceLimits(max_memory=200 * MiB, max_cpu_time_seconds_per_call=10)

questionpy-server/questionpy_server/worker/impl/_base.py

Lines 75 to 76 in 8af6599

	_init_worker_timeout = 2
	_load_qpy_package_timeout = 4

Insbesondere die 200MB und die 4 Sekunden hat der SQL-Fragetyp aus dem Praktikum gesprengt.

[MartinGauk]

Meine Vorstellung hier ist:

• Es gibt eine (konservative) hard codierte Voreinstellung, die möglicherweise über künftige Versionen erhöht werden (aber nicht verringert)
• Ein Paket kann über das Manifest höhere (vielleicht auch niedrigere) Limits anfordern.
  • In den Einstellungen kann man als Admin angeben, bis zu welchen Werten die Limits direkt akzeptiert werden.
  • Wenn noch höhere Limits angefordert werden, muss der Admin dies pro Paket erlauben.

[janbritz]

In einer neuen venv mit SymPy und gelöschten __pycache__-Ordnern dauert der Import ca. 1.77s. Das kann mit python -X importtime -c "import sympy" getestet werden. Vermutlich wird noch woanders gecached, denn wenn ich manuell (mit cProfile.Profile oder time.time) die Zeit für einen Import im Subprocess-Worker messe, dann sind wir bei den knapp 4 Sekunden.

Dazu gibt es auch mehrere Issues, z.B. das hier, wo einer der Entwickler folgendes schreibt:

I don't think there is a lot of scope for lazy loading because everything is expected to be available as from sympy import X which means everything has to be imported to sympy/__init__.py and then it isn't possible to import anything from anywhere without running that __init__.py.

Ich finde den Vorschlag sehr gut, das würde aber erstmal nicht das Problem mit _load_qpy_package_timeout lösen, da zum Auslesen der Limits das Paket bereits geladen sein muss, oder?

[MHajoha]

Ich finde den Vorschlag sehr gut, das würde aber erstmal nicht das Problem mit _load_qpy_package_timeout lösen, da zum Auslesen der Limits das Paket bereits geladen sein muss, oder?

Wir starten zwar aktuell immer einen Worker, um das Manifest auszulesen, ich denke das können (und mMn sollten) wir aber ändern.

Ich frage mich gerade, ob die Art der gewählten Limits super sinnvoll ist. Ich und vermutlich die meisten anderen Leute haben keine Intuition, wie viel 2s CPU-Zeit bedeutet und sicherlich ist ein Worker, der 5s bei 20% CPU-Auslastung läuft, akzeptabler als einer, der 1s bei 100% läuft. Ich würde daher eher vorschlagen, folgendes konfigurierbar zu machen:

• Physischen Speicher (aktuell schränken wir den Virtuellen ein)
• CPU-Auslastung
• Bootstrap-Timeout (nur Echtzeit, CPU-Zeit-Timeout ergibt sich dann mit der CPU-Auslastung)
• Request-Timeout (nur Echtzeit, CPU-Zeit-Timeout ergibt sich dann mit der CPU-Auslastung)
• evtl. zukünftig mal Timeouts für asynchrone Tasks

Leider führt für den physischen Speicher und die CPU-Auslastung nichts an Cgroups vorbei.