Einem Task mehr Speicher geben

Lange Arbeit mit weitem Zuschnitt — ein Sicherheits-Audit über eine ganze Codebasis, ein großes Refactoring — kann den Speicher eines Agent-Containers aufbrauchen. Der Lauf stirbt dann an der Decke, ohne dass etwas Handhabbares übrig bleibt, und der einzige Regler war bisher eine einzige Zahl für die ganze Installation: sie für ein Audit zu erhöhen, erhöhte sie für jeden Task auf dem Server.

Eine Ressourcenklasse ist dieser Regler, angesetzt dort, wo die Arbeit ist.

Klasse	Was sie bedeutet
Normal	Das heutige Verhalten, unverändert.
Heavy	Mehr Speicher — und entsprechend mehr der parallelen Kapazität deines Workspace.

Speicher und Parallelität sind EIN Budget

Das ist der Teil, den man vor der Wahl verstanden haben sollte, denn er ist es, der Heavy unbedenklich macht.

Ein Server zahlt nicht für ein Speicherlimit. Er zahlt für das Limit mal die Zahl der Tasks, die gleichzeitig eines halten dürfen:

3 Tasks x 2 GB = 6 GB       (ein typischer Normal-Workspace)
1 Task  x 6 GB = 6 GB       (dieselben Kosten)
3 Tasks x 6 GB = 18 GB      (das Dreifache)

Eine Klasse trägt deshalb ein Gewicht: ein Heavy-Task belegt mehr als einen der parallelen Plätze deines Workspace. Mit der ausgelieferten Einstellung nimmt er zwei Plätze und den doppelten Speicher, und beides hebt sich auf — ein Workspace, der nur Heavy-Tasks fährt, kostet den Server genau so viel wie derselbe Workspace mit ausschließlich Normal-Tasks.

Heavy heißt also: weniger Tasks gleichzeitig, jeder mit mehr Platz. Es erhöht nicht, was dein Server bereitstellen muss.

Achtung

Die Parallelitätsgrenze gilt pro Workspace, und mehrere Workspaces teilen sich einen Server. Das reale Maximum, das eine Maschine abdecken muss, ist aktive Workspaces x parallele Tasks x Klassenspeicher. Wer zwei Workspaces mit je drei Plätzen fährt, muss für sechs gleichzeitige Tasks vorsorgen, nicht für drei.

Wo du sie setzt

Es gibt drei Stellen, und die dem Task nächste gewinnt:

1. Am Agent-Profil — Einstellungen → Profile → (ein Profil) → Ressourcenklasse. Das ist meist der richtige Ort: „Das Audit-Profil braucht Platz” ist eine Aussage über die Art der Arbeit, nicht über einen einzelnen Start. Jeder Task unter diesem Profil erbt sie.

2. Am Workspace — Einstellungen → Arbeitsbereich → Ressourcenklasse. Das ist der Standard für Arbeit, die unter keinem Profil läuft — dazu gehören jeder Workflow und jeder automatische Entwicklungslauf. Leer lassen heißt: keine Hausregel.

3. An einem einzelnen Lauf — ein Start kann ein eigenes resource_class tragen und übersteuert damit beide. Diese Ebene steht über die Task-Konfiguration der API zur Verfügung; die beiden Orte darüber sind die mit einer Auswahl in der Oberfläche.

Steht ein Profil oder ein Workspace auf Erben / Kein Standard, reicht es die Entscheidung weiter; der eingebaute Boden ist Normal, es ändert sich also nichts, bis jemand wählt.

Wenn ein Lauf trotzdem stirbt

Eine Klasse hebt eine Decke an, sie beseitigt sie nicht. Läuft ein Lauf dennoch aus dem Speicher, nennt der Fehler jetzt die Klasse, in der er lief, und das Limit, das er hatte — damit die nächste Frage („knapp daneben oder weit weg?“) eine Antwort hat. Auf dem Server selbst trägt der Container seine Klasse als Label; das ist es, was einem Betreiber erlaubt, einen Kernel-Logeintrag einem Lauf zuzuordnen.

Was die Zahlen tatsächlich sind

Die Byte-Werte gehören dem, der den Server betreibt, nicht auf diese Seite. Heavy wird als das Doppelte von Normal ausgeliefert — auf beiden Hälften, Speicher und Plätze — und ein Betreiber kann jede Hälfte einzeln setzen. Sie ungleich zu setzen ist erlaubt (ein Server, dessen Last die Grenze nie erreicht, mag das wollen), und SupaCloud sagt es beim Start, statt die Rechnung still driften zu lassen.