Probleme nach dem Löschen von Dateien

raba

raba

New Member
Hallo,

ich bin ganz neu hier und hoffe, ihr könnt mir helfen. Mein Provider, bei dem ich einen V-Server unter Ubuntu 16.04 betreibe meinte, ich sei mit meiner Frage in einem solchen Forum besser als bei ihm aufgehoben.

Es geht um Folgendes: mehrmals pro Woche läuft ein Sicherungsprozess (MySQL-Datenbanken werden mit xtrabackup von Percona gesichert). Dabei werden mehrere Dateien erzeugt. Eine davon ist mit fast 300 GB wesentlich größer als die anderen.

Später werden die Dateien mit "rm -R ..." wieder gelöscht. Und jetzt kommt das Problem: Danach funktionieren die Applikationen, die den Apache benutzen, nicht mehr. Wenn ich "systemctl restart apache2" eingebe, ist alles wieder in Ordnung. In den Protokolldateien finde ich keine Hinweise (außer den Zeilen, die angeben, dass ich den Apache neu gestartet habe).

Wie kann ein Löschprozess solche Auswirkungen auf andere Anwendungen haben? Liegt das vielleicht daran, dass ein V-Server beim Löschen einer so großen Datei Probleme bekommt?

Noch ein weiteres Phänomen habe ich gelegentlich beobachtet: Nach "rm -R ..." verändert sich die Anzeige von "df" nicht. Ich weiß, dass dies darauf zurückgeführt werden kann, dass ein anderer Prozess noch eine Verbindung zu den gerade gelöschten Dateien hat, aber mit "lsof|grep deleted" finde ich nichts. Nach einer Weile wird bei "df" ohne weiteres Zutun der richtige Wert ausgegeben.

Kann dies alles an der sehr großen Datei liegen?

Gruß

Ralph
 
Danach funktionieren die Applikationen, die den Apache benutzen, nicht mehr.
Click to expand...

Was heisst: "funktionieren nicht mehr?" Wie ist die Fehlermeldung? Hat die Applikation vielleicht noch ein eigenes Log neben dem Apachen?

Ist die DB noch erreichbar, wenn die Anwendung nicht funktioniert(Mal prüfen sich mit mysql von der Konsole zu verbinden und eine Abfrage auf den betreffenden DBs ausführen)?
 
Last edited by a moderator:
Bitte die exakte Vorgehensweise (alle Befehle inklusive aller Optionen) vom ersten bis zum letzten Schritt (step-by-step) und die exakten Fehlermeldungen posten.

Welche Virtualisierung?
Welches OS?
Welches FS?
 
Hallo ihr alle,

vielen Dank für das in mehreren Antworten gezeigte Interesse.

Dei Angelegenheit ist etwas verzwickt und daher möchte ich ganz ausführlich dazu schreiben.

Der V-Server läuft bei Strato unter der Virtuozzo-Virtualisierungsumgebung mit Ubuntu 16.04 LTS 64bit + Plesk Onyx.

Um meine MYSQL-Datenbanken, die weitgehend aus InnoDB-Tabellen bestehen, konsistent sichern zu können, bereite ich die Daten mit dem Tool "xtrabackup" von Percona im laufenden Betrieb vor. Dabei werden die Tabellen an eine andere Stelle im Dateisystem (nach .../mysql.sicher/) kopiert, zusammen mit einer Protokolldatei, mit deren Hilfe die Transaktionen, die während der Sicherungszeit angefallen sind, nachgeholt werden können. Unter diesen kopierten Dateien bzw. Datenbanktabellen befindet sich eine Tabelle, die fast 300 GB groß ist.

Nach Abschluss des Kopiervorganges werden die kopierten Dateien (die sich jetzt nicht mehr verändern) mit "rsync ..." auf ein externes Speichermedium gesichert.

Vor dem nächsten Durchlauf (also deutlich später) werden die gesicherten Dateien mit "rm -r mysql.sicher/" gelöscht.

Und genau danach kommt es reproduzierbar zu diesen Ausfällen. Ich habe das gestern einmal genauer untersucht. Und zwar sind nicht alle Applikationen, die von Apache bedient werden, betroffen. Einige Seiten laufen weiter so, als wäre nichts gewesen. "Hängen" tun Moodle, Mahara und Horde. Da mir bisher immer nur der Ausfall dieser häufig benutzten Anwendungen aufgefallen war, ging ich von einer generellen Störung aus.

