Beiträge von Konni

  • LightTPD

    Hallo Sebastian,


    du kannst in der Konfiguration selbst angeben, wieviele PHP-Prozesse gestartet werden sollen. Das ist natürlich abhängig von der Last, die dein Server bewältigen muss.


    Gruß
    Konni


    PS: lighttpd wird soweit ich weiß auch von Wikipedia und YouTube eingesetzt.

  • LightTPD

    Also der Speicherverbrauch liegt bei mir im Vergleich bei ca. 20 zu 4 MB. Wobei ich den Apache schon lange nicht mehr laufen gehabt habe.


    Via FastCGI sind auch PHP-Applikationen schön flott.


    Gruß
    Konni

  • LightTPD

    Ich nutze lighttpd auch auf meinem vServer. Er kann im Prinzip fast alles, was der Apache auch kann. Ein paar Mängel hat er aber leider noch. z.B. keine vollständige WebDAV-Implementierung. Dafür ist er aber sehr flott, ressourcenschonend und einfach zu konfigurieren.


    Als Einstieg kann ich Dir die Wikiseite auf Ubuntuusers.de empfehlen:
    http://wiki.ubuntuusers.de/lighttpd


    Gruß
    Konni

  • vServer: seit 3 Tagen regelmäßig korrupte MySQL-Tabellen

    Zitat von henk77;9493

    Hallo Konni,


    falls dein postfix bzw. Teile davon tatsächlich chrooted laufen, dann solltest du dir mal die Doku zu proxymap anschauen. Die Anleitung mit dem Link ist meiner Meinung nach eher unschön, falls sie denn überhaupt funktionieren sollte.


    In jedem Fall sollten postfix und andere Dienste deinen mysql server nicht zum crashen bringen können. Falls du noch nicht sichergestellt hast, dass alle Dienste nicht mehr Arbeitsspeicher wollen können als dir zur Verfügung steht, d.h. im Wesentlichen jeweils die maximale Anzahl an Prozessen beschränkt hast, solltest du das mal tun und dann den mysql server komplett neu aufsetzen.


    postfix läuft normal gar nicht chrooted. Zumindest steht in der chroot-Spalte in der master.cf überall ein "-" oder ein "n".


    Ich glaube nicht, dass dem Server irgendwie der Speicher ausgeht. Wenn ich morgens den abgeschmierten Server untersuche, sind so 120 von 200 MB belegt. Nachdem ich MySQL dann neu gestartet habe und smtpd dann alle Mails noch verteilt hat, sind es nur noch 80 MB.


    Wo bzw. wie soll denn nachts ohne Last dem Server der Speicher ausgehen? Tagsüber läuft er ja immer einwandfrei und auch performant. Es lief ja auch alles über Monate einwandfrei.


    Ich vermute immer noch, dass das etwas mit dem neuen Kernel oder meinem VM-Backup zu tun hat ...


    Wenn es morgen wieder auftritt, schmeisse ich MySQL mal komplett runter und installiere es neu.


    Gruß
    Konni

  • vServer: seit 3 Tagen regelmäßig korrupte MySQL-Tabellen

    Kleiner Nachtrag:
    Was ich auch sehr seltsam finde, ist, dass MySQL gar nichts loggt. Sowohl mysql.log wie auch mysql.err sind komplett leer (0 Byte).


    Ist da nicht standardmäßig ein Logging aktiviert? Ich schaue mal in die Config ...


    Edit: Ich habe jetzt das Logging mal testweise aktiviert (schluckt laut der Kommentare wohl ordentlich Performance).


    Gruß
    Konni

  • vServer: seit 3 Tagen regelmäßig korrupte MySQL-Tabellen

    Ich glaube auch nicht, dass es an dem PHP-Cron liegt, da der ja alle 30 Minuten einwandfrei durchläuft. Warum sollte er gerade nachts immer einmal zu einem Problem mit postfix und MySQL führen.


    Im Anhang habe ich noch meine sources.list + eine packages.list, die alle installierten Pakete und Programme enthält.


    Ich kann auch gerne mal root-Zugriff jemandem geben, wenn es jemanden mit sehr guten Debugging-Kenntnissen gibt.


    Gruß
    Konni

  • vServer: seit 3 Tagen regelmäßig korrupte MySQL-Tabellen

    Ich muss jetzt noch kurz an die Uni, danach gibt es die nötigen Infos.


    Zusätzlich sind glaube ich nur denyhosts und lighttpd installiert (via apt-get). Alle Programme sind mittels dist-upgrade auf den neuesten Stand gebracht worden. sources.list ist noch die originale, kann ich aber dann gerne nochmal hier einfügen.


    Danke und Gruß
    Konni


    PS: Alternativ würde ich auch einfach eine Neu-Installation durchführen - dann aber am liebsten schon gleich mit Lenny.

  • vServer: seit 3 Tagen regelmäßig korrupte MySQL-Tabellen

    Leider keine Entwarnung, Jungs ... immer noch der selbe Fehler. Ich vermute entweder ein Problem mit syscp oder mit MySQL, denn diese beiden Dienste laufen immer als letztes durch, bevor postfix nicht mehr auf MySQL zugreifen kann:


    Was macht der Cron mit dem php-Aufruf eigentlich genau? Ich kann die Syntax nicht komplett entschlüsseln. Killt der einfach alle PHP-Skripte, die länger laufen als die gültige Skriptlaufzeit?


    Was bezweckt der mysqld_safe restart um diese Uhrzeit (das macht er täglich)? Ist das ein Cron oder wird der Aufruf durch irgendeinen Fehler verursacht?
    Das sieht doch fast so aus, als wäre MySQL durch irgendwas abgewürgt worden, so dass es neugestartet werden muss. Anscheinend macht er dabei aber irgendwas beim Neustart falsch (fehlende mysqld-sock Verlinkung für postfix?).


    Gruß
    Konni

  • vServer: seit 3 Tagen regelmäßig korrupte MySQL-Tabellen

    Danke, Jungs - das sieht echt genau nach meinem Fehler aus. Zumal postfix vor einigen Tagen auch tatsächlich von mir upgedatet wurde, wenn ich mich recht erinnere.


    Müsste nicht vor dem Update auch schon ein ähnlicher Code im Init-Script gewesen sein?


    Jetzt drückt mir alle die Daumen, dass es auch wirklich daran gelegen hat. ;)


    Falls dann alles gut ist, gebe ich auch virtuell ein Bier aus. :)


    Gruß
    Konni

  • vServer: seit 3 Tagen regelmäßig korrupte MySQL-Tabellen

    Hm ... selbst nach einem Neustart zeigt localhost immer noch auf die externe IP. Oder muss ich die Zeile mit 127.0.0.1 einfach über die andere schieben, damit diese zuerst "gewählt" wird?


    Im Syscp-Forum (du meinst doch das Unterforum hier im Forum, oder?) habe ich noch nicht nachgefragt. Nur mal kurz gestöbert, ob jemand ähnliche Probleme hat.

  • vServer: seit 3 Tagen regelmäßig korrupte MySQL-Tabellen

    Der letzte Cron-Job, der durchgeflaufen ist, steht ja auch im letzten syslog-Ausschnitt ^^


    Code
    Nov 14 01:55:38 v230211191 -- MARK --
