PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : CPU Load begrenzung mit "nice" und "cpulimit" auf VPS geht nicht



hedie
23.11.15, 15:45
Hallo zusammen

Ich habe einen VPS dienst mit 512MB Ram und 15GB Space. System: debian 8.1 minimal
Auf diesem möchte ich wöchentlich ein Backup mit gzip durchführen.

Um die CPU Last so gering wie möglich zu halten, habe ich mein Skript mit

nano -n 19 /path/to/script.sh
aufgerufen.

Leider liegt die CPU Last dennoch um die ca. 90% während gzip die Files komprimiert.
Ich habe cpulimit heruntergeladen und mit

cpulimit --limit 2 /path/to/script.sh
versucht zu limitieren.

Ergebnis war wiederum keine limitierung.
Ich habe folgendes versucht:


echo 0 > /proc/sys/kernel/sched_autogroup_enabled
Da meldet mir das System "no such file or directory"

Nun weiss ich leider nicht mehr wirklich weiter.

Hat jemand eine idee oder kann mir zumindest schreiben, dass er keine Idee hat?
(dann weiss ich nämlich, dass sich zumindest jemand gedanken darüber gemacht hat :)

Danke und Gruss
Claudio

DrunkenFreak
23.11.15, 15:51
Du vergibst eine Priorität und keine Limitierung mit nice. Das ist ein großer Unterschied.

hedie
23.11.15, 16:02
Du vergibst eine Priorität und keine Limitierung mit nice. Das ist ein großer Unterschied.

Danke für deine Antwort
Das habe ich mir bereits gedacht. Deshalb habe ich auch cpulimit getestet.

Habe gerade noch folgendes versucht:

root@blssrv2:/# /usr/bin/nice -n 19 /usr/bin/ionice -c2 -n7 /sbin/backup.sh
Leider auch ohne erfolg. Ca 90% CPU Load

DrunkenFreak
23.11.15, 16:04
ionice wird vermutlich das gleiche machen. Wenn Resourcen da sind, werden sie genutzt. Wenn sie knapp werden kommen die anderen Programme zuerst dran.

fork
23.11.15, 16:27
Du könntest pv(=Pipe Viewer) verwenden. Dadurch kannst Du einen Datenstrom leiten und dessen Bandbreite begrenzen:

also z. B.:



tar -cf - /sicherungs-verzeichnis1 /sicherungs-verzeichnis2 ... | pv -L 50k | gzip -9 >backup.tar.gz


D. h. schreibt mit max. 50 KB/Sek. ebenso wie gzip dann max. 50KB/Sek an Daten komprimieren kann.

ThorstenHirsch
23.11.15, 22:52
Eigentlich sollte cpulimit funktionieren. Bei mir tut es das jedenfalls auf einem virtualisierten root-Server der billigsten Art (kvm? keine Ahnung). Nicht so einfach von der Bedienung sind cgroups, die könntest Du noch ausprobieren.

TheDarkRose
24.11.15, 00:16
Wo ist das Problem bei 90% Systemlast? Wenn sonst nichts rennt?

Lieber während des Backups mal mit abache benchmark reinfahren und schauen, ob der Webserver entsprechend viel CPU Zeit und Prio bekommt und dein Backup zurückgefahren wird.

hedie
24.11.15, 07:41
Vielen Dank für eure Antworten.

@ThorstenHirsch: ich verstehe ehrlich gesagt auch nicht, warum es nicht funktioniert. cgroups werde ich mal googlen.

@TheDarkRose: Das Problem ist, dass mein VPS gesperrt wurde, da er zuviel CPU beanspruchte.


Mein Aufruf sieht so aus:


tar -zcvpf /backups/fullbackup-$(date +%Y-%m-%d).tar.gz --directory=/ \
--exclude=proc --exclude=sys --exclude=dev --exclude=run --exclude=tmp \
--exclude=lost+found --exclude=var/cache/apt --exclude=var/run \
--exclude=backups --exclude=restore .


