Posts by nvertigo

    Ja, binary logging war das Problem: "skip-bin-log" schaltet das binary logging in mariadb ab. "#bin-log" (also einfach auskommentieren) läßt binary-logging aktiv. Besonders gemein: das schlägt nur bei einem epgd first run auf die leere db zu - deshalb habe ich es mit der geupdateten db zuerst nicht gemerkt. (Siehe EDIT in ursprünglicher Nachricht.)


    Das plugin_dir mußte ich angeben, als ich versehentlich die alte epgd Version gebaut habe (Änderungen gefetched, aber nicht ausgechecked...).


    So, aus den vdr plugins ist nichts mehr gegen libmysqlclient gelinkt:


    Code
    1. ingo@adler /usr/local/src/VDR $ ldd /usr/lib64/vdr/plugins/libvdr-* |grep -e mariadb -e mysql
    2. libmariadb.so.3 => /usr/lib64/libmariadb.so.3 (0x00007fb04e308000)
    3. libmariadb.so.3 => /usr/lib64/libmariadb.so.3 (0x00007fa0ccba8000)
    4. ingo@adler /usr/local/src/VDR $

    Scheint alles gut zu laufen. Danke horchi !


    EDIT:

    Nachdem ich die Abhängigkeiten zu libmysqlclient los war, habe ich (für andere Pakete) libmysqlclient auf 8.x geupdated. Ich habe auf meinem System also

    Code
    1. /usr/include/mariadb/mysql.h
    2. /usr/include/mysql/mysql.h

    Um sicher zu stellen, dass /usr/include/mariadb/mysql.h und nicht /usr/include/mysql/mysql.h inkludiert wird, benötige ich noch

    Das fiel mir nur auf, weil nach dem libmysqlclient-Update, der my_bool Fehler hoch poppte - solange ich die alte libmysqlclient-Version (5.x oder 6.x) hatte fiel das gar nicht auf.


    Ich denke, dass man das include konditional (je nachdem, ob mysql oder mariadb benutzt wird) gesetzt werden muss.


    Herzlichen Dank für Deine Arbeit an den Quellen und Deinen Support.

    Ich habe jetzt mit ganz neuen /var/lib/mysql angefanden, um den innodb Fehler weg zubekommen. Und mit "epgd-tool -new-db && epgd-tool -new-u" alles neu erzeugt. Leider geht jetzt gar nichts mehr: der epgd loopt beim start mit:


    Was übersehe ich? :(


    EDIT: binary logging wird mit skip-bin-log ausgeschaltet - und nicht durch auskommentieren von bin-log.

    Ich mußte bei meiner Distro (gentoo) noch


    Code
    1. plugin_dir = /usr/lib64/mysql/plugin

    für mysqlepglv.so setzen.


    Bei "mysql_update" und "mariadb-update" bekomme ich


    Code
    1. Error : Unknown column 'information_schema.INNODB_METRICS.STATUS' in 'field list' Error : View 'sys.metrics' references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them

    Kann das bleiben? Kann man das fixen? Besser mariadb neu einrichten (ohne update von bestehenden mysql dbs)? Oder benötige ich eines oder mehrere useflags aus innodb-lz4, innodb-lzo oder innodb-snappy?

    sehe ich mir im laufe des Tages an.

    Frohes neues und gesundes Jahr für alle.


    Mit "dringend" meinte ich eher sowas wie "vordringlich" oder "wichtig" - ich meinte nicht "sofort". War vieleicht etwas ungenau ausgedrückt. Lass' Dir Zeit und beginne Dein Jahr entspannt - Hauptsache, Ihr habt's auf der Todo-Liste.


    SQL
    1. SELECT relaxed FROM "new_year";

    ;)

    wenn euch noch was auffällt meldet euch.

    Wunschliste:

    • fix für merging mit vdr-2.6.0 ("epg2vdr: Updated changes since ..." erscheint 4x nach vdr start, danach nie wieder - der letzte log-Eintrag ist auch das letzte merge im epgd - scheint mit dvb-epg merging zusammen zu hängen.
    • update für mysql c connector (aka libmysqlclient) auf MySQL 8.0 C API (auch für mysql 5.x empfohlen; siehe: https://dev.mysql.com/downloads/c-api/). libmysqlclient-8.x scheint zwar zu laufen, aber nur wenn die db mit 5.x initialisiert wurde, bei einem epgd first run auf eine leere, neu angelegte epg2vdr db crasht der epgd.
    • update für mysql-8.x. Autoupdate auf bestehende epg2vdr db schlägt genauso fehl, wie das Neuanlegen der epg2vdr db.

    Ich würde sagen der erste Punkt ist dringend, da der fix die Voraussetzung ist, epgd überhaupt mit vdr 2.6.0 (oder 2.5.x) nutzen zu können.


    Der zweite Punkt ist semi-dringend, da ältere libmysqlclient versionen upstream nicht mehr gepflegt werden und von einigen Distris nicht mehr angeboten werden.


    Der dritte Punkt wird dringend, wenn die ersten Distros anfangen, mysql-5.x nicht mehr anzubieten.

    Den aktuellen Stand habe ich ins GIT (git.tvdr.de) eingespielt.

    Ich verwende den delete-d patch erfolgreich mit 2.4.7. Da 2.4.x der stable branch ist, der auch von vielen Distributionen verwendet wird, wäre eine Version 2.4.8 im git vieleicht hilfreich für Paket-Pfleger.

    Ich hoffe, HelmutB ist da schon auf der richtigen Spur.

    Die Hoffnung habe ich nach diesem Test ( Speicherleck im VDR oder einem Plugin ) aufgegeben.


    Wenn es nicht zwei unabhängige leaks sind, sollten wir im Hinterkopf behalten, dass der "epg scan off" Effekt nicht direkt das Leak behebt, sondern das tunen verhindert (welches dann eben nicht mehr das leak triggered). Deshalb würde ein Test mit "Umschaltscript" insofern neue Erkenntnisse bringen, als dass wir hinterher wissen, ob der epg scan direkt das leak beeinflusst, oder nur indirekt, wegen weniger tunings.


    Wie war das eigentlich bei Dir: meine vdr Installation lief Jahre lang ohne dieses massive leak, und es trat auf, ohne dass ich die vdr installation verändert habe (keine vdr und/oder plugin updates, in der Zeit, als das leak auftrat) , sondern "nur" normale distro updates durchgeführt habe.

    Hat vielleicht die Anzahl an DVB Geräten, oder deren System einen Einfluss auf das Speicherleck?


    Ich habe 6x DVB-C per USB angebunden. Bei mir sind es ca 180 MB / 24h.

    Möglich. Ich habe je nach Benutzung auch bis zu knapp 200MB/Tag gesehen. Da mehr devices meist auch mehr Aufnahmen (also Kanalwechsel bzw. tunings) bedeuten, halte ich zumindest einen indirekten Effekt für wahrscheinlich.


    Hast Du mal den epg scan abgeschaltet? behebt das bei Dir das Leak?

    Auf beiden Servern laufen Aufnahmen, auf dem Testserver natürlich deutlich weniger. Bei mir kann man wohl eindeutig eine Abhängigkeit zum EPG Scan erkennen.

    Hast Du mal ein "Umschaltescript" laufen lassen? Bei mir bringt das Abschalten des epg scans nichts: bei mir hängts an der Benutzung: viel zappen -> großes leak - wenig zappen -> kleines Leak. Vieleicht sind es aber auch einfach unterschoedliche Leaks. Der "Trick" mit eit- und nit-Filterabschalten hilft bei mir ja auch nicht.

    Oder das laek verhält sich auf headless Installationen anders, als eine mit Ausgabe-Plugin umd interaktiver Nutzung.

    Hier die ersten Erkenntnis ohne EIT: der Speicherverbrauch steigt ziemlich konstant um ~700 KiB/Std.

    Wenn aber zusätzlich auch der NIT-Filter deaktiviert wird, ändert sich die Speicherbelegung nur wärend des ersten Tranponderscans, in den darauffolgenden 1,5 Stunden habe ich keine Steigerung mehr beobachtet.

    Ich werde mir daher nit.c etwas genauer ansehen.

    Im Anhang die Logs mit den Ausgaben von "top".

    Ich habe gestern den vdr mit

    übersetzt.


    Zuerst sah das auch gut aus. In den ersten Stunden gab der vdr sogar 'mal 70KB wieder frei. Aber nachdem ich gestern Abend etwas gezappt habe, gings wieder los - und heute morgen habe ich verglichen mit dem Speicherverbrauch der ersten Stunden wieder 110 MB verloren. Sorry.

    Echt jetzt ? Hat mir einer Windows untergeschoben ???


    Code
    1. Server3:~$ free -m
    2. gesamt belegt frei gemeinsam Zwischen verfügbar
    3. Speicher: 31777 5296 473 48 26006 25975
    4. Auslager: 8191 4938 325

    Hm, das ist merkwürdig. Ich habe nur 16 GB und geswappt hat die Maschine vorhin, als ich ein paar updates übersetzt habe (bei gut der Hälfte Speichernutzung, also etwa 60%). Einmal ausgswappt werden die pages natürlich nur zurückgeholt, wenn sie auch wieder benötigt werden.


    Code
    1. free -m
    2. total used free shared buff/cache available
    3. Mem: 16028 3973 1926 11 10128 11284
    4. Swap: 32565 191 32374

    Keine Ahnung, ob bei Deiner Maschine was falsch läuft, oder ob es einfach eine Situation gab, als sie mehr Auslastung hatte, ausgelagert hat und die Pages einfach noch nicht wieder gebraucht hat.


    Das geht jetzt jedenfalls in Richtung off topic und hat nichts mehr mit dem Ursprünglichen Thread-Thema zu tun.