5
Incron stürzt ab öfters ab
Schönen guten Tag auch,
ich habe ein Debian Squeeze System auf einem Hetzner EX4 laufen.
Dazu habe incron installiert, um diverse Verzeichnisse zu überwachen bzw. ein PHP Skript auszuführen.
Soweit funktioniert das Ganze eigentlich auch wunderbar, er erkennt den IN_CLOSE_WRITE und führt das Skript mit dem Dateinamen aus.
Das Skript selbst parsed die Datei und schreibt dann die Daten in eine mySQL Datenbank.
Nun kann es sein, dass im späteren Stadium auf ca. 300 Verzeichnisse (abhängig von der Kundenanzahl) eine Überwachung läuft.
Dies wiederum kann dazu führen, dass eben ca. 300 Kunden bzw. deren Überwachungsgeräte per FTP 2-5 Dateien uploaden.
Worst-Case Szenario wäre also hier, dass 300 gleichzeitige FTP Uploads reinkommen.
Das wollte ich heute mal ausprobieren, indem ich per Skript in mehrere Verzeichnisse Dateien kopiert hatte. Alles in allem, man will ja stressen, 800-2000 Dateien auf 5-10 Verzeichnisse (je nach Test) .
Um nicht bis zu 2000 PHP Calls zu haben, die die Datenbank gleichzeitig attakieren, habe ich einen eher unschönen, aber einigermaßen praktikablen Ansatz gewählt, indem ich zum Start der PHP Datei folgendes einfügte:
Mittendrinnen, jedoch ohne (für mich) erkennbares Muster, stürtzt incrond ab. Laut syslog mit:
Ich hatte noch das ganze /var/log durchwühlt aber keinen weiteren Eintrag gefunden, der mir genauere Infos liefern könnte.
Dies geschieht nicht zwangsläufig nach einem Test oder nach X Tests, auch nicht nach X Dateien, sondern einfach so.
Auch bei einem Test mittels FTP, indem ich ein paar Dateien upgeloaded habe, brachte das Ganze zum Crash (dürften ungefähr 1000 Dateien gewesen sein). Natürlich kamen diese nicht auf einen Rutsch daher, sondern wurden Stück für Stück übertragen (max. Uploadgeschwindigkeit 10KB/s).
Übrigens behandelt jeder Call auch nur 1 Datei. Was mir aber schon aufgefallen ist, ist der Umstand, dass das Signal 2 x kommt und natürlich dementsprechend 2 mal das Skript auf dei Datei ausgeführt werden würde.
Aber dadurch sollte sich ja nicht der Daemon zum Absturz bringen lassen oder?
Gibt es denn eventuell noch Möglichkeiten, wo etwas geloggt sein könnte?
Gibt es unter *nix die Möglichkeit dazu, den Dienst so einzurichten, dass er sich nach einem Absturz automatisch wieder selbst startet?
Danke schon mal für Hilfen und Ratschläge
Gruß
Micha
ich habe ein Debian Squeeze System auf einem Hetzner EX4 laufen.
Dazu habe incron installiert, um diverse Verzeichnisse zu überwachen bzw. ein PHP Skript auszuführen.
Soweit funktioniert das Ganze eigentlich auch wunderbar, er erkennt den IN_CLOSE_WRITE und führt das Skript mit dem Dateinamen aus.
Das Skript selbst parsed die Datei und schreibt dann die Daten in eine mySQL Datenbank.
Nun kann es sein, dass im späteren Stadium auf ca. 300 Verzeichnisse (abhängig von der Kundenanzahl) eine Überwachung läuft.
Dies wiederum kann dazu führen, dass eben ca. 300 Kunden bzw. deren Überwachungsgeräte per FTP 2-5 Dateien uploaden.
Worst-Case Szenario wäre also hier, dass 300 gleichzeitige FTP Uploads reinkommen.
Das wollte ich heute mal ausprobieren, indem ich per Skript in mehrere Verzeichnisse Dateien kopiert hatte. Alles in allem, man will ja stressen, 800-2000 Dateien auf 5-10 Verzeichnisse (je nach Test) .
Um nicht bis zu 2000 PHP Calls zu haben, die die Datenbank gleichzeitig attakieren, habe ich einen eher unschönen, aber einigermaßen praktikablen Ansatz gewählt, indem ich zum Start der PHP Datei folgendes einfügte:
$random = rand(0, 30);
sleep($random);Mittendrinnen, jedoch ohne (für mich) erkennbares Muster, stürtzt incrond ab. Laut syslog mit:
Dec 23 12:28:46 servermaster incrond[4850]: *** unhandled exception occurred ***
Dec 23 12:28:46 servermaster incrond[4850]: polling failed
Dec 23 12:28:46 servermaster incrond[4850]: error: (11) Resource temporarily unavailable
Dec 23 12:28:46 servermaster incrond[4850]: stopping serviceIch hatte noch das ganze /var/log durchwühlt aber keinen weiteren Eintrag gefunden, der mir genauere Infos liefern könnte.
Dies geschieht nicht zwangsläufig nach einem Test oder nach X Tests, auch nicht nach X Dateien, sondern einfach so.
Auch bei einem Test mittels FTP, indem ich ein paar Dateien upgeloaded habe, brachte das Ganze zum Crash (dürften ungefähr 1000 Dateien gewesen sein). Natürlich kamen diese nicht auf einen Rutsch daher, sondern wurden Stück für Stück übertragen (max. Uploadgeschwindigkeit 10KB/s).
Übrigens behandelt jeder Call auch nur 1 Datei. Was mir aber schon aufgefallen ist, ist der Umstand, dass das Signal 2 x kommt und natürlich dementsprechend 2 mal das Skript auf dei Datei ausgeführt werden würde.
Aber dadurch sollte sich ja nicht der Daemon zum Absturz bringen lassen oder?
Gibt es denn eventuell noch Möglichkeiten, wo etwas geloggt sein könnte?
Gibt es unter *nix die Möglichkeit dazu, den Dienst so einzurichten, dass er sich nach einem Absturz automatisch wieder selbst startet?
Danke schon mal für Hilfen und Ratschläge
Gruß
Micha
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 178067
Url: https://administrator.de/forum/incron-stuerzt-ab-oefters-ab-178067.html
Ausgedruckt am: 22.12.2024 um 17:12 Uhr
5 Kommentare
Neuester Kommentar
Und was spricht dagegen, einen normalen Cron zu benutzen, der die Ordner einfach regelmäßig durchläuft?
Oder PHP in einer Schleife?
Übrigens hat unter Unix jeder Benutzer Beschränkungen auf die Anzahl der maximalen Prozesse und maximal geöffneten Dateien.
Alle neueren Service-Manager die nicht mehr auf dem reinen init basieren machen das.
Sonst gibt es auch immer noch z.B. supervise: http://cr.yp.to/daemontools/supervise.html
Oder PHP in einer Schleife?
Übrigens hat unter Unix jeder Benutzer Beschränkungen auf die Anzahl der maximalen Prozesse und maximal geöffneten Dateien.
Gibt es unter *nix die Möglichkeit dazu, den Dienst so einzurichten, dass er sich nach einem Absturz automatisch wieder selbst startet?
Alle neueren Service-Manager die nicht mehr auf dem reinen init basieren machen das.
Sonst gibt es auch immer noch z.B. supervise: http://cr.yp.to/daemontools/supervise.html
Hi dog,
PHP in einer Schleife habe ich gemacht.
Beziehungsweise, je nachdem wie viele Dateien in den Verzeichnissen vorhanden waren, wurden diese abgearbeitet und dann ggf. eine Zeit X gewartet (sleep) bevor das Skript die Funktion readbydir() (so hatte ich die genannt) wieder aufgerufen hatte. Ergebnis waren schlimme Memory Probleme, die sicherlich auch an nicht ganz optimiertem Code liegen können, doch wenn ich jedesmal sich selbst das Skript aufrufen lasse bzw. die Funktion neu aufrufe, wird über kurz oder lang das Memorylimit erreicht.
Der Cron war deshalb nicht möglich, da ich die Daten zeitnah benötige. Am liebsten ASAP. Angenommen ich setze den CRON auf 3 Minuten und er ist noch nicht fertig, könnten sich die 2 Aufrufe doch in die Quere kommen oder nicht? Ich müsste ja schon zu Beginn festlegen, was ich alles lesen will/muss. Dazu hatte ich unter anderem PHP glob() benutzt. Klar, hätte ich auch anders coden können, hatte aber nicht ganz ins Konzept gepasst, geb ich ehrlich zu
Eine CRON Zeit von > 5 Minuten ist inakzeptabel. Ich brauche die Daten zur Verarbeitung beim Eintreffen, man rand-sleep macht mir da eh schon Kopfschmerzen, aber ist im akzeptablen Rahmen.
Zu Beginn werden es vielleicht 100-200 Kunden sein, natürlich will ich da noch mehr drauf packen. Im Endeffekt wird vom Kunden bzw. dessen Überwachungsgerät per FTP Daten an mich geschickt, ich verarbeite diese und speichere sie in die DB und generiere daraus verschiedene SVGs zur Visualisierung. Und die sollten halt schnellstmöglich vorhanden sein. Auch wenn die Üebrwachungsgeräte "nur" im 5 Minuten Rhythmus senden.
Nochmal eine Rückfrage zu einer Aussage von Dir:
Wie bringe ich diese Beschränkung bezüglich max Procs und max Files in Erfahrung bzw. wie/wo kann ich die ändern?
Bis dato stand ich noch nie vor dem Problem, was mich grade wundert, denn ein anderer Server von mir bekommt für ein anderes Projekt teilweise 1000-2000 http-posts pro Minute geliefert und die werden mittels FAST-CGI abgearbeitet (und somit ja prozessen), auch mit DB, Dateien usw usw.. Gabs noch nie Probleme damit. Zumind. keine erkennbaren. Muss ich zwischen den Jahren mal kontrollieren.
Danke Dir schon mal für Deine Infos und Anregungen!
Gruß
Micha
PHP in einer Schleife habe ich gemacht.
Beziehungsweise, je nachdem wie viele Dateien in den Verzeichnissen vorhanden waren, wurden diese abgearbeitet und dann ggf. eine Zeit X gewartet (sleep) bevor das Skript die Funktion readbydir() (so hatte ich die genannt) wieder aufgerufen hatte. Ergebnis waren schlimme Memory Probleme, die sicherlich auch an nicht ganz optimiertem Code liegen können, doch wenn ich jedesmal sich selbst das Skript aufrufen lasse bzw. die Funktion neu aufrufe, wird über kurz oder lang das Memorylimit erreicht.
Der Cron war deshalb nicht möglich, da ich die Daten zeitnah benötige. Am liebsten ASAP. Angenommen ich setze den CRON auf 3 Minuten und er ist noch nicht fertig, könnten sich die 2 Aufrufe doch in die Quere kommen oder nicht? Ich müsste ja schon zu Beginn festlegen, was ich alles lesen will/muss. Dazu hatte ich unter anderem PHP glob() benutzt. Klar, hätte ich auch anders coden können, hatte aber nicht ganz ins Konzept gepasst, geb ich ehrlich zu
Eine CRON Zeit von > 5 Minuten ist inakzeptabel. Ich brauche die Daten zur Verarbeitung beim Eintreffen, man rand-sleep macht mir da eh schon Kopfschmerzen, aber ist im akzeptablen Rahmen.Zu Beginn werden es vielleicht 100-200 Kunden sein, natürlich will ich da noch mehr drauf packen. Im Endeffekt wird vom Kunden bzw. dessen Überwachungsgerät per FTP Daten an mich geschickt, ich verarbeite diese und speichere sie in die DB und generiere daraus verschiedene SVGs zur Visualisierung. Und die sollten halt schnellstmöglich vorhanden sein. Auch wenn die Üebrwachungsgeräte "nur" im 5 Minuten Rhythmus senden.
Nochmal eine Rückfrage zu einer Aussage von Dir:
Wie bringe ich diese Beschränkung bezüglich max Procs und max Files in Erfahrung bzw. wie/wo kann ich die ändern?
Bis dato stand ich noch nie vor dem Problem, was mich grade wundert, denn ein anderer Server von mir bekommt für ein anderes Projekt teilweise 1000-2000 http-posts pro Minute geliefert und die werden mittels FAST-CGI abgearbeitet (und somit ja prozessen), auch mit DB, Dateien usw usw.. Gabs noch nie Probleme damit. Zumind. keine erkennbaren. Muss ich zwischen den Jahren mal kontrollieren.
Danke Dir schon mal für Deine Infos und Anregungen!
Gruß
Micha
könnten sich die 2 Aufrufe doch in die Quere kommen oder nicht?
Du kannst ja mit File Locking arbeiten und so prüfen ob eine Datei bearbeitet wird.
Wie bringe ich diese Beschränkung bezüglich max Procs und max Files in Erfahrung bzw. wie/wo kann ich die ändern?
Innerhalb einer Shell kann man die Grenzen mit ulimit steuern und abfragen: ulimit -a.Oder du nimmst statt FTP-Upload einen HTTP-Upload und kannst PHP direkt einbinden.
Vielleicht ist PHP dafür aber auch einfach das falsche Werkzeug und du solltest eher Java etc. benutzen.
Hi Dog,
HTTP Upload geht nicht, geben die Überwachungsgeräte nicht her. Ausserdem kann die Größe der Dateien stark schwanken von morgens vielleicht ein paar Bytes bis hin zu Abends auf mehrere 10K pro Datei und dann kommen mind. immmer 5 Dateien bis zu 8 Stück.
Das mit den File Locking wäre eine Idee, dann würde aber wieder ein Job alle Dateien abgrasen müssen oder ich lege pro Kunde einen Cron an. Wiegesagt, die Grenze von ca. 5 Minuten darf einfach nicht überschritten werden.
umlimit -a sagt mir übrigens 1024 open Files.
Muss ich ggf. daran noch arbeiten.
Das hier PHP zum Einsatz kommt, hat 2 Gründe:
1. Ich kann kein Java (wie von Dir vorgeschlagen)
2. Die Bibliotheken / Funktionen sind nunmal einfach schon vorhanden als PHP bzw. das ganze System setzt im Webfrontend und Backend auf PHP/jQuery. Ich müsste das Rad also 2mal neu erfinden.
Gruß Micha
PS: Danke nochmal an der Stelle für Deine Hilfe. Jetzt lassen wir das mal gut sein für 2-3 Tage und ich wünsche euch allen und im speziellen Dir ein Frohes Fest und ruhige, besinnliche Stunden
HTTP Upload geht nicht, geben die Überwachungsgeräte nicht her. Ausserdem kann die Größe der Dateien stark schwanken von morgens vielleicht ein paar Bytes bis hin zu Abends auf mehrere 10K pro Datei und dann kommen mind. immmer 5 Dateien bis zu 8 Stück.
Das mit den File Locking wäre eine Idee, dann würde aber wieder ein Job alle Dateien abgrasen müssen oder ich lege pro Kunde einen Cron an. Wiegesagt, die Grenze von ca. 5 Minuten darf einfach nicht überschritten werden.
umlimit -a sagt mir übrigens 1024 open Files.
Muss ich ggf. daran noch arbeiten.
Das hier PHP zum Einsatz kommt, hat 2 Gründe:
1. Ich kann kein Java (wie von Dir vorgeschlagen)
2. Die Bibliotheken / Funktionen sind nunmal einfach schon vorhanden als PHP bzw. das ganze System setzt im Webfrontend und Backend auf PHP/jQuery. Ich müsste das Rad also 2mal neu erfinden.
Gruß Micha
PS: Danke nochmal an der Stelle für Deine Hilfe. Jetzt lassen wir das mal gut sein für 2-3 Tage und ich wünsche euch allen und im speziellen Dir ein Frohes Fest und ruhige, besinnliche Stunden
So,
ich markier das ganze mal als gelöst.
Ich hatte die max. open files usw. mal nach oben geschraubt und etliche Streßtests verliefen bis dato positiv.
Hoffentlich bleibts auch dabei, wenn mehr Kunden an das System kommen.
Zudem habe ich parallel noch einen 5 Minuten Cron eingebaut, der nachprüft, ob noch Dateien vorhanden, die "vergessen" wurden.
Dabei wird jetzt von incron zu jeder Datei eine Job Datei erzeugt. Ist diese Job Datei für eine Datei nicht vorhanden oder der Job + Datei älter als 10 Minuten, scheint sie incron verloren zu haben (warum auch immer, trat auch noch nicht auf) und diese Datei würde dann über den cron "nachträglich" eingelesen werden. Dazu überprüft der Cron vorher nochmals ob incron läuft. Wenn nicht, wird dieser gestartet.
Nicht ganz ideal, das gebe ich zu, aber zumind. eine Art kleiner Fallback.
ich markier das ganze mal als gelöst.
Ich hatte die max. open files usw. mal nach oben geschraubt und etliche Streßtests verliefen bis dato positiv.
Hoffentlich bleibts auch dabei, wenn mehr Kunden an das System kommen.
Zudem habe ich parallel noch einen 5 Minuten Cron eingebaut, der nachprüft, ob noch Dateien vorhanden, die "vergessen" wurden.
Dabei wird jetzt von incron zu jeder Datei eine Job Datei erzeugt. Ist diese Job Datei für eine Datei nicht vorhanden oder der Job + Datei älter als 10 Minuten, scheint sie incron verloren zu haben (warum auch immer, trat auch noch nicht auf) und diese Datei würde dann über den cron "nachträglich" eingelesen werden. Dazu überprüft der Cron vorher nochmals ob incron läuft. Wenn nicht, wird dieser gestartet.
Nicht ganz ideal, das gebe ich zu, aber zumind. eine Art kleiner Fallback.
