Timeout für mysql-Statements (Datenbanken und Verzeichnisdienste)

[thread]15887[/thread]

Timeout für mysql-Statements

Readers: 23

Articles: hide open all | hide show old branches

+6 replies
pq

2011-01-25 12:20

User since
2003-08-04
12209 articles
Admin1

Ich habe ein Problem mit einem Script, das alle 5 Minuten mit DBI ein select auf eine bestimmte Tabelle macht. Es wird von munin gestartet.

Das Problem tritt auf, wenn mysql z.b. Tabellen checken muss (das passiert zwar nur, wenn der Rechner nicht ordentlich runtergefahren wird, das wiederum passiert hier aufgrund der Stromleitungen häufiger).
Die Tabellen sind sehr gross (auch die, die ich im Script auslesen will), so dass sehr lange gecheckt wird.
Bis dahin muss das Statement aus meinem Script warten. Da es alle 5 Minuten aufgerufen wird, sammeln sich so jede Menge wartende Statements an, und es scheint so, als ob die Scripte irgendwann abgebrochen werden von munin, aber die Statements selber sind noch da und füllen anscheinend auch die Liste der offenen Connections, und irgendwann ist die maximale Anzahl der Connections erreicht.

So, lange Rede, kurzer Sinn:
Ich frage mich, ob es irgendeine Methode gibt, das Statement per Script abzubrechen. Das einzige, was mir momentan noch einfällt, wäre, per "show processlist" vorher nachzusehen und dieses Statement vorher zu killen, bevor ich ein neues starte.
Schön wäre aber, wenn ich einfach sagen könnte, wenn das Script stirbt (z.b. mittels alarm()), soll auch das Statement mitgekillt werden, das ich abgesetzt habe.

Habe mehrere alarm()-Varianten aus der DBI-Doku ausprobiert (und mittels eines LOCK TABLE simuliert), die aber alle nicht das Statement beenden.

Mein nächster Workaround wird sein, ein Lockfile anzulegen, das nicht freigegeben wird, wenn das Script stirbt, so dass der nächste Prozess erst gar keine Datenbankverbindung startet. Aber schön finde ich das irgendwie nicht. Scheint irgendwie nicht anders lösbar zu sein, aber vielleicht hat ja jemand Erfahrung damit und eine Idee.

edit: typos
Last edited: 2011-01-25 12:22:05 +0100 (CET)
Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
- pq
  
  2011-01-25 13:41
  User since
  2003-08-04
  12209 articles
  Admin1
  als alternativen workaround habe ich jetzt im irc einen vorschlag bekommen:
  ich hole mir zuerst die connection id, und benutze das alarm mit POSIX::SigSet/POSIX::SigAction aus der DBI-doku (normales alarm funktioniert hier nicht).
  
  im alarm-handler mache ich eine neue db-verbindung auf und kille die connection id.
  
  Code (perl): (dl )
  
  1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27
  
  use POSIX ":signal_h"; my $mask = POSIX::SigSet->new( SIGALRM ); my $dbh = ...; my ($t) = $dbh->selectrow_array("SELECT CONNECTION_ID()"); my $sth = $dbh->prepare("mein select"); my $action = POSIX::SigAction->new( sub { my $dbh = ...; my $foo = $dbh->prepare("kill ?"); $foo->execute($t); die "connection ($t) timeout"; }, $mask, ); my $oldaction = POSIX::SigAction->new(); sigaction( SIGALRM, $action, $oldaction ); eval { alarm 5; $sth->execute(...); alarm 0; }; alarm 0; sigaction( SIGALRM, $oldaction ); if ($@) { ... }
  
  edit: perl-code hinzugefügt
  
  edit: "ALRM" in SIGALRM umgewandelt, ist in perldoc DBI falsch dokumentiert!
  Last edited: 2011-02-01 14:58:21 +0100 (CET)
  Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
  lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
- +4 replies
- pktm
  
  2011-01-25 14:18
  
  User since
  2003-08-07
  2921 articles
  BenutzerIn
  
  Wie man das per Skript macht, weiß ich auch nicht, Aber ich habe neulich gehört, dass man in der Datenbank einstellen kann, dass solche Statements gesondert geloggt und behandelt werden können. So könnte man die z.B. per zeitlichem Grenzwert einfach abschießen.
  http://www.intergastro-service.de (mein erstes CMS :) )
  - +3 replies
  - pq
    
    2011-02-01 14:33
    
    User since
    2003-08-04
    12209 articles
    Admin1
    
    2011-01-25T13:18:36 pktm
    Aber ich habe neulich gehört
    
    das ist noch nicht sehr hilfreich... =)
    Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
    lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem
    - +2 replies
    - vifo
      
      2011-03-08 20:07
      
      User since
      2010-01-25
      11 articles
      BenutzerIn
      
      Hey pq,
      
      ich nehme an, es ist MySQL (wg. CONNECTION_ID()). Wenn nicht, bitte um Korrektur.
      
      Ich vermute, dass hier ein Lock-Timeout auftritt (e.g. der Perl-Prozess wartet auf eine Antwort von MySQL, MySQL wartet auf einen Lock der Tabellen, da diese gerade repariert/optimiert werden). Handling von Deadlocks und Timeouts ist hier diskutiert:
      
      http://forums.mysql.com/read.php?39,28504,28504#ms...
      
      Generell gibt es hierzu keine gescheite Methode. Mit InnoDB ist es zumindest möglich, einen Lock-Timeout einzustellen. So würde das Perl-Skript eine Fehlermeldung kriegen, wenn die Tabelle nach einer bestimmten Zeit immer noch gelockt ist.
      
      http://dev.mysql.com/doc/refman/5.0/en/innodb-para...
      
      Falls dies mit den POSIX Signals funzt, super. Falls nicht, kannst Du ggf. im Skript prüfen, ob gerade ein REPAIR/OPTIMIZE auf der in Frage kommenden Tabelle läuft.
      
      Oder als Non-Perl Workaround: Kompletter REPAIR/OPTIMIZE TABLE Lauf beim Startup der MySQL DB (und ein Load abhängiger Lauf von OPTIMIZE TABLE alle paar Stunden, falls der Server wieder seinen Geist aufgibt). USV ist natürlich auch eine Idee (die Du wahrscheinlich aber nicht hören willst :))
      
      Was pktm meint ist wahrscheinlich mk-kill:
      
      http://www.maatkit.org/doc/mk-kill.html
      
      Eine wirklich schöne Lösung ist das aber auch nicht.
      
      Grüße
      ViFo
      Last edited: 2011-03-08 20:17:02 +0100 (CET)
      - pq
        
        2011-03-08 21:06
        
        User since
        2003-08-04
        12209 articles
        Admin1
        
        es ist mysql (hatte ich ja in den titel geschrieben und im posting erwähnt).
        
        USV ist grossartig, ich hab hier nur leider den fall, dass die USV selber abraucht bzw. nicht lange genug durchhält. kann ich leider nix dran machen.
        
        aber mein skript oben funktioniert ganz gut. hübsch ist es freilich nicht.
        sind leider MyISAM-tabellen, weshalb ich den lock-timeout nicht verwenden kann.
        Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. -- Damian Conway in "Perl Best Practices"
        lesen: Wie frage ich & perlintro brian's Leitfaden für jedes Perl-Problem

View all threads created 2011-01-25 12:20.