Das ist der epg2vdr vom Server und der epgd, der vermutlich auch auf dem Server läuft. Das ist nur unterschiedlich, wenn epgd auf einem eigenen Host läuft.

epg2vdr - deadlocks
-
-
Ja, der EPGD läuft auch auf diesem Server. Wieso trägt der sich in vdrs ein?
-
-
Hier aber habe ich Einträge mit derselben IP drin, von denen einer einen leeren Port hat:
ja das eine ist der epgd da wird das nicht benötigt.
Sieht alles gut aus und erklärt nicht die locks. -
die Deadlocks kommen jedenfalls aus dem EPG Handler. Du verwendest das epg2vdr 1:1 aus dem git ohne weitere Patches wie z.B. den VPS Patch?
Wie oft hast du die Deadlocks?
Hast du diese Meldungen?CodeFeb 21 09:28:44 gate vdr: epg2vdr: Got epgd state 'busy (match)' (4) Feb 21 09:29:09 gate vdr: epg2vdr: Got epgd state 'standby' (1)
Wenn ja schick mal die Letzte vor und die Erste nach so einer Deadlock Meldung, am besten den Bereich zw. den beiden.
Ich habe hier keinen einzigen Deadlock in der gesamten log Historie:
Code
Display Moreroot@gate~> ll /var/log/vdr.log* -rw-r----- 1 syslog adm 290K Feb 21 09:41 /var/log/vdr.log -rw-r----- 1 syslog adm 886K Feb 20 23:59 /var/log/vdr.log.1 -rw-r----- 1 syslog adm 65K Feb 20 00:00 /var/log/vdr.log.2.gz -rw-r----- 1 syslog adm 59K Feb 19 00:00 /var/log/vdr.log.3.gz -rw-r----- 1 syslog adm 70K Feb 17 23:59 /var/log/vdr.log.4.gz -rw-r----- 1 syslog adm 62K Feb 16 23:59 /var/log/vdr.log.5.gz -rw-r----- 1 syslog adm 55K Feb 15 23:59 /var/log/vdr.log.6.gz -rw-r----- 1 syslog adm 90K Feb 14 23:59 /var/log/vdr.log.7.gz root@gate~> zgrep -i Deadlock /var/log/vdr.log* root@gate~>
-
Ich habe mal meine (wegen VPS absichtlich) unzulässige Konfiguration mit zwei Master korrigiert. Seit dem habe ich keine Deadlocks mehr. Somit ist klar, bei mir kommen die davon und es ist kein grundsätzliches Problem. Da ich den Verdacht eh schon hatte, habe ich das auch nie als Problem gepostet. Vielleicht hilft euch die Info zur weiteren Eingrenzung in euren Systemen.
-
es steht zwar bereits im README des Plugins ich habe die Formulierung jetzt noch ein klein wenig angepasst:
CodeUpdate DVB EPG Database Master/Slave Mode (one client should be master, e.g. 24/7 Server, all others slave) - auto: Normally first VDR will be master - the master transfers the DVB events to the mariadb Server - yes: Master mode on - no: Master mode off Make sure that only one VDR will be master or you run into DB performance issues or deadlocks.
kommt aber erst mit der nächsten Version ins git.
-
Ich habe nur einen VDR mit lokaler DB
-
Mir gehts gleich wie MegaV0lt: lokaler VDR mit lokaler DB und trotzdem immer mal wieder Deadlock-Meldungen im syslog.
Stört offenbar inhaltlich nicht, aber wollte ich hier kundtun.
-
Wie oft hast du die Deadlocks?
Wie geschrieben 5x seit 5.02.
QuoteNein, hab ich nicht. Trotzdem mal hier das Drumherum um den letzten Deadlock:
Code
Display MoreFeb 20 10:05:55 server epgd[12053]: Loaded 416 images (7,280 MB), checked 8099; 0 failed to load in 1 seconds Feb 20 10:05:55 server vdr[22142]: epg2vdr: Got 8 images from database in 1 seconds (0 updates, 8 new) and created 2770 links Feb 20 10:05:55 server vdr[22142]: epg2vdr: --- EPG update finished --- Feb 20 10:05:56 server vdr[22142]: epg2vdr: SQL-Error in 'execute(stmt_execute)' - Deadlock found when trying to get loc k; 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 < ? a nd (tableid > ? or (tableid = ? and version <> ?));] Feb 20 10:06:09 server epgd[12053]: State now 'busy (scraping)' Feb 20 10:06:09 server vdr[22142]: [22178] SVDRP VDR < 192.168.1.4:42476 client connection accepted Feb 20 10:06:09 server vdr[22142]: [22178] SVDRP VDR > 192.168.1.4:42476 server created Feb 20 10:06:09 server epgd[12053]: Send 'PLUG epg2vdr STATE busy (scraping)' to '192.168.1.4:6419' Feb 20 10:06:09 server vdr[22142]: epg2vdr: Got epgd state 'busy (scraping)' (5) Feb 20 10:06:09 server vdr[22142]: epg2vdr: Change handler state to 'standby'
-
Nein, hab ich nicht. Trotzdem mal hier das Drumherum um den letzten Deadlock:
wenn du in deinem log keine Got epgd state Meldungen des epg2vdr Plugins findest ist das die Ursache für die Deadlocks.
Diese Meldungen kommen mit log level 1, also wenn du den auf 1 oder größer hast und die Meldungen ausbleiben müssen wir nur noch herausfinden warum des Plugin den Status des epgd nicht mitbekommt. -
wenn du in deinem log keine Got epgd state Meldungen des epg2vdr Plugins findest ist das die Ursache für die Deadlocks.
Diese Meldungen kommen mit log level 1, also wenn du den auf 1 oder größer hast und die Meldungen ausbleiben müssen wir nur noch herausfinden warum des Plugin den Status des epgd nicht mitbekommt.Sry, man sollte nicht so spät nachts noch Protokolle wälzen 8-<
Doch ja, ich habe die von dir genannten Meldungen gefunden.
Also alles gut.
-
Quote
Wenn ja schick mal die Letzte vor und die Erste nach so einer Deadlock Meldung, am besten den Bereich zw. den beiden.
-
Du meinst hier auch die "got epgd state" Meldungen?
Siehe Anhang. -
der Deadlock passiert im Handler (das Statement wird nur von Handler ausgeführt, der Handler ist auch (wie man im Log sieht) schon wieder 'active'. Das ist auch richtig da der epgd zwar noch 'busy' ist dies aber nur noch mit den images.
Aus deinem Log:Code#> egrep "(Got epgd state|Deadlock|handler)" server.log.txt Feb 20 10:05:52 server vdr[22142]: epg2vdr: Got epgd state 'busy (images)' (6) Feb 20 10:05:52 server vdr[22142]: epg2vdr: Change handler state to 'active' Feb 20 10:05:56 server vdr[22142]: epg2vdr: SQL-Error in 'execute(stmt_execute)' - Deadlock ... Feb 20 10:06:09 server vdr[22142]: epg2vdr: Got epgd state 'busy (scraping)' (5)
In dieser Situation hatte ich hier noch nie einen Deadlock und kann es mir erst mal nicht erklären.
CKone kennst du eine maria/mysql Server Einstellung welche das Lock Verhalten dementsprechend beeinflussen könnte? Mir fällt gerade nichts ein.
Participate now!
Don’t have an account yet? Register yourself now and be a part of our community!