Devora Cloud · Blog
Website langsam? So erkennen Sie, ob CPU, Speicher oder der Code das Problem ist
Lernen Sie, CPU- und Speichergrafiken, Neustarts und Logs (out of memory, Killed) zu lesen – und entscheiden Sie zwischen mehr Replikaten, größerem Tarif oder Codekorrektur.
Eine langsame Website gehört zu den häufigsten Beschwerden – und wird teuer, wenn man rät. Viele buchen einen größeren Server und stellen eine Woche später fest, dass eine Abfrage ohne Index schuld war. Andere optimieren tagelang Code, obwohl der Anwendung schlicht Arbeitsspeicher fehlte.
Die gute Nachricht: Die Signale sind meist eindeutig, wenn man weiß, wo man hinschauen muss. Diese Anleitung zeigt, wie Sie CPU, Speicher, Neustarts und Logs lesen, um zu einer Diagnose zu kommen – und wann die Antwort Skalieren, ein größerer Tarif oder eine Codeänderung ist.
Zuerst: Was die Grafiken messen
Im Dashboard von Devora Cloud zeigen die CPU- und Speichergrafiken den Anteil am Kontingent Ihrer Anwendung, nicht am ganzen Server. Im Hobby-Tarif mit 0,5 vCPU und 512 MB bedeuten 100 % CPU, dass diese 0,5 vCPU ausgelastet sind; im Pro-Tarif, dass es die 2 vCPU sind.
Betrachten Sie immer einen längeren Zeitraum, etwa die letzten 24 Stunden. Eine Spitze von wenigen Sekunden während eines Deployments ist normal. Entscheidend ist das Muster: lange hohe Auslastung, stetiges Wachstum oder plötzliche Einbrüche mit anschließendem Neustart.
Das Dashboard warnt außerdem, wenn CPU oder Speicher mindestens drei Minuten über 85 % liegen – ein guter Ausgangspunkt für die Suche.
Signal 1: zu wenig CPU
Symptome: Die CPU liegt lange über 80 %, und die Seiten werden genau zu den Stoßzeiten langsam. Der Speicher kann dabei unauffällig sein.
Was zu tun ist:
- Im Hobby-Tarif (0,5 vCPU): Pro (2 vCPU) oder Enterprise (4 vCPU) in Betracht ziehen.
- In Pro oder Enterprise: Autoscaling aktivieren oder ein Skalierungsreplikat hinzufügen, um den Traffic zu verteilen.
- Bevor Sie mehr bezahlen, prüfen Sie, ob bei jeder Anfrage schwere Arbeit erledigt wird – Berichte erzeugen, Bilder skalieren, große Dateien verarbeiten.
Signal 2: zu wenig Arbeitsspeicher
Symptome: Der Speicher liegt über 90 %, der Neustartzähler steigt und die Logs zeigen Meldungen wie diese:
- Killed – das System hat den Prozess beendet, weil er das Speicherlimit überschritten hat.
- out of memory oder JavaScript heap out of memory – der Prozess (oft Node.js) hat sein Limit erreicht.
- Die Website fällt mehrmals täglich für einige Sekunden aus und kommt von selbst zurück.
Replikate beheben keinen Speichermangel: Jede Kopie hat dasselbe Limit wie der Tarif. Der Ausweg ist meist der nächste Tarif (Hobby 512 MB → Pro 1 GB → Enterprise 8 GB). Steigt der Speicher ununterbrochen, bis der Prozess stirbt, suchen Sie auch nach Lecks: unbegrenzte In-Memory-Caches, Listen, die nur wachsen, komplett geladene Dateien.
Signal 3: Code oder Datenbank sind das Problem
Symptome: CPU und Speicher niedrig, keine Neustarts – und trotzdem laden die Seiten langsam. Hier hilft mehr Server nicht, denn die Anwendung wartet auf etwas.
- Langsame Abfragen: fehlende Indizes, Abfragen in Schleifen (das klassische N+1), ganze Tabellen geladen, um zehn Zeilen anzuzeigen.
- Langsame externe APIs: Zahlung, Versand oder E-Mail während der Anfrage aufgerufen, ohne Timeout.
- Große Dateien, die die Anwendung selbst ausliefert, statt signierte S3-URLs zu nutzen.
- Timeouts und 5xx-Fehler in den Logs, die genau zeigen, welche Route leidet.
Die Lösung liegt im Code: Index anlegen, Abfragen bündeln, schwere Aufgaben in den Hintergrund verlagern, einen Redis-Cache ergänzen.
Schnelldiagnose-Tabelle
| Was Sie sehen | Wahrscheinliche Ursache | Was zu tun ist |
|---|---|---|
| CPU stundenlang hoch, Speicher normal | Zu wenig CPU | Autoscaling oder Replikat (Pro/Enterprise) oder Tarif mit mehr vCPU |
| Speicher über 90 %, Neustarts, „Killed“ | Zu wenig Speicher | Nächster Tarif; nach Lecks suchen |
| CPU und Speicher niedrig, Seiten langsam | Code oder Datenbank | Indizes, weniger Abfragen, Cache, Timeouts für APIs |
| Uploads scheitern mit QuotaExceeded | S3 voll | Dateien löschen, Zusatzpaket oder größerer Tarif |
| Nur für weit entfernte Besucher langsam | Entfernung zum Server | Apps laufen in den USA; in Brasilien beschleunigt der CDN-Cache von Devora die Auslieferung |
Lassen Sie Ihre KI die Analyse übernehmen
Wenn Sie das KI-Token von Devora Cloud nutzen, müssen Sie das nicht allein lesen. Fragen Sie die KI, die Ihre Anwendung veröffentlicht hat: „Warum ist meine Website langsam?“ Sie prüft die CPU- und Speichermetriken der letzten 24 Stunden, die Neustarts jedes Replikats, die Anwendungslogs und die S3-Nutzung.
Die Antwort kommt mit Zahlen statt Vermutungen – etwa „Der Speicher lag über 90 %, und es gab Neustarts mit Killed in den Logs“ – und mit einer klaren Empfehlung. Die KI ändert weder Ihren Tarif noch kauft sie Ressourcen für Sie: Diese Entscheidung bleibt im Dashboard.
Häufige Fragen
Helfen zusätzliche Replikate gegen Speichermangel?
Nein. Jedes Replikat hat dasselbe Speicherlimit wie der Tarif; geht dem Prozess der Speicher aus, passiert das auf allen Kopien. Die Lösung ist ein Tarif mit mehr RAM oder ein sparsamerer Code.
Was bedeutet „Killed“ in den Logs?
Dass der Prozess beendet wurde, weil er mehr Speicher als erlaubt nutzte. Die Meldung erscheint meist zusammen mit Neustarts und einem Speicherwert nahe 100 % in der Grafik.
Heißt 100 % CPU im Dashboard, dass der Server überlastet ist?
Nicht unbedingt. Der Wert bezieht sich auf das Kontingent Ihrer Anwendung: 100 % bedeutet, dass sie die gesamte CPU Ihres Tarifs nutzt – nicht, dass die ganze Maschine voll ist.
Kann die KI meinen Tarif ändern?
Nein. Sie analysiert Metriken und Logs und gibt eine Empfehlung. Tarife, bezahlte Replikate und Speicherpakete buchen Sie selbst im Dashboard.