Heute früh beim Einloggen auf donau2space: draußen in Passau alles klar, 4,7 °C, kaum Wind. So eine Luft, wo man irgendwie automatisch ruhiger atmet. Und dann im Terminal dieses vertraute Bild: htop vollflächig bunt, aber ohne Stress. Keine Zacken, keine Aussetzer – einfach konstant Rechenarbeit. Genau mein Ding.
Schneller Überblick
Zusammenfassung
Das Logbuch dokumentiert eine Woche Serverbetrieb eines BOINC-Crunchers in Passau. Die CPU lief konstant unter hoher Auslastung (99,8 %) bei stabilen Temperaturen (Ø 65,4 °C). Der Speicherbedarf schwankte, getrieben von Einstein@Home-Aufgaben mit bis zu 4,8 GB pro Task. Es traten keine Ausfälle auf; alle 2.770 Rechenjobs wurden erfolgreich abgeschlossen.
Auf den Punkt
- Server-Uptime bei 1.551,28 Stunden unter Last
- Einstein@Home dominiert mit hohem RAM-Verbrauch pro Task
- Asteroids@home meist kurze Aufgaben, einige im Reporting-Limbo
- PrimeGrid mit sehr unterschiedlichen Laufzeiten, aktuell lange Aufgabe aktiv
- spacious@home minimale Systembelastung durch kleine Working Sets
- Keine Swaps und ausreichend Speicherreserven, Peak bei 38,33 GB RAM
- Auffällige Peaks: 74°C Temperatur, 45W Verbrauch, aber keine kritischen Zustände
FAQ
- Wie hoch war die durchschnittliche CPU-Auslastung?
- Die CPU war zu durchschnittlich 99,8 % ausgelastet.
- Welche Projekte haben den RAM-Verbrauch stark beeinflusst?
- Einstein@Home-Aufgaben benötigten pro Task rund 4,8 GB RAM.
- Gab es Systemausfälle oder fehlgeschlagene Jobs?
- Nein, alle 2.770 Jobs wurden erfolgreich abgeschlossen, keine Ausfälle registriert.
- Hat das System geswappt?
- Nein, es gab durchgehend 0 MB Swap-Nutzung.
Serverstatus & Telemetrie
Der Zeitraum geht von Mittwoch, 1. April 2026, 7:00 Uhr bis Mittwoch, 8. April 2026, 6:00 Uhr. Die Uptime steht am Ende bei 1.551,28 h. Das ist für mich jedes Mal so ein stilles Qualitätsmerkmal: nicht „lange an“, sondern lange an unter Last.
Die Durchschnittswerte erzählen eine ziemlich klare Woche:
- CPU Ø 34,7 W bei 99,8 % Usage. Heißt: praktisch Dauer-Vollast, aber eher im „effizient durchziehen“-Modus als im „alles ballert und wird heiß“. Für den i7-7700 fühlt sich das nach sauberem Workunit-Mix an.
- Ø 65,4 °C CPU-Temperatur. Das ist für 24/7-Crunching richtig entspannt. Nicht „kalt“, aber weit weg von irgendeinem thermischen Drama.
- Load1 Ø 8,36 bei 8 Threads: das ist genau diese Zahl, die sich richtig anfühlt. Die Runqueue ist voll, aber nicht überfüllt – also kaum Zeichen für systematisches Warten/Verstopfen.
Beim RAM war diese Woche mehr Bewegung drin als man bei „nur CPU-Last“ erwarten würde:
- RAM Ø 24,3 GB (38,8 %), Peak bis 38,33 GB (61,24 %).
- Swap: 0 MB durchgehend.
Diese Swap-Null macht mich ehrlich mehr happy als irgendein Credit-Sprung. Weil: hoher RAM-Verbrauch ist okay, aber sobald der Kernel anfängt zu swappen, wird aus Rechnen ganz schnell „ich verwalte mich selbst“.
Storage bleibt weiterhin komplett unkritisch:
- Disk total 201,1 GB, frei 172,9 GB.
- BOINC belegt 4.099,4 MB.
Und BOINC insgesamt war fast schon langweilig sauber (im besten Sinn): 2.770 Jobs erfolgreich, 0 failed, 0 RPC- oder Fetch-Failures. Da merk ich immer: die Maschine rechnet nicht nur warm – sie liefert.
Projekte im Detail
Diese Woche hat einen sehr klaren Charakter: Einstein@Home dominiert das Profil des Hosts, und die anderen Projekte sind eher die Rotation drumrum.
Einstein@Home – RAM-schwerer Langläufer
Einstein@Home steht bei 1.838.772 Credit und einem expavg von 34.719,22. Das ist nicht nur „viel“, das formt das ganze Systemverhalten.
Man sieht’s vor allem an den aktiven Tasks: mehrere Einstein-WUs laufen mit einem Working Set um 4.796–4.822 MB pro Task. Das ist nicht „ein bisschen Speicher“, das ist ein echter RAM-Footprint, der das Memory-Subsystem mitbeschäftigt.
Technisch heißt das für die Kiste:
- Einstein ist nicht nur CPU-bound, sondern auch speichercharakteristisch: großer Working Set → mehr Cache-/RAM-Traffic → oft etwas „dichter“ im Energieprofil.
- Wenn die CPU bei gleicher Auslastung weniger Leerlauf durch Memory-Stalls hat (oder einfach ein Workunit-Typ gerade sehr gut „durchzieht“), dann sieht man das eher in Watt und damit auch in Temperatur.
Die Laufzeiten sind dabei typisch Einstein: zuletzt im Log 4 Tasks mit Ø 40h 26m. Das ist Scheduler-seitig angenehm: wenig Task-Wechsel, wenig Bericht-Stress, lange stabile Phasen. Und genau diese langen Phasen fühlen sich in der Telemetrie dann so „glatt“ an.
Asteroids@home – kurze Rotation, aber gerade viel „Client-Zustand“
Asteroids@home steht bei 51.252,292263 Credit, expavg 930,55. In den zuletzt erledigten Tasks war’s ziemlich präsent: 13 Tasks mit Ø 1h 9m.
Das ist die Sorte Projekt, die schön rotiert: viele Einheiten, regelmäßig Reports, insgesamt aber meistens nicht der große RAM-/Watt-Treiber.
Spannend ist gerade eher der Status: in der aktiven Liste hängen mehrere Asteroids-Tasks auf „UNINITIALIZED READYTOREPORT“. Das wirkt nicht nach „rechnet schwer“, sondern nach Pipeline/Client-Zwischenzustand – Aufgaben sind quasi schon durch oder im Reporting-Limbo, aber nicht aktiv lastend. Solange RPC/FETCH sauber bei 0 Failures bleibt, fühlt sich das eher wie „BOINC hat gerade Verwaltungskram“ an, nicht wie ein echtes Problem.
PrimeGrid – von Snack bis Brocken
PrimeGrid steht bei 327.543,354276 Credit und expavg 5.500,2. In den letzten Meldungen waren’s 3 Tasks mit Ø 31m 33s – wobei man bei PrimeGrid halt immer merkt: da gibt’s kurze Happen und dann wieder Dinge, die plötzlich richtig Zeit fressen.
Aktuell läuft sogar eine PrimeGrid-Task (llrTRP…) und die hat schon 26h 56m CPU-Zeit bei 36,4 % done. Das ist so ein typischer Moment, wo PrimeGrid von „kurz“ auf „okay, das wird ein Abendprojekt“ umschaltet.
Vom Systemgefühl her ist PrimeGrid für mich meistens klassisch CPU-bound: Working Set hier 178 MB – nicht winzig, aber im Vergleich zu Einstein eher „leicht“. Es füllt die Kerne gut, ohne das RAM-Profil zu dominieren.
spacious@home – leichtfüßig, fast unsichtbar
spacious@home steht bei 77.746,263753 Credit, expavg 1.295,05, und ist aktuell mit 2 Tasks dabei.
Was ich daran mag: es ist oft der Gegenpol zu Einstein. Die aktiven Working Sets sind bei 4 MB und 27 MB – also fast schon „Cache-Warmhalten“. Dadurch bleibt das Projekt thermisch und energetisch meist sehr unauffällig, selbst wenn’s nebenher läuft.
climateprediction.net – aktuell nicht aktiv
climateprediction.net steht bei 0 (keine Jobs, keine Runtime). Also diese Woche schlicht kein Faktor im Mix.
Auffälligkeiten
Keine Temperatur-Drosselung, keine Flags – die Woche war insgesamt sehr souverän. Aber es gab trotzdem ein paar Momente, die rausstechen und für mich genau den Reiz ausmachen, warum ich überhaupt logge.
Erst die Peaks, als echte „Momente“:
- Max Temp: 74 °C am Sonntag, 5. April 2026, 12:00 Uhr
- Max Watt: 45 W am Sonntag, 5. April 2026, 6:00 Uhr
- Max RAM: 38,33 GB (61,24 %)
74 °C bei einem Wochenmittel von 65,4 °C ist ein klarer Ausreißer, aber keiner, der mich nervös macht. Wenn ich sowas sehe, denk ich eher: Okay, welcher Workunit-Typ hat da gerade den „besseren“ Instruktionsmix gehabt? Oder: War das ein Moment, wo mehrere RAM-schwere Einstein-Dinger parallel genau gleichzeitig richtig gezogen haben?
Der 45-W-Peak passt perfekt in dieses Bild. Für den i7-7700 ist das nicht absurd hoch, aber deutlich über dem Ø von 34,7 W. Und genau solche Sprünge sehe ich oft, wenn sich der Workunit-Mix ändert: gleiche 99,8 % Usage, aber intern mehr „echte“ Arbeit pro Zeiteinheit (Cache-Verhalten, Vektoranteile, weniger Stalls) → mehr Leistungsaufnahme → Temperatur zieht nach.
Beim RAM-Peak auf 38,33 GB werd ich automatisch aufmerksam, aber nicht, weil’s knapp wäre – eher weil’s zeigt, wie stark Einstein den Speicher prägen kann. Solange Swap bei 0 MB bleibt, fühlt sich das stabil an: viel genutzt, aber nicht überzogen.
Fazit
Unterm Strich war das eine Woche, die sich anfühlt wie ein sauber eingestellter Cruncher: 99,8 % CPU, Load1 8,36 auf 8 Threads, Temperaturen entspannt bei Ø 65,4 °C, und dann dieses BOINC-Gütesiegel: 2.770 erfolgreich, 0 failed.
Einstein@Home bleibt der Charakterkopf: lange Laufzeiten, pro Task rund 4,8 GB Working Set, und damit der größte Hebel für RAM-Profil und die kleinen Watt-/Temp-Ausschläge. Asteroids liefert flotte Rotation, PrimeGrid überrascht mal wieder mit „doch länger als gedacht“, und spacious läuft so leicht mit, dass man’s fast nur im Task-Tab merkt.
Und ja: ein Teil von mir findet so eine stabile Woche fast ein bisschen „zu ruhig“… aber dann sehe ich die 0 Failed Jobs und denk mir: genau so soll Dauerlast aussehen. Klar draußen, klar drinnen.
Diagramme
Begriffe kurz erklärt
- Einstein@Home: Ein verteiltes Rechenprojekt, bei dem Freiwillige ihre Computer nutzen, um nach Gravitationswellen und Pulsaren in Weltraumdaten zu suchen.
- Asteroids@home: Ein Projekt, das mit der freien Rechenleistung von PCs die Formen und Bahnen von Asteroiden im Sonnensystem berechnet.
- PrimeGrid: Ein verteiltes Projekt, das mithilfe vieler Computer große Primzahlen sucht und mathematische Muster untersucht.
- BOINC: Eine Plattform, mit der man die Rechenzeit seines Computers freiwillig für wissenschaftliche Projekte wie Einstein@Home bereitstellen kann.
- CPU-bound: Ein Programm ist CPU-bound, wenn seine Laufzeit hauptsächlich von der Rechenleistung des Prozessors abhängt.
- Working Set: Das Working Set ist die Menge an Daten und Code, die ein Programm gerade aktiv im Speicher nutzt.
- Memory-Stalls: Memory-Stalls entstehen, wenn die CPU auf Daten aus dem Arbeitsspeicher warten muss und kurzzeitig nichts rechnen kann.
- Cache-Verhalten: Das Cache-Verhalten beschreibt, wie gut ein Programm den schnellen Zwischenspeicher der CPU nutzt, um wiederholte Speicherzugriffe zu vermeiden.
- Instruktionsmix: Der Instruktionsmix zeigt, aus welchen Arten von Befehlen (z. B. Rechen-, Speicher-, Sprungbefehle) ein Programm hauptsächlich besteht.
- RPC: RPC (Remote Procedure Call) erlaubt es einem Programm, Funktionen auf einem anderen Computer auszuführen, als wären sie lokal.
- Fetch-Failures: Fetch-Failures treten auf, wenn der Prozessor eine Anweisung nicht rechtzeitig aus dem Speicher laden kann.
- Runqueue: Die Runqueue ist die Warteschlange, in der das Betriebssystem alle Prozesse sammelt, die gerade Rechenzeit auf der CPU wollen.
