Die Message hat doch absolut nichts zu sagen, außerdem wird das Statement ja 3 Sekunden später ausgeführt.
[gelöst] epg2vdr: SQL-Error in 'execute(stmt_execute)' - Deadlock found when trying to get lock ...
-
-
Einen Deadlock mit "Die Message hat doch absolut nichts zu sagen" ist jetzt etwas grob verharmlosend.
Mal für die Interessierten eine kurze und vereinfachte Erklärung was ein Deadlock bedeutet:
Der Thread 1 holt sich einen exklusiven Lock auf die Tabelle A, weil er darauf schreiben will
Der Thread 2 holt sich einen exklusiven Lock auf die Tabelle B, wer er darauf schreiben will
Jetzt will der Thread 1 sich einen Lock auf die Tabelle B holen, weil er davon lesen will. Er muss aber warten, bis Thread 2 seinen Lock released hat.
Der Thread 2 denkt aber gar nicht daran den Lock zu releasen, will seinerseits einen Lock auf Tabelle A und hängt, weil Thread 1 ja schon einen Lock darauf hat.
Deadlock! Tot, weil normalerweise jetzt beide Threads bis in alle Ewigkeiten hängen würden. Allerdings erkennt die Datenbank-Engine das, und schickt eine Fehlermeldung.
Jetzt kann der Programmierer z.B. in den Threads unterschiedlich lange warten und es dann nochmal versuchen. Das scheint wohl hier die Vorgehensweise zu sein.Ich kenne mich mit MySQL nicht sehr aus, aber bei richtigen Datenbanken macht man das anders. Statt implizite Locks durch die Datenbank-Zugriffe zu machen, lockt man durch das Starten einer Transaktion mit expliziten Locks.
Thread 1 versucht Tabelle A und B zu locken und schafft das, weil keiner die Tabellen gelockt hat.
Thread 2 versucht ebenfalls Tabelle A und B zu locken, hängt aber weil Thread 1 die Tabellen gelockt hat.
Das ist aber kein Deadlock, weil Thread 1 ja weitermachen kann und die Locks released. Dann kann auch Thread 2 die Locks bekommen.So, jetzt habe ich euch genug gelangweilt.
Gerald
-
der Deadlock bei dem im ersten Post genannten Statement ist, solange er selten auftritt aus fachlichen (nicht technischen) Gründen relativ unkritisch.
Hintergrund, wenn der epgd 'arbeitet' teilt er dies den VDRs mit damit diese die Arbeit im EPG Handler (das speisen der DB mit EPG Updates) solange aussetzen und es nicht zu diesen 'deadlocks' kommt. Hier kann es in sehr seltenen Fällen zu einer Überschneidung beim timing und einem damit verbundenen Deadlock kommen. Bei mir tritt das 0-4 Mal im Monat auf, meist 0 Mal ;).
Unkritisch da die EPG Updates permanent erneut'einfliegen' und somit beim nächsten Mal - sofern in der Tabelle nicht aktuell - übernommen werden.Tritte es mehrmals täglich oder sogar mehrmals in einer Stunde auf ist es ein Zeichen dass in der epgd / epg2vdr Kommunikation etwas klemmt - dann sollte man das recherchieren.
Grüße
Jörg -
der Deadlock bei dem im ersten Post genannten Statement ist, solange er selten auftritt aus fachlichen (nicht technischen) Gründen relativ unkritisch.
Zwischen den Zeilen meines Posts hatte ich ja schon angedeutet, dass sowas durchaus in Ordnung sein "kann", was du ja jetzt bestätigt hast.Nur einen Schönheitspreis gewinnt das nicht ;).
Gerald
-
Nur einen Schönheitspreis gewinnt das nicht .
da stimme ich zu
das erweiterte SVDRP Interface des VDR 2.3.2 verbessert oder löst das vermutlich. Muss den epgd nur noch dort hin portieren (leider wie immer abwärts kompatibel)
-
Der nicht 24/7 VDR ist auch der bei dem der EPG handler aktiv ist?
Kannst du bitte das Ergebnis vonCodeegrep "deadlock|handler state" /var/log/syslog
(Pfad ggf. anpassen) posten wenn du einen deadlock hattest.Jörg
-
Also das Positive zuerst:
Seit heute morgen (Aufwachen VDR) kein einziger Deadlock mehr *freu*
(Viell. hat da das gestrige Update schon geholfen???)Jetzt zu deinen Fragen/Empfehlungen:
Der nicht 24/7 VDR ist auch der bei dem der EPG handler aktiv ist?
Hmmmm ... ich habe nur einen einzigen yaVDR (siehe Signatur) und der läuft nicht 24/7 durch, sondern geht immer mal wieder in den Ruhezustand (S3, glaub ich).
Auf diesem PC läuft auch der epgd und die Datenbank.Hier noch das Ergebnis von egrep "deadlock|handler state" /var/log/syslog.1 vom gestrigen syslog VOR dem Update (der heutige ist ja "sauber")
Danke, Jörg, für deine Bemühungen!
-
Pro Nachricht sind "nur" 100.000 Zeichen erlaubt, darum antworte ich mir selbst
Witzbold! Mit solchen Logs bläst man das VDR-Portal ja auch nicht auf, sondern bringt sie z.B. nach https://paste.ubuntu.com/ und verlinkt dahin.Gerald
-
-
das ist die relevante Stelle:
CodeFeb 27 20:32:38 myVDR vdr: epg2vdr: Change handler state to 'active' Feb 27 20:32:57 myVDR vdr: epg2vdr: SQL-Error in 'execute(stmt_execute)' - Deadlock found when trying to get lock; try restarting transaction (1213) 'Deadlock found when trying to get lock; try restarting transaction' [update events set delflg = ?, updflg = ?, updsp = ? where channelid = ? and source = ? and starttime+duration > ? and starttime < ? and (tableid > ? or (tableid = ? and version <> ?));] Feb 27 20:33:02 myVDR vdr: epg2vdr: SQL-Error in 'execute(stmt_execute)' - Deadlock found when trying to get lock; try restarting transaction (1213) 'Deadlock found when trying to get lock; try restarting transaction' [update events set delflg = ?, updflg = ?, updsp = ? where channelid = ? and source = ? and starttime+duration > ? and starttime < ? and (tableid > ? or (tableid = ? and version <> ?));] Feb 27 20:33:06 myVDR vdr: epg2vdr: Change handler state to 'standby'
der Handler wird erst aktiviert wenn der epgd mit seinem Job fertig ist, nur wer erzeugt dann den Deadlock :o.
Hier bitte nochmal mit dem erweiterten grep:Codeegrep "deadlock|handler state|epgd: State now" /var/log/syslog
es genügen wenige Zeilen um den Deadlock herum!Wie viele Tuner hat dein VDR?
Jörg
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!