Heute früh beim Einloggen hab ich kurz aus dem Fenster geschaut: Passau ist klar, 11,2 °C, kein Wolkenzeug, bisschen Wind. Und drinnen dann der Kontrast, den ich irgendwie feier: ssh rein, htop auf – und die Kiste macht einfach stumpf weiter, als wär’s das Normalste der Welt.
Schneller Überblick
Zusammenfassung
Der Bericht dokumentiert eine Woche Serverbetrieb für das BOINC-Projekt donau2space. Der Host lief stabil bei 99,8 % CPU-Auslastung und nahezu fehlerfrei. Speicherverbrauch lag durch Einstein@Home teils hoch, blieb aber immer im RAM-Bereich (kein Swap). Temperatur und Stromverbrauch blieben im normalen Bereich. Die Projekte unterscheiden sich deutlich bezüglich Ressourcenanforderungen und Task-Laufzeiten.
Auf den Punkt
- Server-Uptime ohne Ausfälle, 0 fehlgeschlagene Jobs.
- Einstein@Home dominiert den RAM-Verbrauch (~5 GB pro Task).
- PrimeGrid nutzt mehr CPU, weniger RAM.
- spacious@home sorgt für häufige Taskwechsel.
- Asteroids@home arbeitet sehr RAM-sparsam.
- Temperaturpeaks bis 76 °C, ohne Drosselung.
- BOINC-Nutzung: 3.834 Jobs erfolgreich, kein RPC-/Fetch-Fehler.
Serverstatus & Telemetrie
Der Zeitraum geht von Mittwoch, 22. April 2026, 7:00 Uhr bis Mittwoch, 29. April 2026, 7:00 Uhr. Die Uptime steht am Ende bei 2.056,27 h. Das ist genau dieses „läuft einfach“-Gefühl: kein Neustart-Drama, keine unerklärlichen Lücken – nur Last.
Was die Woche charakterisiert hat, ist ziemlich eindeutig: Vollauslastung, aber entspannt.
Im Schnitt liegt die CPU bei 36,5 W und 66,5 °C bei 99,8 % Usage. Das ist für 24/7-Crunching auf dem i7‑7700 echt ein angenehmer Bereich. Nicht „maximal heiß“, sondern eher effizient: die CPU arbeitet durchgehend, aber ohne dass die Telemetrie nach Kampf aussieht.
Der Load1 Ø 8,38 bei 8 Threads fühlt sich für mich „richtig“ an. Das ist dieses Bild von: alle Threads sind beschäftigt, die Runqueue ist voll, aber nicht so überladen, dass man schon an IO-Wartezeit oder Scheduling-Overhead denkt.
RAM ist deutlich genutzt, aber ohne Druck:
Ø 27,6 GB (44,1 %), Peak bei 36,34 GB (58,05 %) – und das Wichtigste: Swap 0 MB. Genau das macht’s stabil. Viel RAM-Verbrauch ist bei BOINC kein Problem, solange es im RAM bleibt. Sobald Swap ins Spiel kommt, rechnest du nicht mehr „schnell“, sondern schiebst Speicher herum.
Storage ist komplett unkritisch: 201,1 GB total, 175,1 GB frei. BOINC selbst liegt bei 1.791,28 MB Disk usage – da ist genug Luft, und es fühlt sich nicht so an, als würde irgendwo still Platz knapp werden.
BOINC-seitig war’s einfach sauber: 3.834 Jobs succeeded, 0 failed. Und dazu 0 RPC failures und 0 fetch failures. Ich sag’s immer wieder: diese Null bei „failed“ macht mich mehr glücklich als jeder Credit-Sprung. Weil 24/7 Last kann jeder… aber 24/7 Last ohne schleichenden Murks ist das, was ich sehen will.
Projekte im Detail
Diese Woche wirkt vom „Charakter“ her wie: Einstein gibt den Grundton, die anderen Projekte machen die Rotation und halten die Pipeline lebendig.
Einstein@Home – Langläufer mit fettem RAM-Fußabdruck
Einstein ist bei 2.209.176 Credit und einem expavg von 20.196,11. Das ist nicht nur „auch dabei“, das ist ganz klar der dominante Crunch-Block.
Und man sieht wieder richtig schön, warum Einstein das Systemprofil prägt: die aktiven Einstein-Tasks hängen bei ~5.095 MB bis 5.150 MB Working Set pro Task. Wenn davon mehrere parallel laufen, ist das kein „bisschen RAM“, das ist ein echter Speicher-Footprint, der den Memory-Controller beschäftigt.
Technisch ist das genau die Sorte Workload, die Temperatur und Watt beeinflussen kann, obwohl die CPU-Auslastung eh konstant bei ~100 % steht: großer Working Set → mehr RAM-/Cache-Traffic → nebenbei mehr Aktivität im Speicherpfad → das kann sich als kleine Watt- und Temp-Verschiebung zeigen.
Auch die Laufzeiten passen: in den zuletzt erledigten Tasks waren Einstein-WUs bei Ø 40h 44m. Das ist schedulertechnisch „ruhig“: wenig Taskwechsel, wenig Reporting-Hektik, dafür lange gleichmäßige Last.
PrimeGrid – CPU-bound, aber nicht unbedingt kurz
PrimeGrid steht bei 435.593,938323 Credit und expavg 5.155,48. In den letzten Meldungen waren PrimeGrid-WUs eher kurz (Ø 35m 23s bei den letzten zwei), aber das aktive Set zeigt: da kann auch „zäh“ drinstecken.
Gerade läuft z. B. eine llrSR5-WU mit 51h 2m CPU-Zeit und 276 MB Working Set, schon bei 97,8 %. Das ist so typisch PrimeGrid: im Kern sehr CPU-bound (viel rechnen, wenig RAM), aber je nach Subprojekt kann die Laufzeit von Snack bis Marathon gehen.
Systemseitig ist PrimeGrid für mich oft der „saubere“ Gegenspieler zu Einstein: hält die Kerne warm, ohne den RAM groß aufzudrehen.
spacious@home – schnelle Rotation, unauffällig… bis es mal nicht mehr mini ist
spacious@home ist bei 105.896,263753 Credit und expavg 1.393,33. Und das Projekt fühlt sich genau so an, wie die Laufzeiten aussehen: zuletzt 10 Tasks mit Ø 44m 2s.
Das ist diese angenehme, regelmäßige Rotation. Scheduler-seitig heißt das: öfter neue Tasks, öfter Reports, mehr „Bewegung“ im BOINC-Alltag.
Spannend ist, dass spacious beim Working Set nicht immer nur winzig ist: aktiv läuft z. B. ein Task mit 219 MB WS (und gerade erst gestartet), andere liegen bei 4 MB oder 27 MB. Alles komplett unkritisch – aber man merkt: da sind unterschiedliche WU-Typen/Datensätze unterwegs.
Asteroids@home – mittlere Laufzeiten, sehr leicht auf dem RAM
Asteroids@home steht bei 71.666,621605 Credit und expavg 1.049,94. Zuletzt waren es 6 Tasks mit Ø 1h 10m. Das ist so die „mittlere“ Kategorie: nicht super kurz, nicht ewig lang.
Vom Ressourcenprofil her wirkt Asteroids hier sehr schlank: aktive Tasks liegen z. B. bei 13 MB Working Set. Also CPU beschäftigt, RAM quasi egal.
Was im Task-Listing auffällt: viele Asteroids-Einträge stehen als UNINITIALIZED READYTOREPORT drin. Solange RPC/FETCH auf 0 bleibt (und das tut’s), fühlt sich das für mich eher nach Client-/Anzeigestatus an als nach einem echten Problem. Rechenfehler würde ich sofort in „failed“ oder in Retries sehen – und da ist ja nix.
climateprediction.net – weiterhin nicht im Mix
Hier bleibt’s bei 0 Credit, 0 Jobs, 0 Runtime. Kein Einfluss diese Woche.
Auffälligkeiten
Erst der Durchschnitt, dann die Momente: im Mittel war alles schön glatt, aber ein paar Peaks zeigen, dass „99,8 % CPU“ nicht heißt „immer exakt gleiche Arbeit“.
Der höchste Temperaturpunkt war 76 °C am Sonntag, 27. April 2026, 11:00 Uhr. Bei einem Wochen-Ø von 66,5 °C ist das ein klarer Ausschlag – aber thermisch absolut nicht kritisch. Eher so ein Moment, wo ich kurz hängen bleib und mir denke: Okay, welcher Workunit-Mix war das jetzt? Oft ist das weniger „mehr Last“ (weil Last ist eh konstant), sondern eher ein anderer Instruktions-/Memory-Mix, der die CPU real mehr Watt ziehen lässt.
Passend dazu der Watt-Peak: 45 W am Sonntag, 27. April 2026, 4:00 Uhr. Das sind knapp 8,5 W über dem Schnitt – merkbar, aber nicht „aus dem Rahmen“. Für mich ist das genau die Sorte Spike, die zeigt: manche WUs drücken die CPU effizienter/“härter“ in die Silicon-Ecken, obwohl die Auslastungszahl gleich bleibt.
RAM-Peak lag bei 36,34 GB (58,05 %). Das ist deutlich, aber nicht knapp. Und weil Swap weiterhin 0 MB ist, fühlt sich das nicht nach Druck an, sondern nach „Einstein macht Einstein-Sachen“: großer Working Set, viel parallel im Speicher, aber sauber im RAM gehalten.
Und wichtig: keine Temperatur-Drosselung / keine Events. Also kein „Notbremsen“, keine unsichtbare Leistungsbremse – der Host hat die Peaks einfach genommen und weitergerechnet.
Fazit
Das war eine Woche, die sich richtig souverän anfühlt: 99,8 % CPU, Load 8,38, dabei im Schnitt nur 36,5 W und 66,5 °C. Nicht spektakulär, aber genau diese Art Stabilität ist eigentlich das, worauf ich am meisten stolz bin.
Einstein bleibt der RAM-Charakterkopf mit seinen ~5,1 GB Working Set pro Task und langen Laufzeiten um die 40 Stunden. PrimeGrid ist der CPU-pure Gegenpol (teils lange WUs, aber RAM-sparsam), und spacious/Asteroids bringen die Rotation rein, ohne das System zu stressen.
Und ja: 0 failed ist wieder das Highlight. Draußen klarer Himmel, drinnen klare Telemetrie – so darf ein Mittwochmorgen aussehen.
Diagramme
Begriffe kurz erklärt
- BOINC: BOINC ist eine Software, mit der viele Computer weltweit Rechenaufgaben gemeinsam erledigen, etwa für Wissenschaftsprojekte.
- Einstein@Home: Einstein@Home nutzt freiwillig gespendete Rechenleistung, um Signale von Pulsaren und Gravitationswellen zu suchen.
- PrimeGrid: PrimeGrid ist ein verteiltes Rechenprojekt, das gemeinsam nach besonders großen Primzahlen sucht.
- Asteroids@home: Asteroids@home berechnet mit weltweiter Rechenleistung die Formen und Bahnen von Asteroiden im Sonnensystem.
- Working Set: Das Working Set beschreibt den Bereich im Arbeitsspeicher, den ein Programm aktuell häufig benutzt.
- Memory-Controller: Der Memory-Controller steuert den Zugriff der CPU auf den Arbeitsspeicher und sorgt für schnellen Datenaustausch.
- Runqueue: Eine Runqueue ist die Warteschlange, in der der Scheduler alle laufbereiten Prozesse verwaltet.
- llrSR5: llrSR5 ist ein spezielles Programm, das große Zahlen auf ihre Primzahleigenschaft prüft, oft in PrimeGrid verwendet.
- RPC: RPC steht für Remote Procedure Call und ermöglicht, dass ein Programm Funktionen auf einem anderen Rechner ausführt.
- CPU-bound: CPU-bound bedeutet, dass eine Aufgabe hauptsächlich Rechenzeit braucht und kaum auf Speicher oder Netzwerk wartet.
- Scheduler: Der Scheduler entscheidet im Betriebssystem, welcher Prozess als Nächstes auf der CPU laufen darf.