Im error.log von Moodle findet sich mehrere Einträge der Form:
[proxy_fcgi:error] [pid 3493] (70007)The timeout specified has expired: [client XXX.XX.XXX.XXX:32826] AH01075: Error dispatching request to : (polling)

Übrigens ging es gestern nach ca 4 Minuten wieder von selber weiter, aber das war nicht immer so.

Was mag das wohl sein?

Gruß und vielen Dank für die Unterstützung
Ralph
 
Joe User said:
Bitte die exakte Vorgehensweise (alle Befehle inklusive aller Optionen) vom ersten bis zum letzten Schritt (step-by-step) und die exakten Fehlermeldungen posten.
Click to expand...
Du wirst Dich hiervor nicht drücken können, wenn Du ernsthafte Hilfe möchtest...
 
Ich habe es heute wieder ausprobiert. Derselbe Effekt. Diesmal hat es sich gar nicht mehr von selber gerappelt. Ich vergaß noch, dass auch Plesk davon betroffen ist. Nach einer gewissen Wartezeit kommt:

Code: 
Nginx 504 Gateway Time-out

Nun hat mich Joe User um weitere Präzisierungen gebeten. Mal sehen, was ich hier noch finde.

Zunächst der genaue xtrabackup-Befehl (Passwort rausgenommen):

Code: 
xtrabackup -u<username> -p<password> --open-files-limit=2500 --backup --target-dir=/var/lib/mysql.sicherung/base

Der Filesystemtyp ist vzfs

Noch eine Beobachtung: vielleicht weil Horde "aus dem Takt" kommt, muss auch der Mailserver (dbmail-imapd), der auf einem anderen Rechner läuft, wieder neu gestartet werden.

Was soll ich noch schreiben? Die von mir gefundenen Fehlermeldungen stehen schon in der vorigen Mail.

Gruß
Ralph Ballier
 
Wie wäre es mal, wenn du mal in den Logdateien schaust, was da zu dem Zeitpunkt für Einträge gemacht werden?
 
Hallo ihr alle,

sorry für die lange Pause, aber ich habe versucht, selber weitere Informationen über das Problem zusammenzutragen (in der Hoffnung, ihr könnt mir doch noch helfen) und bin dabei sogar fündig geworden.

Zunächst zum Vorgehen: Ich habe mit einem Shellskript bewirkt, dass alle zwei Sekunden
Code: 
ps ax
in eine Datei geschrieben wurde. Gestartet habe ich dieses Skript kurz bevor ich den Löschbefehl
Code: 
rm -r ...
ausgelöst habe. Und nun das Ergebnis:

Zusammenfassung
Die Prozesse vom Typ
Code: 
php-fpm: pool example.com
laufen aus dem Ruder. Dabei steht
Code: 
example.com
für fünf unterschiedliche Webseiten-URL.

In Einzelnen
Im "Ruhezustand" (vor und nach dem Ausfall) beträgt die Anzahl der angezeigten Prozesse vom Typ
Code: 
php-fpm: pool example.com
vier bis sechs. (Der Server ist ganz allgemein wenig belastet.). Es folgt der weitere zeitliche Verlauf:

Nach 1 Minute: 17 Prozesse
Nach 2 Minuten: 37 Prozesse
Nach 3 Minuten: 55 Prozesse
Nach 4 Minuten: 62 Prozesse
Nach 5 Minuten: 91 Prozesse
Nach 6 Minuten: 112 Prozesse
Nach 7 Minuten: 129 Prozesse
Nach 8 Minuten: 48 Prozesse
(danach nicht mehr gemessen)

Dann sind die Seiten ohne weitere Eingriffe wieder zugänglich.

pm.max_children hatte ich bereits hochgesetzt. Man sieht aber unmittelbar, dass es an einer zu niedrigen Einstellung nicht liegen kann.

Einige Meldungen in diesem Zusammenhang:

Nginx 504 Gateway Time-out erscheint im Webbrowser nach einer Weile.

In den Logdateien gibt es folgende Meldungen:
Code: 
ERROR: unable to read what child say: Bad file descriptor (9)
[pid 8177] (70007)The timeout specified has expired: [client XXX.XX.XXX.XX:52624] AH01075: Error dispatching request to : (polling)
*1182255 upstream timed out (110: Connection timed out) while reading response header from upstream, client: ...

Vielleicht hilft das weiter?

Ralph
 
Was steht denn in journalctl und kern.log? Am besten mal auf pastebin hochladen. Das können nicht alle Logmeldungen sein. Warum werden überhaupt so viele php-fpm Prozesse gestartet, wenn kaum jemand auf die Seite zugreift? Läuft Plesk selbst unter php-fpm?
 
