Ich bin heute früh per SSH auf donau2space drauf, während es in Passau einfach nur klar und warm war – so diese ruhige Sorte Wetter, wo man nebenbei fast besser denken kann. Einmal Telemetrie auf, einmal kurz in die Kurven schauen… und das Ding macht genau das, wofür ich’s gemietet hab: dauerhaft Arbeit, ohne Drama.
Schneller Überblick
Zusammenfassung
Das Cruncher-Logbuch dokumentiert eine Woche stabilen Serverbetriebs mit 99,8 % CPU-Auslastung, einer durchschnittlichen Temperatur von 65,3 °C und durchgehend hoher Zuverlässigkeit ohne Fehlerfälle. Besonders Einstein@Home beansprucht viel RAM, während PrimeGrid, spacious@home und Asteroids@home unterschiedliche Lastprofile zeigen. Der Speicher blieb ausreichend, Swap kam nicht zum Einsatz.
Auf den Punkt
- Uptime: 2.727,28 Stunden, durchgängige Last ohne Abstürze.
- CPU-Auslastung konstant bei 99,8 %, Durchschnittstemperatur 65,3 °C.
- Maximaler RAM-Peak bei 30,5 GB, keine Swapauslastung.
- Einstein@Home dominiert RAM-Nutzung und Credits.
- PrimeGrid zeichnet sich durch sehr lange einzelne Tasks aus.
- spacious@home und Asteroids@home laufen mit geringem RAM-Bedarf und schnelleren Rotationen.
- Keine Fehler: 5.131 abgeschlossene Jobs, 0 fehlgeschlagen.
FAQ
- Wie hoch war der maximale RAM-Bedarf in der Woche?
- Der RAM-Peak lag bei 30,5 GB.
- Gab es Fehler oder Ausfälle während des beobachteten Zeitraums?
- Nein, 5.131 Jobs liefen erfolgreich, keine sind fehlgeschlagen.
- Welches Projekt hatte den größten Einfluss auf die RAM-Nutzung?
- Einstein@Home verursachte den höchsten RAM-Bedarf mit Working Sets bis zu 4.996 MB pro Task.
Serverstatus & Telemetrie
Der Zeitraum geht von Mittwoch, 20. Mai 2026, 7:00 Uhr bis Mittwoch, 27. Mai 2026, 6:00 Uhr. Die Uptime steht beim letzten Wert bei 2.727,28 h. Das ist für mich immer so ein unterschwelliger Stabilitäts-Check: lange Uptime + 24/7-Last heißt meist, dass nichts „schleichend“ wegkippt.
Was die Woche charakterisiert hat: konstant volle Auslastung, aber thermisch sogar etwas entspannter als letzte Woche.
Im Schnitt lag die CPU bei 34,4 W und 65,3 °C, bei 99,8 % Usage. Das fühlt sich richtig „gesund“ an: fast 100 % Rechenlast, aber die Temperatur bleibt im angenehmen Bereich. 65 °C als Wochenmittel unter Vollgas heißt für mich: kein Hitzestau, keine unnötige Spannung/Boost-Spielerei, einfach effizienter Dauerbetrieb.
Der Load1 Ø 8,35 bei 8 Threads ist auch wieder genau diese saubere Cruncher-Zahl. Wenn ich htop offen hab und das so sehe, wirkt es einfach „rund“: alle Threads haben Arbeit, aber es staut sich nicht in der Runqueue. Das ist keine Benchmark-Spitze – das ist ehrliche Dauerlast.
Beim Speicher ist es diese Woche insgesamt entspannt geblieben: RAM Ø 20,5 GB (32,7 %), Peak bei 30,5 GB (48,73 %), und ganz wichtig: Swap 0 MB. 30,5 GB sind auf einem 64‑GB-Host nicht knapp, aber es ist genug, dass man merkt: da läuft nicht nur „leichter Kram“. Dass Swap komplett bei 0 bleibt, ist für mich die eigentliche gute Nachricht – weil Swap wäre der Punkt, wo Rechenzeit plötzlich in Latenz und I/O versickert.
Storage: weiterhin komplett unkritisch. 201,1 GB total, 170,1 GB frei. BOINC nutzt 6.873,33 MB – im Kontext ist das absolut okay, und vor allem: kein wildes Anwachsen.
BOINC-seitig war’s wieder richtig sauber:
- 5.131 Jobs succeeded, 0 failed
- 0 RPC failures, 0 fetch failures
Diese „0 failed“ bei so vielen Jobs ist für mich jedes Mal mehr wert als jeder Credit-Sprung. Fehlerfreiheit unter Dauerlast ist wie ein stiller Beweis, dass CPU/RAM/Kernel einfach stabil zusammenarbeiten.
Projekte im Detail
Vom Charakter her war das klar ein Mix aus Einstein als schwerer Dauerläufer plus spacious/Asteroids als schnelle Rotation, und PrimeGrid als Langläufer-Block, der einfach stundenlang durchzieht.
Einstein@Home – CPU-bound, aber mit richtig RAM-Fußabdruck
Einstein dominiert bei den Kennzahlen komplett: 3.254.562 Credit und ein expavg von 38.896,66. Das ist nicht nur „viel Credit“, das ist auch systemisch spürbar – vor allem am RAM.
Bei den aktiven Einstein-Tasks sieht man Working Sets von 2.361 MB bis hoch zu 4.996 MB pro Task. Wenn mehrere davon parallel laufen, ist das nicht „ein bisschen mehr RAM“, sondern direkt ein anderes Profil: mehr Daten im RAM, mehr Cache-/Memory-Controller-Aktivität, und dadurch kann sich die Leistungsaufnahme bei gleicher CPU-Usage auch anders anfühlen.
Und genau da passt auch der Wochen-Peak: 30,5 GB RAM. Das schreit nicht nach Problem – eher nach „Einstein ist gerade im dicken WU-Mix unterwegs“, aber ohne Druck, weil Swap eben nicht anspringt.
Was ich an Einstein mag: wenig Hektik. Lange Workunits, wenig Rotation, der Scheduler hat’s leicht. Das läuft so stoisch, dass man fast vergisst, wie viel da eigentlich im Hintergrund passiert.
PrimeGrid – der „ich bin noch nicht fertig“-Task
PrimeGrid steht bei 605.474,201628 Credit und expavg 5.373,74. Vom Gefühl her ist PrimeGrid bei mir immer dieses Projekt, das weniger nach „Rotation“ aussieht und mehr nach: hier, nimm diesen Block und kaue dran.
Das sieht man auch konkret: Ein zuletzt erledigter PrimeGrid-Task war ein echter Brocken mit 73h 27m. Sowas ist CPU-bound in Reinform, aber eben mit sehr langer Bindung pro Task. Scheduler-seitig heißt das: weniger Task-Wechsel, weniger Overhead – dafür ist man lange an genau diesem WU-Typ.
RAM-mäßig wirkt PrimeGrid im Vergleich zu Einstein fast leicht: ein aktiver Task mit 172 MB Working Set ist im Kontext der Einstein-GB wirklich „klein“.
spacious@home – schnelle Rotation, kaum Systemstress
spacious@home steht bei 141.296,263753 Credit und expavg 1.255,77. In den zuletzt erledigten Tasks sieht man den Charakter perfekt: 14 Tasks mit Ø 50m 31s. Das ist schnelle Rotation, und ich merke das immer daran, dass ständig neue Tasks „durchrutschen“.
RAM-Footprint ist dabei winzig: bei den aktiven Tasks sind es 4 MB und 27 MB Working Set. Das Projekt ist für den Host fast „unauffällig“ – CPU wird beschäftigt, aber RAM bleibt frei, und thermisch ist es meistens auch nicht das, was die Peaks triggert.
Asteroids@home – schlank, mittlere Laufzeiten
Asteroids@home steht bei 97.913,1212 Credit und expavg 973,41. Zuletzt waren es 4 Tasks mit Ø 1h 13m. Das ist so eine angenehm mittlere Taktung: nicht so kurz wie spacious, nicht so lang wie PrimeGrid/Einstein.
Aktuell fallen mir hier eher die vielen Einträge auf, die UNINITIALIZED READYTOREPORT stehen. Das ist kein Fehler an sich (vor allem nicht, wenn am Ende 0 failed bleibt), aber es ist so ein kleines „Scheduler-/Client-Zwischenzustand“-Ding, wo ich automatisch genauer hinschaue, ob da einfach nur Reporting ansteht oder ob gerade irgendwas im Client-Flow hängt. Bis jetzt spricht aber alles dafür: läuft sauber, nur gerade in einem Übergang.
climateprediction.net
Steht weiterhin bei 0 Credit, 0 Jobs, 0 Runtime. Also: kein Einfluss.
Auffälligkeiten
Keine Temperatur-Drosselung, keine Events. Und das ist die Sorte „Langweilig“, die ich wirklich mag.
Trotzdem gab’s einen klaren Moment in den Peaks: Am Dienstag, 26. Mai 2026, 11:00 Uhr lagen sowohl der Max-Temp-Peak bei 74 °C als auch der Max-Watt-Peak bei 44 W.
74 °C ist für mich sofort so ein kurzer Blick-mit-den-Augenbrauen: nicht gefährlich, aber eindeutig ein Ausschlag. Da denke ich nicht „oh nein“, sondern eher: Okay, welcher Workunit-Mix war das? Wenn Watt und Temp gleichzeitig hochgehen, ist es oft genau das: anderer Instruktionsmix, mehr Speichertraffic, vielleicht gerade mehrere Einstein-WUs mit großen Working Sets plus irgendwas rotierendes dazu. CPU-Usage bleibt bei 99,8 %, aber elektrisch/thermisch fühlt sich das plötzlich „dichter“ an.
Und weil der Wochenschnitt bei 65,3 °C liegt, wirkt dieser Peak nicht wie ein Trend nach oben – eher wie ein einzelner Spike in einer ansonsten stabilen Linie.
Fazit
Unterm Strich war das eine sehr stabile, effiziente Cruncher-Woche: 99,8 % CPU, Load1 8,35, dabei im Schnitt nur 34,4 W und 65,3 °C. Das ist genau die Sorte Dauerbetrieb, bei der ich das Gefühl habe: der i7‑7700 wird nicht „verheizt“, sondern sinnvoll ausgelastet.
Einstein@Home prägt weiterhin das Systembild – vor allem durch die mehrere-GB-Working-Sets, die den RAM-Peak auf 30,5 GB erklären, ohne dass es auch nur in die Nähe von Swap geht. PrimeGrid liefert die Langläufer (die 73h 27m sind schon eine Ansage), spacious bringt schnelle Rotation ohne Druck, und Asteroids bleibt angenehm schlank.
Und mein persönlicher Wochen-Lieblingswert ist wieder der langweiligste: 0 failed bei 5.131 erfolgreichen Jobs. Das ist kein Rekordgefühl – das ist dieses leise „passt“, während der Server einfach weiterrechnet. Genau mein Ding. 🙂
Diagramme
Begriffe kurz erklärt
- SSH: Ein sicheres Protokoll, mit dem man sich aus der Ferne auf einem Linux-Rechner einloggen und Befehle ausführen kann.
- Telemetrie: Automatisches Sammeln und Übertragen von Messdaten, zum Beispiel Temperaturwerte von Sensoren an eine zentrale Auswertung.
- CPU-bound: Ein Prozess ist CPU-bound, wenn die Rechengeschwindigkeit des Prozessors seine Leistung begrenzt, nicht etwa die Festplatte.
- RAM-Fußabdruck: Beschreibt, wie viel Arbeitsspeicher ein Programm tatsächlich belegt – also seinen Speicherverbrauch im RAM.
- Uptime: Zeigt an, wie lange ein System ohne Neustart ununterbrochen läuft, meist in Tagen, Stunden und Minuten.
- Load1: Ein Messwert, der zeigt, wie stark ein System in der letzten Minute ausgelastet war – je höher, desto mehr zu tun für die CPU.
- Runqueue: Liste der Prozesse, die gerade darauf warten, von der CPU abgearbeitet zu werden.
- Swap: Bereich auf der Festplatte, der als Ersatzspeicher dient, wenn der RAM voll ist – langsamer, aber hilfreich gegen Abstürze.
- I/O: Kurz für Eingabe/Ausgabe – beschreibt Datenbewegungen zwischen Prozessor, Speicher und Geräten wie Festplatten.
- RPC: Remote Procedure Call: Eine Methode, mit der Programme Funktionen auf entfernten Rechnern ausführen können, als wären sie lokal.
- Scheduler: Teil des Betriebssystems, der entscheidet, welcher Prozess wann und wie lange auf der CPU läuft.
- Working Set: Die Menge an Speicher, die ein Programm aktuell aktiv nutzt, also seine „heißen“ Daten im RAM.
- Memory-Controller-Aktivität: Misst, wie stark der Speichercontroller beansprucht wird, also wie viel Datenverkehr zwischen CPU und RAM läuft.
- Workunit: Ein kleiner, abgeschlossener Teil einer größeren Rechenaufgabe, den Computer einzeln bearbeiten und auswerten können.
- Instruktionsmix: Zeigt, welche Arten von Maschinenbefehlen ein Programm hauptsächlich ausführt, z. B. Rechnen, Vergleichen oder Speicherzugriffe.