Wäre diese anpassung so korrekt?:



tar -zcvpf --directory=/ \
--exclude=proc --exclude=sys --exclude=dev --exclude=run --exclude=tmp \
--exclude=lost+found --exclude=var/cache/apt --exclude=var/run \
--exclude=backups --exclude=restore . | pv -L 50k | > /backups/fullbackup-$(date +%Y-%m-%d).tar.gz

DrunkenFreak
24.11.15, 08:37
Wenn der VPS gesperrt wurde, ist der Anbieter murks. Soll er doch zusehen, wie deine CPU limitiert wird und nicht andere Leute ausbremst. Ich würde direkt kündigen.

hedie
24.11.15, 09:28
Wenn der VPS gesperrt wurde, ist der Anbieter murks. Soll er doch zusehen, wie deine CPU limitiert wird und nicht andere Leute ausbremst. Ich würde direkt kündigen.

Vielen Dank für deinen Kommentar.
Da war ich mir nämlich nicht ganz sicher wie das üblicherweise gehandhabt wird.

Hier der Kommentar des Anbieters:


It was not 70% CPU.
It was a load of 70.xx+
Your vps was inhialating the node.

I have unsuspended the vps, but if there is anything like this that occurs again there will be at minimum 24 hours suspension involved.

You yourself are responsible for keeping your vm within an acceptable limit.

Regards,
Ryan B

hedie
24.11.15, 09:35
Mein Aufruf funktioniert so leider nicht:


tar -zcvpf --directory=/ \
--exclude=proc --exclude=sys --exclude=dev --exclude=run --exclude=tmp \
--exclude=lost+found --exclude=var/cache/apt --exclude=var/run \
--exclude=backups --exclude=restore . | pv -L 50k > /backups/fullbackup-$(date +%Y-%m-%d).tar.gz


Fehlermeldung:



root@blssrv2:~# tar -zcvpf --directory=/ --exclude=proc --exclude=sys --exclude=dev --exclude=run --exclude=tmp --exclude=lost+found --exclude=var/cache/apt --exclude=var/run --exclude=backups --exclude=restore . | pv -L 50k > /backups/fullbackup-$(date +%Y-%m-%d).tar.gz
-bash: pv: command not found
tar (child): --directory=/: Cannot open: Is a directory
tar (child): Error is not recoverable: exiting now
root@blssrv2:~#

DrunkenFreak
24.11.15, 09:36
Bei einer load von 70 warten 70 Prozesse darauf, dass sie an die Reihe kommen. Da ist entweder der Server unterdimensioniert oder da läuft irgendwas schief.

Dennoch ist dein Anbieter dafür zuständig, deine Prozesse zu limitieren. Wenn er das nicht hinkriegen kann oder will, ist es ein verdammt schlechter. Aber hier wird vermutlich auch you get what you pay greifen.

hedie
24.11.15, 09:50
Aber hier wird vermutlich auch you get what you pay greifen.

Korrekt!

7 USD pro JAHR! inkl. eigener IP-Adresse
Ohne Setup Gebühren oder ähnlichem!

Wenn mir jetzt noch jemand helfen könnte, meine CPU Load zu begrenzen, wäre ich wirklich happy :)
Was muss ich bei meinem Pipe Aufruf ändern, damit es klappt?



tar -zcvpf --directory=/ \
--exclude=proc --exclude=sys --exclude=dev --exclude=run --exclude=tmp \
--exclude=lost+found --exclude=var/cache/apt --exclude=var/run \
--exclude=backups --exclude=restore . | pv -L 50k > /backups/fullbackup-$(date +%Y-%m-%d).tar.gz

DrunkenFreak
24.11.15, 10:07
Die Load kannst du nur begrenzen, indem du Prozesse killst. Was du versuchst, ist den Datendurchsatz zu limitieren.

hedie
24.11.15, 10:13
Das ist korrekt.

Ich möchte, dass mein tar prozess nicht die gesamte cpu beansprucht.

