Ich bin heute früh auf donau2space drauf und hab zuerst kurz aus dem Fenster geschaut: Passau ist gerade klar bei 23,4 °C, fast kein Wind. Dann Terminal auf, einmal die Kurven aufgerufen – und ich merk’s sofort: das ist so eine Woche, wo die Kiste einfach durchzieht. Keine Show, keine Überraschung. Nur Arbeit, sauber.
Schneller Überblick
Zusammenfassung
Der Bericht dokumentiert den Betrieb des donau2space-Servers über eine Woche. Das System lief mit hoher CPU-Auslastung (99,8 %) bei moderaten Temperaturen und Stromverbrauch stabil. Ein RAM-Peak war vor allem durch Einstein@Home-Tasks mit hohem Speicherbedarf zu sehen. Swap wurde kaum genutzt, es traten keine kritischen Fehler auf. Die Netzwerkanbindung funktionierte einwandfrei.
Auf den Punkt
- Durchschnittliche CPU-Nutzung 99,8 %, durchschnittlich 36,1 W und 67,5 °C.
- RAM-Nutzung mit Spitzen bis 52,71 GB (84,21 %) durch Einstein@Home-Workunits.
- 5 BOINC-Projekte aktiv, climateprediction.net inaktiv.
- Zwei fehlgeschlagene Jobs bei über 6.300 erfolgreichen, keine Netzwerkschwierigkeiten.
- Keine Temperatur- oder Lastspitzen, die kritisch wurden.
- Einstein@Home verursachte lange Laufzeiten und hohen RAM-Bedarf.
- Uptime betrug 3.399 Stunden, System lief unter Debian 13 stabil.
FAQ
- Welche Ursache hatte der hohe RAM-Bedarf?
- Vor allem Einstein@Home-Workunits mit Arbeitsmengen von teils über 8 GB führten zu stärkerer RAM-Auslastung.
- Gab es kritische Ausfälle oder Probleme mit dem Host?
- Nein, das System war durchgehend stabil. Zwei Workunits scheiterten, es gab jedoch keine gravierenden Zwischenfälle.
Serverstatus & Telemetrie
Der Zeitraum hier ist von Mittwoch, 17. Juni 2026, 7:00 Uhr bis Mittwoch, 24. Juni 2026, 6:00 Uhr. Die Uptime steht beim letzten Wert bei 3.399,28 Std. – das ist wieder so ein stilles „läuft“ im Kopf. Debian 13 (trixie) mit Kernel 6.12.63 fühlt sich auf dem Host einfach stabil an, wie ein gut eingespieltes Setup.
Im Schnitt lag die CPU bei 36,1 W und 67,5 °C, bei 99,8 % Usage. Das ist ein super typisches 24/7-Profil für den i7-7700: dauerhaft voll, aber nicht gequält. 67,5 °C im Mittel ist für mich „Cruncher-warm“ – weit weg von allem, was nach Thermik-Drama riecht.
Der Load1 bei 8,38 auf 8 Threads fühlt sich in htop genau richtig an: minimal über „voll“. Heißt für mich: die Runqueue ist nie leer, aber wir bauen auch keinen absurden Stau auf. Der Scheduler hat konstant was zu tun, ohne dass das System „zäh“ wird.
RAM war diese Woche dagegen deutlich präsenter als letzte Woche: im Schnitt 35,0 GB (55,9 %), Peak bei 52,71 GB (84,21 %). 84 % ist nicht gefährlich – wir haben ja 64 GB – aber es ist eine Region, wo ich innerlich automatisch aufmerksamer werde. Nicht panisch, eher so: Okay, wer frisst gerade Speicher? Das Beruhigende dabei: Swap 2 MB. Das ist praktisch „nicht benutzt“, also kein echtes Paging-Problem. Sobald Swap wirklich anfängt zu laufen, fühlt sich ein Cruncher nämlich nicht mehr „satt“, sondern „unter Druck“ an – und das war hier nicht der Fall.
Storage bleibt langweilig gesund: 201,1 GB total, 168,1 GB frei. BOINC belegt 8.952,93 MB – und ja, das schreit wieder nach Einstein-Datenpaketen. Das ist keine schleichende Explosion, eher ein erwartbarer Fußabdruck.
BOINC insgesamt: 6.331 Jobs succeeded, 2 failed. Zwei Fehlschläge auf den Durchsatz sind nicht „Katastrophe“, aber ich registrier’s. Mich freut ehrlich gesagt fast mehr, wenn da eine glatte Null steht, weil es ein Signal für „keine wackeligen WUs, kein Rand-Instabilitätskram“ ist. Positiv: 0 RPC failures und 0 fetch failures – also die Anbindung und der Scheduler-Dialog waren die Woche komplett unauffällig.
Projekte im Detail
Hier laufen 5 Projekte, wobei climateprediction.net faktisch weiterhin nicht aktiv ist (0 Credit, 0 Jobs). Der Charakter der Woche kommt aus einem Mix aus Einstein@Home als „schwerer Dauerblock“ und den rotierenden Projekten spacious@home und Asteroids@home. PrimeGrid bleibt so ein CPU-lastiger Einschub, der vom Instruktionsmix her gerne mal „anders“ ist.
Einstein@Home – lang, schwer, und RAM ist Teil der Rechnung
Einstein ist weiterhin der dominante Brocken: 4.095.720 Credit bei einem expavg von 29.572,43. Man merkt’s nicht nur an Credits, sondern am Verhalten: lange Workunits, wenig Wechsel, viel „einfach laufen lassen“.
Und dann die aktive Task-Liste: da stehen Working-Sets wie 2.620 MB, aber auch brutalere Dinger mit 8.316 MB, 8.281 MB oder 8.340 MB pro Task. Wenn mehrere davon parallel laufen, ist das nicht mehr nur „CPU auf 100 %“, sondern auch Speicherhierarchie in Bewegung: mehr Daten im RAM, mehr Druck auf Cache/Memory-Controller, mehr Aktivität außerhalb der reinen ALUs. Genau das passt für mich ziemlich gut zum hohen RAM-Peak der Woche.
Auch von den Laufzeiten her ist Einstein der Langstreckenläufer: zuletzt erledigte Einstein-Tasks lagen im Schnitt bei 34h 2m. Das ist scheduler-technisch super ruhig – wenig Start/Stop, wenig Rotation, dafür konstante Last.
spacious@home – kurze Rotation, viel Taktgefühl
spacious@home steht bei 173.296,263753 Credit und expavg 1.193,81. In den zuletzt erledigten Tasks waren es 11 Tasks mit Ø 40m 13s. Das ist genau diese Art Workload, die sich anfühlt wie ein Metronom: ständig wird reported, ständig kommt was Neues nach.
RAM-seitig ist spacious in der aktiven Liste sehr gemischt: ich sehe Tasks mit 4 MB Working Set, aber auch einen mit 229 MB. 229 MB ist auf dem Host natürlich nichts, aber diese Varianz ist spannend, weil sie manchmal kleine Energie-/Temperatur-Unterschiede erklärt – nicht, weil es „viel“ ist, sondern weil es auf unterschiedliche Datensätze und Zugriffsprofile hinweist.
Asteroids@home – eher leicht, viel Bewegung
Asteroids@home liegt bei 123.399,906029 Credit und expavg 959,31. Zuletzt gab’s 6 Tasks mit Ø 1h 6m. Das ist länger als spacious, aber immer noch klar in der „Rotation läuft“ Kategorie.
In den aktiven Tasks sind die Working-Sets klein, z. B. 13 MB – das wirkt sehr CPU-bound und cache-freundlich. Was auffällt: da stehen einige UNINITIALIZED/READYTOREPORT Einträge. Solange das System insgesamt stabil bleibt und die Fehlerzahlen nicht hochgehen, ist das für mich eher ein Zustands-/Reporting-Zwischenraum als ein echtes Problem. Aber ja: das ist so ein Ding, das ich im Auge behalte, weil’s sich sonst gerne mal zu „warum hängt das Reporting?“ entwickeln kann.
PrimeGrid – CPU-Hammer im Langformat
PrimeGrid steht bei 770.701,758913 Credit und expavg 6.259,94. Diese Woche taucht PrimeGrid bei den zuletzt erledigten Tasks mit einem echten Brocken auf: 26h 3m für einen Task. Aktiv läuft gerade ein ap27 bei 87,5 % mit 23h 52m CPU-Time, Working Set 3 MB. Das ist so ein klassischer Fall: extrem CPU-bound, RAM fast egal – der Kern knallt durch, aber der Speicher bleibt entspannt.
Auffälligkeiten
Es gab keine Temperatur-Drosselung und keine Events. Die Peaks sind eher „Momente“, die man einordnet, nicht Alarme.
Der maximale Temperaturwert lag bei 77 °C am Montag, 23. Juni 2026, 11:00 Uhr. Wenn der Wochenschnitt bei 67,5 °C liegt, dann sind 77 °C für mich ein kurzer Ausschlag nach oben – nicht die Richtung der Woche. Ich seh sowas und denk automatisch: War das gerade ein Mix aus mehreren Einstein-WUs mit fettem Working Set plus Nebenrotation? Das würde zu dem RAM-Profil passen. Und ja: 77 °C ist absolut okay – aber es ist genau der Bereich, wo ich aufmerksam werde, weil’s zeigt: da passiert gerade „mehr“ als nur stumpf CPU.
Der maximale Verbrauch war 46 W am Freitag, 20. Juni 2026, 18:00 Uhr. Auch das ist nicht dramatisch, eher ein Fingerzeig auf einen ungünstigeren Instruktionsmix oder mehr Speicheraktivität. Interessant finde ich dabei: Watt-Peak und Temp-Peak liegen nicht auf demselben Zeitpunkt. Das spricht für unterschiedliche Ursachen – einmal eher „elektrisch/rechnerisch schwer“, einmal eher „thermisch/Umgebung + Workunit-Mix“.
Das RAM-Maximum von 52,71 GB (84,21 %) ist der eigentliche Marker der Woche. Nicht weil es knapp wäre – es ist noch Luft da – sondern weil es zeigt, dass Einstein@Home hier nicht nur CPU dominiert, sondern das System als Ganzes spürbar fordert. Dass Swap praktisch bei 0 bleibt, ist dabei das Wichtigste: das fühlt sich nach „souverän“ an, nicht nach „wir kämpfen“.
Fazit
Diese Woche war konstant und sauber, fast schon „langweilig gut“: 99,8 % CPU, dabei 36,1 W und 67,5 °C im Mittel. Der Cruncher hat nicht an Grenzen gekratzt, sondern einfach stabil gerechnet.
Spannend war eher die Systemseite: der hohe RAM-Peak passt perfekt zum Einstein-Profil mit teils 8+ GB Working Set pro Task. Das ist genau der Punkt, wo man merkt: Workunits sind nicht nur Laufzeit, sie sind Charakter – und der Charakter beeinflusst Watt, Wärme und das ganze Gefühl von „wie schwer“ eine Woche war.
Die 2 failed Jobs sind das einzige, was mich kurz stutzen lässt – nicht, weil es viel ist, sondern weil ich eigentlich gern die „0“ sehe. Dafür: Netzwerk/BOINC-Kommunikation komplett sauber, und der Host wirkt insgesamt so stabil, dass ich eher neugierig bin als genervt.
Und ja: ein Teil von mir findet’s fast schade, dass es keine richtig wilden Kurven gab – aber dann sehe ich die Uptime und denke mir: Stabilität schlägt Rekorde.
Diagramme
Begriffe kurz erklärt
- BOINC: BOINC ist eine Plattform, die Rechenleistung vieler Computer sammelt, um wissenschaftliche Projekte gemeinsam schneller zu berechnen.
- Einstein@Home: Einstein@Home nutzt die Rechenleistung freiwilliger Computer, um Daten nach Hinweisen auf Gravitationswellen oder Neutronensterne zu durchsuchen.
- Asteroids@home: Asteroids@home berechnet mit Hilfe vieler privater Computer die Form und Bahn von Asteroiden anhand astronomischer Beobachtungsdaten.
- PrimeGrid: PrimeGrid ist ein Projekt, das gemeinsam mit vielen Teilnehmern nach besonders großen Primzahlen sucht.
- Kernel 6.12.63: Kernel 6.12.63 bezeichnet eine bestimmte Version des Linux-Kernels, der die grundlegende Steuerung von Hardware und Prozessen übernimmt.
- Scheduler: Der Scheduler im Betriebssystem entscheidet, welcher Prozess als Nächstes Rechenzeit auf der CPU bekommt.
- Runqueue: Die Runqueue ist die Liste aller Prozesse, die gerade darauf warten, von der CPU ausgeführt zu werden.
- Swap: Swap ist ein Speicherbereich auf der Festplatte, in den das System selten genutzte Daten aus dem Arbeitsspeicher auslagert.
- Working Set: Das Working Set beschreibt die Menge an Speicher, die ein Programm gerade aktiv benutzt.
- Memory-Controller: Der Memory-Controller steuert, wie die CPU auf den Arbeitsspeicher zugreift und Daten liest oder schreibt.
- ALU: Die ALU (Arithmetic Logic Unit) führt in der CPU einfache Rechen- und Vergleichsoperationen wie Plus oder Logikfunktionen aus.