Nov 14 02:09:01 v230211191 /USR/SBIN/CRON[30600]: (root) CMD (  [ -d /var/lib/php5 ] && find /var/lib/php5/ -type f -cmin +$(/usr/lib/php5/maxlifetime) -print0 | xargs -r -0 rm)
Nov 14 02:17:02 v230211191 /USR/SBIN/CRON[32415]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Nov 14 02:35:38 v230211191 -- MARK --
Nov 14 02:39:01 v230211191 /USR/SBIN/CRON[4013]: (root) CMD (  [ -d /var/lib/php5 ] && find /var/lib/php5/ -type f -cmin +$(/usr/lib/php5/maxlifetime) -print0 | xargs -r -0 rm)
Nov 14 02:55:38 v230211191 -- MARK --

    Den syscp-Cron-Job habe ich ja schon deaktivier.


    Die Änderung der der hosts-Datei hat aber (noch) nichts bewirkt. Kann ich irgendwie den DNS-Cache löschen?
    rndc flush hat nicht funktioniert.


    Gruß
    Konni

  • vServer: seit 3 Tagen regelmäßig korrupte MySQL-Tabellen

    andre
    Die Datei ist leider kein reines Text-Format, sondern beinhaltet auch Binärdaten. Außerdem etwas zu groß, um sie hier anzuhängen.


    bebbo
    Tatsache ... localhost führt nicht zu 127.0.0.1, sondern zur "externen" IP-Adresse.


    In /etc/hosts steht:

    Code
    188.40.236.111 v230211191 v230211191.yourvserver.net localhost


    In /etc/postfix/main.cf steht folgendes:

    Code
    myhostname = v230211191.yourvserver.net
mydomain = v230211191.yourvserver.net
mydestination = $myhostname $mydomain localhost localhost.$mydomain
mynetworks = 127.0.0.0/8


    In /etc/mysql/my.cnf:

    Code
    bind-address            = 127.0.0.1


    Es lief ja auch seit Monaten einwandfrei. Kann das vielleicht was mit dem Kernel-Update von letzter Woche zu tun haben?


    Gruß
    Konni

  • vServer: seit 3 Tagen regelmäßig korrupte MySQL-Tabellen

    Wie zu erwarten war der Server heute morgen wieder in dem Zustand. Komischerweise ist den syslogs nach der Zeitpunkt wieder ca. 3 Uhr nachts gewesen. Zuvor scheint wohl mysql auch irgendwas gemacht zu haben.


    Hier der Ausschnitt:

    Ausgabe von netstat -nap hänge ich an.


    Kann da jemand Auffälligkeiten erkennen?


    Danke und viele Grüße
    Konni

  • vServer: seit 3 Tagen regelmäßig korrupte MySQL-Tabellen

    Zitat von sugersgroer;9339

    Hmm aufjedenfall sehr komisch


    hast denn darüber mal mit dem Support gesprochen? Vielleicht fällt denen ja noch was ein


    Mein erster Gedanke war ja ein defektes Dateisystem bzw. ein Speicherproblem. Diesbezüglich hatte ich ja den Support schon kontaktiert, der aber nichts feststellen konnte.


    Ich frage da auch nochmal nach.


    bebbo
    Wenn der Server morgen wieder abgeschmiert ist, werde ich mir die Ausgabe von netstat mal anschauen.


    Momentan läuft er wieder einwandfrei. Komischerweise schmiert er immer nur nachts / morgens ab, wenn eigentlich gar keiner drauf zugreifen sollte.


    Gruß
    Konni