Der unterschied ist mir inzwischen bekannt

marce
24.11.15, 10:21
-bash: pv: command not found ist schon mal der erste Fehler, den Du beseitigen solltest.

Dann: Wozu machst Du ein Vollbackup des kompletten Systems? Damit kannst Du im Fall des Falles vermutlich eh nichts anfangen, sichere lieber doch nur die Daten, die wirklich wichtig sind - je nach dem, was das ist (abhängig davon, was auf dem System so läuft) reduziert das das Datenvolumen von ca. 10GB auf ein paar MB.

hedie
24.11.15, 10:48
-bash: pv: command not found ist schon mal der erste Fehler, den Du beseitigen solltest.

Dann: Wozu machst Du ein Vollbackup des kompletten Systems? Damit kannst Du im Fall des Falles vermutlich eh nichts anfangen, sichere lieber doch nur die Daten, die wirklich wichtig sind - je nach dem, was das ist (abhängig davon, was auf dem System so läuft) reduziert das das Datenvolumen von ca. 10GB auf ein paar MB.

Ich benötige das Vollbackup (mit ausnahme der entsprechenden Directories) dazu, um im Falle eines Falles den kompletten VPS zu klonen.
Habe das Szenario bereits durchgespielt und das Backup auf einen anderen VPS mit Debian Minimal 8.1 aufgespielt. Egebnis war, sämtliche Dienste liessen sich sofort starten und es lief alles auf anhieb!

Die aktuellen 2GB belegten Speicher werden auf etwa 200MB komprimiert.

Hier mein aktueller Versuch:



root@blssrv2:~# tar -zcvp --directory=/ --exclude=proc --exclude=sys --exclude=dev --exclude=run --exclude=tmp --exclude=lost+found --exclude=var/cache/apt --exclude=var/run --exclude=backups --exclude=restore . | pv -L 50k > /backups/fullbackup-$(date +%Y-%m-%d).tar.gz


Nun scheint das ganze zu funktionieren.

Die CPU Auslastung liegt bei 0.5 - 1%

Danke!

marce
24.11.15, 12:38
Ich benötige das Vollbackup (mit ausnahme der entsprechenden Directories) dazu, um im Falle eines Falles den kompletten VPS zu klonen.
Warum das System sichern wenn das doch "von sich aus" auf dem neuen Server schon vorhanden ist?

Sinnvoll wäre:
- installierte Pakete
- config-Files der Dienste (bzw. die manuell angepassten davon)
- relavante Daten (z.b. DB-Dump, Web-Verzeichnisse)

mehr braucht's eigentlich nicht.

hedie
24.11.15, 12:47
Warum das System sichern wenn das doch "von sich aus" auf dem neuen Server schon vorhanden ist?

Sinnvoll wäre:
- installierte Pakete
- config-Files der Dienste (bzw. die manuell angepassten davon)
- relavante Daten (z.b. DB-Dump, Web-Verzeichnisse)

mehr braucht's eigentlich nicht.

Da stimme ich dir absolut zu.
Ich habe jedoch lange nach einer von dir beschriebenen Lösung gesucht und leider nicht gefunden.
Falls du mir sagen kannst, wie ich deinen Vorschlag umsetzen kann, würde ich dies gerne versuchen.

DrunkenFreak
24.11.15, 13:00
Falls du mir sagen kannst, wie ich deinen Vorschlag umsetzen kann, würde ich dies gerne versuchen.
Du suchst die Daten zusammen und speicherst sie in deinem Backup. Da ist keine Schwierigkeit dabei.

hedie
24.11.15, 13:13
Du suchst die Daten zusammen und speicherst sie in deinem Backup. Da ist keine Schwierigkeit dabei.

Für jemanden der weiss, wo die entsprechenden Daten zu finden sind, bestimmt nicht.
Aber ich habe diesbezüglich nocht nicht sehr viel Erfahrung. Daher kann ich das nicht aus dem FF.