Evtl. auch mal die /proc/user_beancounters beobachten, während das Backup läuft - es könnte auch sein, dass du da an Limits stößt, die Strato auf seinen vServern festgelegt hat
 
Hallo Chris4000,

vielen Dank für deine Antwort.

chris4000 said:
Was steht denn in journalctl und kern.log? Am besten mal auf pastebin hochladen. Das können nicht alle Logmeldungen sein. Warum werden überhaupt so viele php-fpm Prozesse gestartet, wenn kaum jemand auf die Seite zugreift? Läuft Plesk selbst unter php-fpm?
Click to expand...

Zu deinen Fragen:
  • In journalctl steht im entsprechenden Zeitraum nichts, was auffällig wäre.
  • Die Datei "kern.log" gibt es bei mir nicht. Muss ich einen Dienst hierfür noch konfigurieren?
  • Warum so viele Prozesse gestartet werden: genau das ist mein Problem.
  • Schließlich: auch Plesk läuft unter php-fpm:
    Code: 
    php-fpm: master process (/opt/plesk/php/5.6/etc/php-fpm.conf)
Gruß
Ralph
 
Hallo,

nun kommt es doch noch zu einem guten Ende. Mein Provider teilt mir mit, er sei dahintergekommen, dass das Löschen dieser Datenmengen für große Lastspitzen gesorgt hat, die für mich deutlich spürbar waren. Es wurden Maßnahmen auf dem Hostsystem ergriffen, die die Last beim Löschen dieser Datenmengen bei weitem nicht mehr so in die Höhe treiben.

Ein Test zeigt, dass jetzt alles in Ordnung ist.

Etwas befremdlich fand ich es, dass mir hier vorgeworfen wurde, ich würde Informationen zurückhalten, wo ich doch ausführlich über alles berichtet habe, was mir irgendwie zugänglich war.
 
Hallo Raba,

hier im SSF wird von vielen erwartet, dass Du selbst Dich auskennst, dass Du bereit bist, Dich mit Deinem Server zu beschäftigen und dass das in Deinen Beiträgen auch rüberkommt. Serveradministration ist grundsätzlich eine komplexe Angelegenheit, bei dem hier ein gewisses Mindestmaß an Kompetenz und Eigeninitiative vorausgesetzt wird. Ist dieses Mindestmaß nicht gegeben, z. B. dadurch dass Anfragen zu wenige Informationen enthalten, gibt es hier massiv Nackenschläge.

Das ist nicht meine Meinung, sondern die von mir wahrgenommene Realität hier.

Konkret bedeutet das, dass erwartet wird, dass man sich grundsätzlich mit dem jeweils verwendeten System auseinandergesetzt hat und demzufolge weiß, wo relevante Logs liegen, daß man diese bereits selbst geprüft hat und daß man die Erkenntnisse dieser Prüfung bzw. relevante Logauszüge oder Ausgaben von den für die jeweilige Situation relevanten Diagnosetools bereitstellt, damit man hier aus der Ferne überhaupt eine Möglichkeit hat, das jeweilige System zu beurteilen.

Das was bei Dir fehlte, wurde mehrfach von Dir eingefordert. Lies Dir einfach den ganzen Thread nochmal in Ruhe durch.

Grüße,
g.
 
Last edited by a moderator:
Vielen Dank für diese Hinweise.

Es war doch aber so, dass ich in den Logdateien meines V-Servers gar nichts finden konnte, weil sich alles auf einer höheren Ebene, nämlich der Verwaltung des "Blechs" abspielte. Erst als die übergeordneten Admins, denen ich meine Beobachtungen so geschildert habe, wie hier im Forum, den Fehler gefunden haben, ging es voran.

Ich konnte also gar nicht mehr mitteilen und meine im Laufe der Jahre erworbenen Kenntnisse haben mir nichts genützt. Wäre es ein dedicated Server gewesen, dann allerdings hätten die Kritikpunkte vielleicht zugetroffen.

Es wäre vielleicht günstiger gewesen, die Anfrage im Forum V-Server zu stellen.

Ralph
 
Meine Fragen ziehlten explizit darauf ab, zu entscheiden, ob das Problem von Dir auf VM-Seite oder vom Hoster auf Host-Seite lösbar ist. Hättest Du die Fragen also vernünftig und vollständig beantwortet, hätte man Dich gleich an den Hoster verweisen können, statt hier sinnfreie Diskussionen zu führen oder im Nebel stochern zu müssen...
 
You must log in or register to reply here.
Back
Top