Heute beim Einloggen war’s so ein klassischer „erst Passau, dann Payload“-Moment: draußen meist klar, so um die 15,0 °C, quasi kein Wind – und drinnen auf donau2space wieder dieses beruhigende Bild: htop auf, acht Threads voll, nichts zappelt, nichts schreit. Einfach Arbeit, konstant.
Schneller Überblick
Zusammenfassung
Das Logbuch dokumentiert die Stabilität und Leistung des donau2space-Servers zwischen 29.04. und 06.05.2026. Die CPU-Nutzung lag im Schnitt bei 99,5 %, die durchschnittliche Temperatur bei 67,5 °C, ohne kritische Vorfälle. Verschiedene BOINC-Projekte wie Einstein@Home und PrimeGrid bestimmten den Ressourcenverbrauch. Es gab keine Rechenfehler und keine Systemausfälle, der Speicher blieb unter Kontrolle.
Auf den Punkt
- Uptime des Servers: 2.224,27 Stunden ohne Unterbrechung
- CPU-Auslastung durchgängig bei 99,5 %, Durchschnittstemperatur 67,5 °C
- Kein Swap genutzt, RAM-Peak 31,82 GB bei 64 GB Gesamt-RAM
- 4.189 abgeschlossene BOINC-Jobs, keine Fehlberechnungen
- Einstein@Home mit höchsten RAM-Anforderungen (~5,1 GB/Task), lange Laufzeiten
- PrimeGrid CPU-intensiv, Tasks bis 57 Stunden Laufzeit, geringer RAM-Bedarf
- Kurze, RAM-schonende Tasks bei spacious@home und Asteroids@home
FAQ
- Wie hoch war die durchschnittliche CPU-Auslastung in der Woche?
- Die durchschnittliche CPU-Auslastung lag bei 99,5 %.
- Welche Projekte beanspruchten den meisten RAM?
- Einstein@Home hatte die höchsten RAM-Anforderungen mit etwa 5,1 GB Working Set pro Task.
- Gab es während des Berichtszeitraums Fehlberechnungen oder Systemausfälle?
- Nein, es gab keine Fehlberechnungen und keinen Swap, das System lief stabil.
Serverstatus & Telemetrie
Der Zeitraum geht von Mittwoch, 29. April 2026, 8:00 Uhr bis Mittwoch, 6. Mai 2026, 7:00 Uhr. Die Uptime steht beim letzten Wert bei 2.224,27 h. Das ist für mich immer so ein stilles Qualitätsmerkmal: nicht „wow“, sondern „läuft“ – und zwar ohne dass irgendwo heimlich was wegfault.
Im Schnitt war die Woche ziemlich eindeutig: Vollgas, aber kontrolliert.
Die CPU lag durchschnittlich bei 37,1 W und 67,5 °C bei 99,5 % Usage. Das ist genau der Bereich, den ich bei 24/7-Last am i7‑7700 gern sehe: nicht kalt (weil dann stimmt oft was mit Last/States nicht), aber auch weit weg von „thermisch am Anschlag“.
Der Load1 Ø 8,34 bei 8 Threads fühlt sich wieder „richtig“ an. Das ist dieses Bild von: alle Kerne haben zu tun, die Runqueue ist nicht leer, aber du läufst auch nicht in so eine Scheduling-Schlange rein, wo sich Tasks stapeln und du eigentlich nur Overhead produzierst.
RAM war spürbar belegt, aber ohne Druck: Ø 26,9 GB (43,0 %), Peak bei 31,82 GB (50,84 %). Und das Wichtigste dabei: Swap 0 MB. Genau das trennt für mich „viel RAM-Nutzung“ von „Problem“ – solange nichts ausgelagert wird, bleibt die Rechenleistung da, wo sie hingehört, und du fängst nicht an, Speicher über die Platte zu schieben.
Storage ist total entspannt: 201,1 GB total, 175,5 GB frei. BOINC selbst belegt 1.378,45 MB – das ist eher ein „passt in die Hosentasche“-Footprint, nichts was irgendwie knapp wirkt.
BOINC-seitig war’s einfach sauber: 4.189 Jobs succeeded, 0 failed, dazu 0 RPC failures und 0 fetch failures. Diese Null bei „failed“ ist für mich immer noch der bessere Dopamin-Hit als steigende Credits – weil das heißt: Last ja, aber keine schleichenden Fehler, keine instabilen WUs, kein Client-Gezicke.
Projekte im Detail
Vom Charakter her dominiert weiterhin ganz klar ein Projekt das Systemprofil – und die anderen geben Takt und Rotation.
Einstein@Home – RAM-lastiger Langläufer, der den Host „prägt“
Einstein ist bei 2.443.176 Credit und einem expavg von 27.592,1. Das ist nicht nur „läuft mit“, das ist das Grundrauschen.
Man sieht’s auch an den aktiven Tasks: mehrere Einstein-WUs laufen mit ~5.153 MB bis 5.177 MB Working Set pro Task. Das ist schon eine Ansage – nicht kritisch bei 64 GB RAM, aber es erklärt sofort, warum der RAM-Durchschnitt nicht bei 4–8 GB rumdümpelt.
Technisch ist das genau diese Mischung aus CPU-Last + hohem Memory-Footprint, die ich spannend finde: selbst wenn die CPU-Auslastung konstant bei ~100 % steht, kann mehr Speichertraffic (Cache/Memory-Controller) kleine Verschiebungen bei Watt und Temperatur auslösen. Nicht als Drama, eher als: „ah, das ist jetzt ein anderer Workunit-Typ/Mix“.
Auch die Laufzeiten passen zu „ruhig, aber schwer“: zuletzt erledigte Einstein-Tasks lagen bei Ø 39h 30m. Das ist schedulertechnisch angenehm: wenig Taskwechsel, wenig Reporting-Hektik, lange gleichmäßige Last – der Host kann einfach durchziehen.
PrimeGrid – CPU-bound, zäh in der Laufzeit
PrimeGrid steht bei 492.047,741363 Credit, expavg 6.621,29. Und PrimeGrid macht wieder das, was es gerne macht: nicht unbedingt viele Tasks, aber wenn einer läuft, dann richtig.
In den zuletzt erledigten Tasks war 1 PrimeGrid-Task mit 57h 51m dabei. Das ist schon so ein Brocken, wo ich innerlich immer kurz nicke: CPU-bound, wenig Schnickschnack, aber lange am Stück.
Aktiv läuft auch gerade wieder eine PrimeGrid-WU (llrSR5) mit 282 MB Working Set. Im Vergleich zu Einstein ist das RAM-seitig fast nichts – das ist genau der Unterschied: PrimeGrid drückt eher „reine Rechenarbeit“ auf die ALUs/FPUs, während Einstein zusätzlich spürbar über den Speicherpfad atmet.
spacious@home – kurze Rotation, fast unsichtbar im RAM
spacious@home ist bei 115.546,263753 Credit und expavg 1.431,35. Das fühlt sich auch in den Taskzeiten so an: zuletzt 9 Tasks mit Ø 48m 7s.
Diese kurze Rotation merkt man im Alltag: mehr „Bewegung“ im Scheduler, öfter Reports, öfter neue WUs. Ressourcenmäßig ist es hier superzahm: aktive Tasks mit 4 MB bis 27 MB Working Set. Das ist so wenig, dass es in der Gesamttelemetrie fast untergeht – aber genau deshalb ist spacious ein guter „Füller“, wenn man Kerne beschäftigt halten will, ohne RAM-Druck zu erzeugen.
Asteroids@home – moderat lange Tasks, sehr schlank
Asteroids@home steht bei 79.298,864763 Credit und expavg 1.067,76. Zuletzt waren es 7 Tasks mit Ø 1h 11m – also länger als spacious, aber weit weg von Einstein/PrimeGrid.
Das Ressourcenprofil ist angenehm leicht: ein aktiver Task liegt bei 14 MB Working Set. CPU wird gut beschäftigt, RAM ist praktisch egal.
Im aktiven Set fallen allerdings viele Einträge als UNINITIALIZED (teils READY_TO_REPORT) auf. Solange die Infrastruktur sauber bleibt – und das tut sie hier mit 0 RPC failures und 0 fetch failures – wirkt das auf mich eher wie „Client-/Statuszustand“ als wie echte Rechenprobleme. Wenn da was faul wäre, würde es sich ziemlich schnell in failed oder Retries zeigen. Tut’s nicht.
climateprediction.net – weiterhin nicht im Mix
Bleibt bei 0 Credit, 0 Jobs, 0 Runtime. Diese Woche kein Einfluss.
Auffälligkeiten
Im Mittel war alles glatt, aber ein paar „Momente“ gab’s natürlich trotzdem.
Der höchste Temperaturpunkt lag bei 77 °C am Samstag, 3. Mai 2026, 16:00 Uhr. Bei einem Wochen-Ø von 67,5 °C ist das ein klarer Ausschlag – aber thermisch komplett entspannt. 77 °C ist nicht „gefährlich“, das ist eher die Sorte Peak, wo ich kurz hängen bleibe und mir denke: welcher Mix war das gerade? Bei Dauer-100-%-CPU sind solche Peaks fast immer ein Hinweis auf anderen Instruktions-/Memory-Mix (oder einfach effizienter „dichtes“ Rechnen), nicht darauf, dass plötzlich „mehr als 100 %“ passiert.
Der Watt-Peak war 44 W am Mittwoch, 30. April 2026, 20:00 Uhr. Das sind rund 6,9 W über dem Durchschnitt von 37,1 W – merkbar, aber nicht wild. Genau die Art Spike, die ich bei Projektwechseln oder wechselnden WU-Charakteren erwarte: gleiche Auslastungszahl, aber andere elektrische Realität.
RAM-Peak bei 31,82 GB (50,84 %) ist ebenfalls eher „interessant“ als „knapp“. Mit 64 GB Gesamt-RAM und Swap 0 MB fühlt sich das stabil an. Eher so: Einstein zieht sich seinen großen Working-Set, und der Host nimmt’s gelassen.
Und wichtig: keine Temperatur-Drosselung / keine Events. Also keine versteckte Bremse, kein „wir retten uns gerade selbst“ – die Kiste hat die Peaks einfach weggesteckt und weitergerechnet.
Fazit
Das war eine Woche, die ich als souverän und effizient einsortiere: 99,5 % CPU, Load 8,34, dabei im Schnitt 37,1 W und 67,5 °C. Nicht spektakulär, aber genau diese langweilige Stabilität ist halt das, worauf man im 24/7-Crunching baut.
Einstein bleibt der Charakterkopf: lange Laufzeiten um ~40 Stunden und ~5,1 GB Working Set pro Task – das prägt RAM und (indirekt) auch das Temperatur/Watt-Gefühl. PrimeGrid ist der CPU-pure Marathonläufer, spacious bringt die schnelle Rotation rein, Asteroids bleibt angenehm schlank.
Und ja: 0 failed ist wieder mein Wochenhighlight. Draußen mild und klar, drinnen sauberer Crunch – kann von mir aus gerne so weiterlaufen. 🙂
Diagramme
Begriffe kurz erklärt
- BOINC: Ein Programm, das Rechenleistung vieler Computer bündelt, um wissenschaftliche Projekte gemeinsam zu berechnen.
- Einstein@Home: Ein Projekt auf BOINC, das nach Gravitationswellen und Pulsaren in Weltraumdaten sucht.
- PrimeGrid: Ein BOINC-Projekt, das nach besonders großen Primzahlen sucht.
- Asteroids@home: Ein Projekt, das Asteroidenbahnen berechnet, um deren Form und Bewegung besser zu verstehen.
- Working Set: Der Teil des Speichers, den ein Programm aktuell aktiv nutzt; zu klein bedeutet häufiges Nachladen.
- CPU-bound: Bezeichnet Programme, deren Geschwindigkeit hauptsächlich von der Rechenleistung der CPU abhängt.
- Memory-Controller: Ein Bauteil, das den Datenverkehr zwischen Prozessor und Arbeitsspeicher steuert.
- Scheduler: Der Teil des Betriebssystems, der entscheidet, welche Prozesse wann auf der CPU laufen dürfen.
- RPC failure: Ein Fehler, wenn ein Programm über das Netzwerk keine Antwort auf eine entfernte Anfrage erhält.
- llrSR5: Ein spezielles Rechenprogramm in PrimeGrid, das Primzahltests effizient auf mehreren Rechenkernen durchführt.
- Runqueue: Eine Warteschlange im Betriebssystem, in der Prozesse auf ihre Ausführung durch die CPU warten.
