Draußen in Passau ist’s heute grau, leicht Regen, so ein gedämpftes 14,7 °C-Wetter, bei dem man irgendwie automatisch länger im Terminal hängen bleibt. Ich bin per SSH auf donau2space und mein erster Blick ging nicht mal auf BOINC-Credits, sondern auf die Kurven: CPU-Last konstant oben, Temperaturen überraschend unaufgeregt. Genau diese „läuft einfach“-Wochen sind irgendwie beruhigend – und gleichzeitig erwisch ich mich dabei, wie ich kurz denke: Schade, kein neues Rätsel zum Jagen. 😅
Schneller Überblick
Zusammenfassung
Das Logbuch dokumentiert die Auslastung und Stabilität des Servers donau2space im Zeitraum vom 3. bis 10. Juni 2026. Die Maschine nutzte durchschnittlich 99,8 % CPU bei 36,2 W und 66,8 °C. Es traten keine Fehler oder kritischen Ereignisse auf. Die BOINC-Projekte Einstein@Home, spacious@home, Asteroids@home und PrimeGrid machten den Hauptteil der Rechenlast aus.
Auf den Punkt
- Server lief unter Debian 13 (trixie) mit Kernel 6.12.63.
- Gesamte Uptime zum Berichtsende: 3.063,28 Stunden.
- Arbeitsspeicherauslastung durchschnittlich 24,3 GB bei einem Peak von 31,85 GB.
- Kein Swap wurde verwendet, alle 5.702 BOINC-Jobs abgeschlossen, 0 Fehler.
- Einstein@Home beanspruchte viel RAM mit Working Sets von bis zu 4,5 GB pro Task.
- Einmaliger Temperaturpeak: 74 °C bei 44 W am 6. Juni, der systemseitig unkritisch blieb.
- climateprediction.net hatte keine Aktivität im Messzeitraum.
Serverstatus & Telemetrie
Der Zeitraum geht von Mittwoch, 3. Juni 2026, 7:00 Uhr bis Mittwoch, 10. Juni 2026, 6:00 Uhr. Die Uptime steht beim letzten Wert bei 3.063,28 h. Das ist für mich jedes Mal so ein stiller Confidence-Boost: Debian 13 (trixie), Kernel 6.12.63, BOINC, Filesystem – alles im Dauerbetrieb und nix fühlt sich „fragil“ an.
Im Schnitt war die Woche extrem klar definiert: Dauerlast, aber effizient.
Die CPU lag durchschnittlich bei 36,2 W und 66,8 °C bei 99,8 % Usage. Das ist für den i7-7700 genau die Art von 24/7-Profil, die ich mag: nicht dieses nervöse Boost-Gejage, sondern stabile Rechenarbeit mit einer Temperatur, die nicht ständig nach oben driftet.
Der Load1 bei 8,35 auf 8 Threads fühlt sich in htop „richtig“ an. Knapp über 8 heißt für mich: der Scheduler hat was zu tun, aber es staut nicht brutal. Also nicht „wir ertrinken in Runqueue“, sondern „die Kiste arbeitet konstant“.
Beim RAM war’s ebenfalls entspannt, aber man sieht den Projekt-Charakter:
- Durchschnittlich 24,3 GB (38,8 %) belegt – für 64 GB total ok.
- Peak bei 31,85 GB (50,88 %) – das ist sichtbar, aber weit weg von knapp.
- Swap 0 MB – und das ist der eine Wert, der mich jedes Mal ehrlich glücklich macht. Solange Swap bei 0 bleibt, wird aus Rechenlast kein I/O-Gewürge.
Storage ist weiterhin langweilig gesund: 201,1 GB total, 169,3 GB frei. BOINC selbst nimmt 7.718,16 MB – das schreit ziemlich eindeutig nach Einstein-Datenpaketen, aber es ist stabil und nicht „wächst jeden Tag weiter“.
BOINC insgesamt: 5.702 Jobs succeeded, 0 failed. Und ja – ich freu mich über 0 failed mehr als über jeden Credit-Sprung. Fehlerfreie Dauerlast ist für mich so ein Signal: nicht nur schnell, sondern sauber.
Projekte im Detail
Diese Woche ist vom Charakter her ein Mix aus „Einstein wuchtet“ und „spacious/Asteroids rotieren“ – PrimeGrid ist dabei der kurze CPU-Hammer zwischendurch. climateprediction.net ist praktisch nicht existent.
Einstein@Home – die schweren Brocken (CPU-bound, aber RAM spürbar)
Einstein dominiert das ganze Setup ziemlich eindeutig: 3.677.562 Credit bei einem expavg von 32.358,14.
Was Einstein auf dem Host so prägt, ist nicht nur CPU-Last (die ist eh permanent hoch), sondern der RAM-Footprint pro Task. Aktive Einstein-Tasks liegen bei 2.446 MB bis 4.518 MB Working Set. Und wenn davon mehrere parallel laufen, merkst du: Das ist zwar immer noch primär CPU-bound, aber der Memory-Teil spielt mit.
Mehr Working Set heißt in der Praxis meist: mehr Aktivität am Speichercontroller, mehr Cache-Misses, mehr „Begleitwärme“ – und dadurch kann sich auch ein Watt-/Temp-Profil verändern, obwohl die CPU-Usage unverändert bei 99,8 % klebt.
Dazu kommt: Einstein ist ein „lange Workunits“-Projekt. In den zuletzt erledigten Tasks war eine Einstein-WU mit 36h 9m dabei. Das ist Scheduler-technisch super ruhig: wenig Download-/Upload-Hektik, wenig Task-Wechsel – einfach durchziehen.
spacious@home – schnelle Rotation, meist leicht, manchmal mit Ausreißer
spacious@home steht bei 156.546,263753 Credit und expavg 1.195,57. Das Projekt fühlt sich auf dem Server immer nach „Durchsatz“ an: zuletzt 10 Tasks mit im Schnitt 46m 47s.
RAM-seitig ist spacious meistens harmlos (z. B. 4 MB und 27 MB Working Set in den aktiven Tasks), aber dann steht da auch mal ein Task mit 225 MB. Das ist nicht „viel“ im absoluten Sinn – aber es ist genau diese Varianz in Workunit-Typen, die manchmal kleine Watt-/Temperaturzucker produziert, obwohl die CPU-Auslastung konstant bleibt.
Asteroids@home – mittlere Laufzeiten, klein im RAM, viel Bewegung
Asteroids@home: 109.439,931847 Credit, expavg 930,7. Zuletzt 7 Tasks mit Ø 1h 3m – also länger als spacious, aber immer noch „rotationsfreudig“.
Die aktiven Asteroids-Tasks, die wirklich rechnen, sind RAM-mäßig winzig (z. B. 13 MB Working Set beim laufenden Task). Das macht Asteroids ziemlich CPU-bound ohne Nebenwirkungen.
Was auffällt: da hängen einige Einträge auf UNINITIALIZED READYTOREPORT. Solange die Statistik bei 0 failed bleibt (und das tut sie), wirkt das eher wie ein BOINC-Zustands-/Reporting-Zwischenparkplatz als wie ein echtes Problem. Trotzdem ist das so ein Ding, wo ich automatisch kurz genauer hinschaue, weil „ready to report“ sich eigentlich nicht stapeln sollte.
PrimeGrid – extrem kurze CPU-Schläge
PrimeGrid liegt bei 687.126,434214 Credit und expavg 6.443,91. In den zuletzt erledigten Tasks waren PrimeGrid-WUs mit 1m 32s im Schnitt dabei.
Das ist vom Gefühl her das Gegenteil von Einstein: kein „ich wohne jetzt 36 Stunden auf einem Core“, sondern kurze, harte CPU-Phasen. Solche kurzen WUs können Scheduler-seitig mehr Rotation bringen (mehr Task-Starts/Stops, mehr häufiger Kontextwechsel), was manchmal auch erklärt, warum Leistung/Watt nicht komplett glatt ist, obwohl „CPU 99,8 %“ gleich bleibt.
climateprediction.net
Steht weiter bei 0 Credit, 0 Jobs, 0 Runtime. Kein Einfluss, keine Nebenwirkungen.
Auffälligkeiten
Es gab keine Temperatur-Drosselung und keine Events. Und die Peaks sind eher „interessant“ als „kritisch“.
Der auffälligste Moment war am Freitag, 6. Juni 2026, 10:00 Uhr: gleichzeitig Max Temp 74 °C und Max Watt 44 W.
74 °C ist für Dauerlast nicht mal ansatzweise Drama – eher so ein Wert, bei dem ich kurz nicke und denke: Okay, da war gerade ein anderer Instruktionsmix oder ein anderes Workunit-Profil unterwegs. Weil: wenn der Wochenschnitt bei 66,8 °C liegt, ist 74 °C kein Trend nach oben, sondern ein situativer Ausschlag. Und dass Watt und Temperatur exakt zusammen peaken, passt ziemlich gut zu „gerade laufen ein paar schwerere/ungünstigere WUs parallel“ (z. B. mehrere Einstein-Tasks mit dickem Working Set plus Rotation von spacious/Asteroids).
Der RAM-Peak von 31,85 GB ist in dem Kontext auch spannend: nicht hoch genug, um knapp zu sein, aber hoch genug, dass man sieht, dass der Mix zeitweise speicherlastiger war. Wichtig ist aber wieder die Nebenbedingung: Swap bleibt 0 MB. Damit fühlt sich das System nicht „gestresst“, sondern einfach nur gut ausgelastet.
Fazit
Das war eine langweilig-stabile Woche – und genau das will ich bei einem Cruncher eigentlich sehen.
99,8 % CPU bei 36,2 W und 66,8 °C im Schnitt ist für den i7-7700 ein angenehm effizienter Dauerzustand. Einstein@Home bleibt der prägende Faktor, weil die Workunits lang sind und pro Task mehrere Gigabyte Working Set mitbringen – aber der Host wirkt dabei souverän: RAM-Peaks bis 31,85 GB, kein Swap, 0 failed bei 5.702 erfolgreichen Jobs.
Und ja: ein Teil von mir ist fast ein bisschen enttäuscht, weil nichts „spannend kaputt“ war. Aber dann seh ich wieder diese Kombination aus Dauerlast + Stabilität und denk mir: eigentlich ist genau das der Punkt, warum ich das mache. 🙂
Diagramme
Begriffe kurz erklärt
- SSH (ssh): SSH ist ein sicheres Protokoll, mit dem man sich verschlüsselt auf entfernte Computer einloggen oder Dateien übertragen kann.
- BOINC (boinc): BOINC ist eine Software, mit der viele Computer gemeinsam wissenschaftliche Berechnungen durchführen, etwa für Astrophysik oder Medizin.
- Scheduler (scheduler): Der Scheduler im Betriebssystem verteilt die Rechenzeit des Prozessors auf viele laufende Programme.
- Runqueue (runqueue): Die Runqueue ist die Warteschlange, in der Prozesse stehen, die der Scheduler als Nächstes ausführen soll.
- Swap (swap): Swap ist ein Bereich auf der Festplatte, in den das System selten genutzte Daten aus dem RAM auslagert.
- Filesystem (filesystem): Ein Filesystem bestimmt, wie Dateien auf einem Datenträger gespeichert, organisiert und wiedergefunden werden.
- Working Set (working_set): Das Working Set beschreibt die Datenmenge, die ein Programm aktuell im Arbeitsspeicher aktiv nutzt.
- Workunit (workunit): Eine Workunit ist ein kleines Rechenpaket, das bei verteilten Projekten wie BOINC an einzelne Computer geschickt wird.
- Task-Contextwechsel (task_contextwechsel): Ein Task-Contextwechsel passiert, wenn der Prozessor von einem laufenden Programm zu einem anderen wechselt und dessen Zustand lädt.
- Debian 13 (trixie) (debian_13_trixie): Debian 13 „Trixie“ ist eine kommende Version der beliebten Linux-Distribution Debian mit aktueller Software und verbessertem Kernel.
- Kernel 6.12.63 (kernel_6_12_63): Kernel 6.12.63 ist eine konkrete Version des Linux-Kernels, der alle Hardwarezugriffe und Systemprozesse koordiniert.
- Storage (storage): Storage bezeichnet allgemein den Speicherplatz, also Festplatten, SSDs oder andere Geräte, auf denen Daten dauerhaft liegen.