Da du dies ja anscheinend sehr gut weist, würde ich mich freuen, wenn du dein Wissen mit mir teilen würdest,
damit ich etwas lernen kann und mein Backupscript entsprechend verbessern kann.

marce
24.11.15, 13:51
Fange wir doch einfach mal an:
* Du hast Dienste konfiguriert - welche?
... damit, daß Du sie konfiguriert hast - hast Du doch auch Konfigurationsdatien angepasst. Damit weißt Du schon mal, welche Dateien in Dein Backup rein müssen.

... und für mehr Hinweise müsste man wissen, was denn auf dem Ding so läuft.

DrunkenFreak
24.11.15, 13:51
Das sind die Grundlagen. Siehe hier (http://debiananwenderhandbuch.de/).

hedie
24.11.15, 15:30
Fange wir doch einfach mal an:
* Du hast Dienste konfiguriert - welche?
... damit, daß Du sie konfiguriert hast - hast Du doch auch Konfigurationsdatien angepasst. Damit weißt Du schon mal, welche Dateien in Dein Backup rein müssen.

... und für mehr Hinweise müsste man wissen, was denn auf dem Ding so läuft.

Ja, ich weiss welche Files ich angepasst habe.
Ich weiss auch, welche Pakete ich mit apt-get im nachhinein installiert habe.

Ein Skript zu erstellen, welches mir die besagten Pakete runterlädt und dann konfiguriert würde ich sogar auch noch hinkriegen.
Aber ein backup wäre mir lieber.

Was läuft ist nicht wirklich viel: Apache2, MYSQL, Samba

marce
24.11.15, 15:59
Du musst nicht mal die Liste der nachinstallierten Pakete haben - es reicht eine Liste der installierten Pakete. Den Rest macht der Paketmanager für Dich.

Das reduziert den Umfang des Backups auf ein paar Konfigdateien (30k in Summe?) und ein bisschen MySQL-Dump und ein paar Files vom Web-Aufritt. Zudem kannst Du Dir sicher sein, daß das hinterher auch noch funktioniert. Stell Dir mal vor, der Hoster würde das Installationsimage des Systems anpassen. Oder zu ziehst zu einem anderen Hoster um mit anderen Images - mit den relevanten Inhalten aus dem Angepassten Backup bist Du dann wesentlich schneller am Start als mit einer unnötig aufgeblähten Komplettsicherung.

fork
25.11.15, 00:14
Für jemanden der weiss, wo die entsprechenden Daten zu finden sind, bestimmt nicht. Aber ich habe diesbezüglich nocht nicht sehr viel Erfahrung. Daher kann ich das nicht aus dem FF.

Da du dies ja anscheinend sehr gut weist, würde ich mich freuen, wenn du dein Wissen mit mir teilen würdest, damit ich etwas lernen kann und mein Backupscript entsprechend verbessern kann.

Possenhafter Bube! Bereite Dich darauf vor, das Geheimnis von Open Source zu erfahren!

Hinter Open Source steht der Wunsch,
Wissen mit allen Menschen zu teilen.
Unglaublich viel Arbeit, Mühsal,
Energie und Strapazen haben Generationen
von Menschen auf sich genommen, um
die Gemeinschaft zu bereichern.

Alle Menschen, die es möchten,
können sich das Wissen holen.
Sie müssen nur zugreifen.

Es liegt wie das Geld auf der Strasse.
Möchtest Du jetzt auch noch darum bitten,
dass jemand das Geld für Dich einsammelt?

Gehe hin zur allwissenden Guuugl
und greif' nach dem unerschöpflichen
Wissenspeicher der Menschheit!
Nutze die Macht!

Und bist Du nicht Willens,
so scher' dich dorthin zurück, wo Du hergekommen bist!
In die Knechtschaft der Fenster und der Äpfel!
In das Gefängnis aus Apps und Kacheln!
Dort kannst Du raubkopieren oder zahlen.
Dort kannst Du jammern,
denn wahrlich - Du bist ausgeliefert
und zur Machtlosigkeit verdammt!