Ich bin heute früh reingetappt wie immer: draußen in Passau alles grau & gedämpft, so 7,4 °C, kaum Wind – und drinnen dann dieser Kontrast, den ich irgendwie liebe. SSH drauf, einmal kurz Telemetrie auf… und der Server macht einfach stoisch sein Ding. Kein Gezicke, kein „bitte rebooten“, einfach Last. Genau das beruhigt mich komischerweise mehr als jeder Streaming-Abend 😎
Schneller Überblick
Zusammenfassung
Im Beobachtungszeitraum lief der Server donau2space stabil mit 99,8 % CPU-Auslastung, einem Durchschnitt von 65,7 °C und ohne Swap-Nutzung. Dominant war Einstein@Home mit intensiver RAM-Nutzung, daneben arbeiteten PrimeGrid, spacious@home und Asteroids@home mit verschiedenen Ressourcenprofilen. Es traten keine Fehler oder Ausfälle auf. Die Systemparameter blieben konstant im unkritischen Bereich.
Auf den Punkt
- Uptime bei 2.391,28 Stunden ohne Ausfälle.
- RAM-Nutzung durchschnittlich 22,7 GB, Peak bei 32 GB – kein Swapping.
- Einstein@Home verursachte die höchste RAM-Belastung mit bis zu 4,8 GB pro Task.
- PrimeGrid zeigte reine CPU-Last, meist geringerer RAM-Bedarf.
- spacious@home sorgte für häufige, kurze Task-Rotation.
- Keine Temperaturdrosselung oder kritische Watt-Spitzen – Höchstwert 74 °C, 44 W.
- Asteroids@home: Viele Tasks als UNINITIALIZED, aber keine Fehler.
Serverstatus & Telemetrie
Der Zeitraum geht von Mittwoch, 6. Mai 2026, 7:00 Uhr bis Mittwoch, 13. Mai 2026, 6:00 Uhr. Die Uptime steht beim letzten Wert bei 2.391,28 h. Das ist so eine Zahl, die nicht „laut“ ist – aber die sagt halt: nichts ist heimlich instabil geworden.
Diese Woche war vom Profil her: konstant auf Anschlag, aber effizient.
Im Schnitt lag die CPU bei 35,5 W und 65,7 °C bei 99,8 % Usage. Das fühlt sich für den i7‑7700 richtig gesund an: Vollauslastung, aber eben nicht mit unnötig viel Wärme erkauft. Und bei Dauerlast ist für mich genau das spannend: gleiche 100 % CPU können sich je nach Workunit-Mix komplett anders „anfühlen“ (Watt/Temp), obwohl htop immer gleich aussieht.
Der Load1 Ø 8,32 bei 8 Threads ist wieder so ein „ja, passt“-Wert. Das ist nicht diese Situation, wo sich die Runqueue aufstaut und du eigentlich nur Scheduler-Overhead produzierst – sondern eher: alle Kerne haben echte Arbeit.
RAM lag im Schnitt bei 22,7 GB (36,3 %), Peak bei 32,06 GB (51,22 %) – und das Wichtigste: Swap 0 MB. Für mich ist das die klare Trennlinie: viel RAM-Nutzung ist okay, sobald der Host anfängt zu swappen, wird’s plötzlich „zäh“ und ineffizient. Hier: absolut kein Druck.
Storage ist weiterhin komplett entspannt: 201,1 GB total, 175,0 GB frei. BOINC braucht davon 1.890,19 MB – also nicht mal ansatzweise ein Thema.
BOINC selbst war einfach… sauber:
- 4.469 Jobs succeeded, 0 failed
- 0 RPC failures, 0 fetch failures
Diese Null bei failed macht mich ehrlich mehr zufrieden als jeder Credit-Sprung. Weil das heißt: 24/7-Last ja, aber keine schleichenden Fehler, keine instabilen WUs, kein Client, der sich langsam zerlegt.
Projekte im Detail
Diese Woche war vom „Charakter“ her schön gemischt: ein klarer Schwergewicht-Dauerläufer, dazu schnelle Rotation und ein bisschen CPU-pure Crunch.
Einstein@Home – der RAM-schwere Langläufer
Einstein@Home dominiert das Bild ziemlich deutlich: 2.722.176 Credit und ein expavg von 33.625,81. Das ist der Teil vom Setup, der den Host prägt – auch weil die Workunits einfach lang am Stück laufen.
Bei den aktiven Tasks sieht man das extrem direkt: Einstein-WUs mit 2.577 MB bis 4.785 MB Working Set pro Task. Das ist nicht gefährlich (64 GB sind da Luxus), aber es erklärt sofort, warum der RAM-Peak überhaupt in die 32-GB-Region kommt.
Technisch ist Einstein für mich so ein klassischer Mix aus CPU-bound, aber mit ordentlich Memory-Footprint. Bedeutet: die CPU ist zwar „voll“, aber der Speicherpfad (Cache/Memory-Controller) wird spürbar mitbenutzt. Das kann Watt/Temperatur leicht verschieben, ohne dass sich die CPU-% ändern.
Und die Laufzeiten bestätigen den Charakter: zuletzt erledigte Einstein-Tasks lagen bei Ø 35h 36m. Wenig Rotation, wenig Scheduler-Hektik – eher so „setz dich hin, ich rechne jetzt“.
PrimeGrid – CPU-pure, mal kurz, mal zäh
PrimeGrid steht bei 537.609,454955 Credit und expavg 6.605,75. Was ich daran mag: PrimeGrid ist oft ziemlich CPU-lastig und weniger „RAM-Show“. Man sieht das auch an den aktiven WUs:
sr5sievemit 184 MB Working SetllrSR5mit 269 MB Working Set
Im Vergleich zu Einstein ist das RAM-seitig fast nichts. Dafür fühlt sich PrimeGrid oft nach „dichtem Rechnen“ an – also mehr echte Rechenarbeit pro Zeit, weniger Speicherbewegung.
Bei den zuletzt erledigten Tasks waren PrimeGrid-WUs mit Ø 36m 57s dabei. Das ist interessant, weil PrimeGrid je nach Subprojekt eben auch deutlich länger kann – diese Woche war’s bei den letzten Reports eher die kurze Rotation.
spacious@home – schnelle Rotation, meist unauffällig
spacious@home ist bei 123.696,263753 Credit, expavg 1.272,15. In den zuletzt erledigten Tasks sieht man genau, was es ist: 10 Tasks mit Ø 47m 46s.
Das Projekt ist für mich so ein perfekter „Kerne bei Laune halten“-Füller: viel Bewegung im Scheduler, häufige Reports, aber ressourcentechnisch meistens superzahm. Wobei es auch hier Ausreißer gibt: ein aktiver Task läuft mit 222 MB Working Set – das ist immer noch nicht dramatisch, aber genug, dass man es im Mix zumindest wahrnimmt.
Asteroids@home – schlank, moderat in der Laufzeit, aber gerade viel „Status-Gewusel“
Asteroids@home steht bei 84.128,593398 Credit und expavg 835,75. Bei den zuletzt erledigten Tasks war’s 1 Task mit 1h 8m – also so in der Mitte: länger als spacious, weit weg von Einstein.
Aktiv fällt bei Asteroids gerade die Menge an Tasks auf, die als UNINITIALIZED bzw. teils READYTOREPORT auftauchen. Solange aber 0 failed stehen und auch RPC/fetch bei 0 bleiben, wirkt das auf mich eher wie ein Client-/State-Thema und nicht wie echte Rechenprobleme. Wenn da was kaputt wäre, würde es sich ziemlich schnell als Fehlerquote zeigen.
climateprediction.net – weiterhin nicht im Mix
Bleibt bei 0 Credit, 0 Jobs, 0 Runtime. Diese Woche also kein Einfluss aufs System.
Auffälligkeiten
Erstmal: keine Temperatur-Drosselung, keine Events. Das ist mir wichtig, weil’s heißt: nichts läuft heimlich ins Limit und wird dann „gerettet“.
Trotzdem gab’s diese kleinen Momente, wo man kurz hängen bleibt:
Der höchste Temperaturpunkt lag bei 74 °C am Freitag, 9. Mai 2026, 7:00 Uhr. Bei einem Wochen-Ø von 65,7 °C ist das ein klarer Ausschlag – aber thermisch total entspannt. 74 °C ist nicht mal ansatzweise „kritisch“, eher so ein Fingerzeig: da war der Workunit-Mix gerade etwas „dichter“ (mehr Rechenintensität oder mehr Speichertraffic).
Der Watt-Peak war 44 W am Donnerstag, 8. Mai 2026, 22:00 Uhr. Gegenüber 35,5 W im Schnitt ist das merkbar. Genau solche Spikes deute ich meistens als „anderes Profil in den Tasks“: gleiche CPU-Auslastung, aber anderer Instruktionsmix → andere elektrische Realität.
Und der RAM-Peak bei 32,06 GB (51,22 %) passt super zu dem, was Einstein gerade treibt (mehrere GB Working Set pro Task). Das ist nicht knapp – aber ich mag’s, weil es zeigt, dass das System nicht nur „CPU 100 %“ macht, sondern wirklich unterschiedliche Lastarten abkann, ohne ins Swapping zu kippen.
Fazit
Eine Woche, die ich als langweilig stabil (und genau deshalb gut) einordne: 99,8 % CPU, Load 8,32, dabei im Schnitt nur 35,5 W und 65,7 °C. Für 24/7-Crunching ist das für mich ziemlich ideal – Leistung, aber ohne Stresssignale.
Einstein@Home bleibt der Charakterkopf: lange Workunits und GB-Working-Sets, die den RAM-Peak erklären. PrimeGrid bringt die eher CPU-pure Komponente rein, spacious liefert die schnelle Rotation, und Asteroids läuft schlank mit – auch wenn da gerade viel im UNINITIALIZED/READYTOREPORT-Zustand rumliegt.
Und ja: mein Wochenhighlight bleibt simpel. 0 failed. Draußen alles auf „Leise“, drinnen rechnet donau2space stoisch weiter. So darf Crunching gern aussehen. 🙂
Diagramme
Begriffe kurz erklärt
- SSH: SSH ist ein sicheres Netzwerkprotokoll, mit dem man per Kommandozeile auf entfernte Computer zugreifen kann.
- Telemetrie: Telemetrie bedeutet, Mess- oder Zustandsdaten automatisch von einem Gerät zu einem anderen zu übertragen, zum Beispiel vom Sensor zum Server.
- BOINC: BOINC ist eine Plattform, mit der viele Nutzer gemeinsam Rechenleistung für wissenschaftliche Projekte bereitstellen können.
- RPC failures: RPC failures sind Fehlermeldungen, wenn ein Programm übers Netzwerk keinen erfolgreichen Aufruf bei einem anderen Dienst machen kann.
- Workunit-Mix: Der Workunit-Mix beschreibt die Zusammensetzung verschiedener Rechenaufgaben, die ein verteiltes System gerade bearbeitet.
- Scheduler-Overhead: Scheduler-Overhead ist die Rechenzeit, die das Betriebssystem selbst fürs Planen der Prozesse verbraucht.
- Runqueue: Eine Runqueue ist eine Warteschlange, in der Prozesse liegen, die von der CPU abgearbeitet werden sollen.
- Working Set: Das Working Set ist die Menge an Speicher, die ein Programm gerade aktiv nutzt.
- CPU-bound: CPU-bound bedeutet, dass ein Programm hauptsächlich durch die Rechenleistung der CPU begrenzt ist, nicht durch Speicher oder Festplatte.
- Memory-Controller: Der Memory-Controller verwaltet den Datenfluss zwischen Prozessor und Arbeitsspeicher.
- sr5sieve: sr5sieve ist ein Programm, das im BOINC-Kontext verwendete Zahlenmengen durchsucht, um Primzahlanwärter herauszufiltern.
- llrSR5: llrSR5 testet gefundene Zahlen aus sr5sieve genauer, um echte Primzahlen zu bestätigen.
- UNINITIALIZED: UNINITIALIZED bedeutet, dass eine Variable oder ein Prozess noch nicht richtig gestartet oder zugewiesen wurde.
- READY TO REPORT: READY TO REPORT zeigt an, dass eine erledigte Aufgabe bereit ist, ihre Ergebnisse zurückzumelden, etwa an einen Server.
