[vz-dev] Middleware Absturz

Wed Apr 11 09:41:47 CEST 2012

On Wed, 11 Apr 2012 06:42:47 +0200 "Tom Weber" <tom.weber at gmx.de> wrote:
> Hei,
> 
> Thorben, du hattest mit deiner Vermutung Recht, unten ein Auszug aus dmesg
> mit zig Kills.
> 
> Frage wäre: Was kann ich tun? Aufrüsten von Sheeva auf einen PC möchte ich
> nicht so gerne, ich könnte es mit meinem NAS probieren (hat aber weniger
> RAM)

nunja, andere benutzen vz.org ja wohl auch mit (mehr) erfolg auf aehnlichen
systemen...
haben andere vlt eine auslagerungsdatei/partition angelegt und du nicht?

was an deinem log stutzig macht sind solche zeilen:
> [80949.352194] postgres invoked oom-killer: gfp_mask=0x201da, order=0,
> [82835.405992] postgres invoked oom-killer: gfp_mask=0x201da, order=0,
> [94217.345931] postgres invoked oom-killer: gfp_mask=0x201da, order=0,

postgres ist ein anderer datenbankserver, den du scheinbar installiert hast,
volkszaehler benutzt aber mysql...
ich vermute du hast viel muell auf deinem system laufen, der den speicher
verbraucht... hast du irgendeine standard-installation ("datenbankserver")
gemacht? gerade bei so einem kleinen system sollte man nur eine minimale
machen, und alles _benoetigte_ einzeln nachinstallieren.
wenn du das nicht selber aufgeraeumt bekommst, waer's vermutlich am
einfachsten wenn du das ding sauber neu installierst...

ansonsten zB mal top starten, mit shift-M nach speicherverbrauch sortieren,
und anfangen nicht benoetigtes rauswerfen.
alternativ `deborphan -a` und nicht benoetigtes deinstallieren.

> Ich versuche jetzt erst mal, die my.cnf anzupassen...CHECK TABLE lief
> übrigens brav durch.

was man zB auch machen koennte waehre in der apache-config die anzahl der
threads runtersetzen.

> Grüße,
> Tom

- T.

> [80949.330931] Out of memory: kill process 741 (mysqld_safe)
> [80949.352194] postgres invoked oom-killer: 
> [80949.647436] Out of memory: kill process 13105 (apache2)
> [82834.410512] mysqld invoked oom-killer: 
> [82834.705770] Out of memory: kill process 741 (mysqld_safe)
> [82835.405992] postgres invoked oom-killer: 
> [82835.701761] Out of memory: kill process 13563 (apache2)
> [94217.345931] postgres invoked oom-killer: 
> [94217.641382] Out of memory: kill process 15366 (apache2)
> [98309.566364] apache2 invoked oom-killer: 
> [98309.861631] Out of memory: kill process 15880 (apache2)
> [98713.113644] apache2 invoked oom-killer: 
> [98713.370815] Out of memory: kill process 16107 (apache2)
> [99119.875929] startpar invoked oom-killer: 
> [99120.170186] Out of memory: kill process 15947 (apache2)
> [103476.365668] apache2 invoked oom-killer: 
> [103476.663429] Out of memory: kill process 16781 (apache2)
[...]

> -----Ursprüngliche Nachricht-----
> Von: volkszaehler-dev-bounces at lists.volkszaehler.org
> [mailto:volkszaehler-dev-bounces at lists.volkszaehler.org] Im Auftrag von
> Thorben Thuermer
> Gesendet: Dienstag, 10. April 2012 13:59
> An: volkszaehler.org
> Betreff: Re: [vz-dev] Middleware Absturz
> 
> On Tue, 10 Apr 2012 09:08:24 +0200 "Tom Weber" <tom.weber at gmx.de> wrote:
> > Hi,
> > 
> > ja, in den access.log sehe ich alle POSTS und auch die GETS - auch die 
> > der Zeiten, wo die DB nicht mehr gefüllt wurde. Also scheinen die 
> > requests durchgereicht zu werden.
> 
> kannst du die middleware-antworten denn sehen (manueller aufruf, vzlogger
> mit hohem debug-level, notfalls traffic-sniffer) und sind die ok?
> 
> > Ein OPTIMIZE geht auf allen Tabellen bis auf DATA. Da kommt es nach 
> > einigen Minuten zu:
> > ERROR 2013 (HY000): Lost connection to MySQL server during query
> 
> schaue mal in dmesg, vermutlich wurde mysql aufgrund von speichermangel
> gekillt...
> ("kernel: [...] Out of memory: Kill process ... (mysqld)") das koennte auch
> deine anderen probleme erklaeren.
> 
> und: optimize ist NICHT noetig/sinnvoll...
> das entfernt nach loeschoperationen freigewordene ungenutzte bereiche aus
> der tabelle - aber volkszaehler loescht eigentlich eh nie was.
> wenn check table sagt die tabelle ist ok, reicht das eigentlich, vielleicht
> noch ein repair hinterher...
> 
> > Leider auch schon ca. 2 Mill Datensätze ....
> 
> kann gut sein, dass sich da irgendwann die grenzen einer so kleinen hardware
> zeigen...
> (also, fuer den normalen betrieb reicht es, aber nicht fuer operationen  auf
> so grossen tabellen als ganzes.) notfalls kann man die tabelle vermutlich
> noch auf eine groesseres system (gleicher endianess?) kopieren und dort
> reparieren. (auch wenn mysql nicht garantiert das das funktioniert.)
> 
> > Tom
> 
> - Thorben
> 
> > -----Ursprüngliche Nachricht-----
> > Von: volkszaehler-dev-bounces at lists.volkszaehler.org
> > [mailto:volkszaehler-dev-bounces at lists.volkszaehler.org] Im Auftrag 
> > von Thorben Thuermer
> > Gesendet: Montag, 9. April 2012 22:02
> > An: volkszaehler.org
> > Betreff: Re: [vz-dev] Middleware Absturz
> > 
> > On Mon, 9 Apr 2012 21:41:44 +0200 "Tom Weber" <tom.weber at gmx.de> wrote:
> > > ich habe bei meiner Sheeva Middleware immer wieder das Problem, dass 
> > > sie sich nach einigen Tagen oder Stunden verabschiedet.
> > > Es findet dann keinerlei Aufzeichnung mehr statt, weder s0 noch
> vzlogger.
> > > Bizarrerweise kann ich aber die middleware.php aufrufen, apache 
> > > scheint also zu laufen. Auch die error.log zeigt in meinen Augen 
> > > keine Auffälligkeiten....
> > > 
> > > Wie kann ich dem Fehler auf die Schliche kommen?
> > 
> > also, die middleware als solche kann ja nicht "abstuerzen", zumal es 
> > sich um ein php-script handelt, das vom webserver fuer fuer jeden 
> > eingehenden request neu ausgefuehrt wird.
> > 
> > die fragen die zu klaeren sind sind im prinzip:
> > * erzeugen der/die client/s noch requests
> > * erreichen diese requests den webserver
> > * verarbeitet der webserver diese
> > * treten bei der verarbeitung probleme auf
> > 
> > du sagst, manuell abgesetzte requests funktionieren noch?
> > betrifft das nur das abrufen von daten, oder auch das eintragen (zB 
> > auf einem dafuer erzeugten test-kanal)?
> > 
> > du sagst im error-log steht nichts...
> > wie sieht es dann mit access.log aus? da sollten die requests in jedem 
> > fall auftauchen, wenn sie gesendet werden und den server erreichen.
> > 
> > im zweifelsfall mit wireshark etc. pruefen, ob noch requests ueber's 
> > netz gehen.
> > 
> > was ich auch lohnt zu pruefen ist, ob die dahinterliegende 
> > mysql-datenbank ggfs. probleme hat - das ist auch ein haeufiges problem.
> > (show processlist - haengen ggfs mysql-anfragen (platte voll?),  oder 
> > mal ein check/repair table.)
> > 
> > > Hilfe wäre Klasse,
> > > Tom
> > 
> > - Thorben
> > 
> 