epg2vdr: DB > 4,6 GB und merge-Dauer > 100 Sekunden - ist das normal?

davie2000 · Aug 14th 2020

Hallo!

Braucht die Datenbank für epg2vdr (bei mir mariadb) bei euch auch fast 5 GB?

Oder ist das was Besonderes?

Wenn ja: fehlt bei mir viell. nur eine regelmässige "automatische Bereinigung"?

Ich habe bei der Größe nämlich Schwierigkeiten gute Einstellungen für die my.cnf zu finden,

da der PC insgesamt nur über 4 GB RAM verfügt und epgd & co NICHT alleine dort laufen.

Code: Auszug MySQLTuner script

[--] Database: epg2vdr
[--] +-- TABLE: 31
[--] +-- COLL : 1 (utf8_general_ci, NULL)
[--] +-- ROWS : 731850
[--] +-- DATA : 4.3G(93.80%)
[--] +-- INDEX: 294.6M(6.20%)
[--] +-- TOTAL: 4.6G
[--] +-- ENGIN : 1 (InnoDB, NULL)
[OK] 1 collation for epg2vdr database.
[OK] 1 engine for epg2vdr database.
[--] Physical Memory : 3.8G
[--] Max MySQL memory : 5.1G

Display More

Fourty2 · Aug 15th 2020

Also hier:

du

6994180 ./epg2vdr

Normal, denke ich, mit einigen TB Aufnahmen und 14 Tage EPG...

Stefan

davie2000 · Aug 15th 2020

Ok, das beruhigt schon mal etwas.

Danke für deine Rückmeldung!

Dann spiel ich mal weiter mit den Settings rum - bin schon ein Stück weiter ...

wmautner · Aug 15th 2020

Habe auch

du -sh epg2vdr

5,0G epg2vdr

Viele SAT-Sender, dazu Kabel (haben aber kürzere EPG-Vorlaufzeiten).

Mysqltuner empfiehlt mir auch immer, die innodb_buffer_pool_size zu erhöhen, aber der vdr selbst braucht auch noch Speicher

Wobei ich noch andere DBs im Mariadb-Ordner habe (amarok, digikam, mediathekview, gerbera).

Ist also kein Unglück, aber das Brett ASRock H61M-GE hat 4 DDR3-Slots, da geht sicher noch was rein, und DDR3 bleibt nach Umstellung auf die neuen DDR4-Boards eh jedem übrig ...

utiltiy · Aug 15th 2020

Meiner läuft schon ein paar Tage....

Code

12G /var/lib/mysql/epg2vdr

Fourty2 · Aug 15th 2020

davie2000 wrote:

Ok, das beruhigt schon mal etwas.

Danke für deine Rückmeldung!

Dann spiel ich mal weiter mit den Settings rum - bin schon ein Stück weiter ...

Habe das hier auf einem 1 GB BPi (mit SATA-Platte) stabil laufen.

Falls Dein Kernel das unterstützt: ZRAM verwenden.

Einstellung:

- ZRAM = 150% des RAMs, auf < 42% im RAM beschränkt,

- mit ZRAM-BACKING_DEV (=alte SWAP Partition)

(dann per Cron ein Script laufen lassen, das (länger) Idle-Pages auslagert)

Mit der beiliegenden Konfig bleibt das ganze unter 750 MB. Die Datenbank paßt eh nicht in den RAM.

Wenn noch Platz ist, die Werte nach Bedarf erhöhen. Den MySQL-Tuner kann man für unsere Zwecke vergessen, wenn man nicht 32 GB RAM in der Büchse hat.

davie2000 · Aug 15th 2020

Wow - vielen Dank für eure vielen Rückmeldungen!

Dann bin ich bzgl. der DB-Größe jetzt mal wirklich beruhigt und werde mich noch weiter am Feintuning der 50-server.cnf versuchen.

Die aktuellen RAM-Preise schaue ich mir auch an

Und ZRAM kannte ich noch gar nicht, musste dabei aber stark an die RAM- und Festplatten-"Verdoppler" Ende der 90er-Jahre denken.

davie2000 · Aug 23rd 2020

Nach dem - sehr schnell gelösten - Speicherfress-Problem diese Woche, konnte ich meine mariadb mal ein paar Tage laufen lassen.

Die Empfehlungen vom mysql-optimizer-Skript sind jetzt etwas zuverlässiger und die DB läuft jetzt mit weniger RAM-Verbrauch, aber gleich stabil (und langsam?) wie vorher.

Daher jetzt noch eine Frage in die Runde:

Sind solche Merge-Durchlaufzeiten normal bzw. dauert das bei euch auch so lange?

Und vor allem: warum läuft merge alle paar Minuten???

Code

Aug 23 00:34:25 localhost epgd: 567 DVB pending, mergeepg done after 109.085 seconds
...
Aug 23 00:37:22 localhost epgd: 710 DVB pending, mergeepg done after 111.159 seconds
...
Aug 23 00:41:50 localhost epgd: 1780 DVB pending, mergeepg done after 108.728 seconds...
Aug 23 00:55:37 localhost epgd: 742 DVB pending, mergeepg done after 109.684 seconds

wmautner · Aug 23rd 2020

Wie oft epg-merge laufen soll, ist in der epgd.conf zu bestimmen mittels des "UpdateThreshold" - Parameters.

Ich habe den mittlerweile auf 9000 gestellt.

Code

grep "mergeepg done" syslog
Aug 23 02:01:47 hdvdr2 epgd: 9127 DVB pending, mergeepg done after 25.368 seconds
Aug 23 06:15:11 hdvdr2 epgd: 9031 DVB pending, mergeepg done after 19.253 seconds
Aug 23 07:54:49 hdvdr2 epgd: 9049 DVB pending, mergeepg done after 13.116 seconds
Aug 23 09:50:39 hdvdr2 epgd: 9004 DVB pending, mergeepg done after 18.659 seconds

Die DB liegt bei mir auf SSD, möglicherweise macht das die bessere Geschwindigkeit aus. Sie ist aber hier auch 5GB groß.

davie2000 · Aug 23rd 2020

Danke für eine rasche Antwort!

Der Update-Treshold steht bei mir tatsächlich auf '500' - daher das merge alle paar Minuten. Das sollte ich wohl erhöhen ...

Die DB liegt bei mir (seit ca. 1 Jahr) auch auf SSD, und braucht trotzdem so lange.

Bei mir liegt die DB in /var/lib/mysql, was eindeutig auf der SSD "wohnt.

Code: Auszug von /var/lib/mysql$ ls -l

-rw-rw---- 1 mysql mysql 549453824 Aug 23 11:59 ibdata1
-rw-rw---- 1 mysql mysql 201326592 Aug 23 11:59 ib_logfile0
-rw-rw---- 1 mysql mysql 201326592 Aug 23 11:59 ib_logfile1

Code: df /var/lib/mysql

Dateisystem 1K-Blöcke Benutzt Verfügbar Verw% Eingehängt auf
/dev/sdb1 101617656 20330176 76082540 22% /

Was kann da bei mir sonst noch "falsch" laufen?

wmautner · Aug 23rd 2020

Ich hab meine 50-server.cnf ziemlich lange optimiert mit mysqltuner.pl und tuning-primer.sh.

Allerdings braucht die auch recht viel vom Speicher:

Code

join_buffer_size = 3M
innodb_buffer_pool_size = 5G
innodb_buffer_pool_instances = 5
innodb_log_file_size = 550M
key_buffer_size = 14M
max_allowed_packet = 14M
thread_stack = 192K
thread_cache_size = 4
query_cache_type = 0
query_cache_size = 0
query_cache_limit = 0
tmp_table_size = 512M
max_heap_table_size = 512M
read_rnd_buffer_size = 4M
sort_buffer_size = 10M
aria-pagecache-buffer-size = 18M
innodb_flush_log_at_trx_commit = 1

Display More

Wenn weniger RAM (ich habe 12G gesamt) vorhanden ist, sollte buffer_pool_size und _instances verringert werden (1GB/Instance) und auch die _log_file_size kann verkleinert werden, etwa im selben Verhältnis.

davie2000 · Aug 23rd 2020

Ist das der gesamte Inhalt deiner 50-server.cnf?

Ich werde dann mal die Werte mit meinen vergleichen.

Da ich insgesamt nur 4GB (bzw. 3,8GB) RAM habe, gibts bei mir nur 2 Instanzen:

Code

### by davie2000 - performance optimization
# besser 1G bis max. 1,33 GB
innodb_buffer_pool_size = 2G
# besser 192M, weil es zwei gibt u 360 MB reichen für > 1h
innodb_log_file_size = 192M
innodb_buffer_pool_instances = 2
### end davie2000

Wodurch der max. RAM-Footprint der DB bei ca. 2,8 GB liegt und somit noch mind. 1 GB für den "restlichen VDR" bleibt.

minixjr · Aug 23rd 2020

Ich vermute mal auch die Anzahl der Sender spielt eine Rolle.

Code

mysql -D epg2vdr -u epg2vdr -pepg -e "SELECT COUNT(DISTINCT channelid)AS Anzahl_Sender FROM channelmap"
+---------------+
| Anzahl_Sender |
+---------------+
| 88 |
+---------------+

Code

grep "mergeepg done" /var/log/syslog
Aug 23 04:33:50 vdrserver epgd: 707 DVB pending, mergeepg done after 41.434 seconds
Aug 23 04:44:55 vdrserver epgd: 4736 DVB pending, mergeepg done after 34.839 seconds
Aug 23 04:48:44 vdrserver epgd: 775 DVB pending, mergeepg done after 34.751 seconds
Aug 23 04:54:35 vdrserver epgd: 761 DVB pending, mergeepg done after 33.227 seconds

davie2000 · Aug 23rd 2020

Danke für den sehr guten Punkt - das spielt sicher eine (große) Rolle.

Bei mir sind es 186 Sender. Mehr als doppelt so viele; könnte die "Verdoppelung" der Durchlaufzeit viell. erklären.

Edit:

Das Hochdrehen des Thresholds auf 5000 führt erfreulicherweise dazu, dass merge deutlich seltener läuft, dafür

aber nicht wesentlich länger braucht als vorher alle drei Minuten:

Code

Aug 23 12:21:07 localhost epgd: 658 DVB pending, mergeepg done after 110.088 seconds
Aug 23 12:50:33 localhost epgd: 5108 DVB pending, mergeepg done after 113.456 seconds

wmautner · Aug 23rd 2020

Bei mir sind es 218 Sender, da ich viele über dvb-c und dvb-S empfange und daher doppelt in der Liste habe. Zudem hab ich mir mal die Arbeit gemacht, sowohl dvb-S als auch dvb-S2 (HD) einzutragen, um Ausweichmöglichkeiten zu haben (schlechter Empfang bei Selfsat und Regenwetter z.B.).

Die anderen Einträge in der 50-server.cnf sind eigentlich Standard.

minixjr · Aug 23rd 2020

Dann scheint die Anzahl der Sender aber nicht der springende Punkt zu sein.

Welche Provider nutzt Ihr?

Ich nutze (Prio in dieser Reihenfolge):

epgdata
tvm
tvsp

davie2000 · Aug 23rd 2020

Ich hab mal zu wmautner's Settings (von oben) meine dazu gestellt;
dort wo DEFAULT steht, habe ich keinen Eintrag in meiner /etc/mysql/mariadb.conf.d/50-server.cnf und die aktuellen Werte aus 'variables' ausgelesen.

Code

MEINE_WERTE
join_buffer_size = 3M 4M
innodb_buffer_pool_size = 5G 2G
innodb_buffer_pool_instances = 5 2
innodb_log_file_size = 550M 192M
key_buffer_size = 14M 4M
max_allowed_packet = 14M 16M
thread_stack = 192K 192K
thread_cache_size = 4 8
query_cache_type = 0 DEFAULT: ON
query_cache_size = 0 32M
query_cache_limit = 0 1M
tmp_table_size = 512M 32M
max_heap_table_size = 512M 32M
read_rnd_buffer_size = 4M DEFAULT: 262144
sort_buffer_size = 10M DEFAULT: 2097152
aria-pagecache-buffer-size = 18M DEFAULT: 134217728
innodb_flush_log_at_trx_commit = 1 DEFAULT: 1
BEI MIR NOCH ZUSÄTZLICH:
skip_name_resolve
max_connections = 25
table_open_cache = 256
performance_schema = 1
slow_query_log = 1
slow_query_log_file = /var/log/mysql/mariadb-slow.log
long_query_time = 1
log-queries-not-using-indexes = 1
log_slow_admin_statements = 1
expire_logs_days = 10
max_binlog_size = 100M
character-set-server = utf8mb4
collation-server = utf8mb4_general_ci
[mariadb]
optimizer_search_depth = 0

Display More

wmautner Dein Parameter 'aria-pagecache-buffer-size' dürfte nicht ziehen, weil er (zumindest bei mir) so heißt: 'aria_pagecache_buffer_size'

Die auffälligsten Unterschiede sind,

dein "key_buffer" ist fast 4 mal so groß als meiner (14 vs 4 MB)
mein "thread_cache" ist doppelt so groß
dass ich offenbar den "query_cache" nutze und du nicht => wie ist das bei den anderen mit gutem Speed?
deine "max_heap" und "tmp_table" viel, viel größer sind - bei mir dzt. (noch) nicht möglich
dein "read_rnd_buffer" ist 20 mal größer (4M zu 250K), dein "sort_buffer" 5 mal so groß (10MB zu 2 MB)
mein "aria-pagecache" ist > 7 mal größer als deiner (132 MB zu 18MB)

=> Fallen jemand bei meinen Einstellungen irgendwelche Ungereimtheiten bzw. Erklärungen für die Langsamkeit auf?

zB Werte die eigentlich gleich sein müssen und bei mir unterschiedlich sind oder umgekehrt

Dass deine DB komplett im RAM schneller ist als meine ist klar, aber ist RAM wirklich 2-3 mal schneller als SSD?

=> Was haben denn die anderen hier so für merge-Zeiten?

Ich nutze übrigens tvm und tvsp - kein epgdata.

wmautner · Aug 23rd 2020

Ich verwende auch tvm/tvsp, und mein mysql muß auch noch gerbera, amarok, digikam, mediathekview versorgen.

Möglicherweise hat das auch eine Rolle gespielt bei der Bemessung der Parameter.

Query_cache ist deprecated und wurde bei mir von epgd überhaupt nicht genutzt, der war immer nahezu leer.

Liebe Grüße aus Wien

utiltiy · Aug 25th 2020

davie2000 wrote:

=> Was haben denn die anderen hier so für merge-Zeiten?

Zwischen 4 und 9 Sekunden

Code

mysql -D epg2vdr -u epg2vdr -pepg -e "SELECT COUNT(DISTINCT channelid)AS Anzahl_Sender FROM channelmap"
+---------------+
| Anzahl_Sender |
+---------------+
| 139 |
+---------------+

davie2000 · Aug 25th 2020

utiltiy wrote:

Zwischen 4 und 9 Sekunden

Zumindest in die Nähe davon, würd ich auch gerne kommen wollen ...

epg2vdr: DB > 4,6 GB und merge-Dauer > 100 Sekunden - ist das normal?

Share

Similar Threads

[EPGd] Zeilenumbruch bei <actors> in der Quelle von tvsp

Ztw. kein Bild nach Umschalten mit VDR ab Version 2.3.9

epgd/mysql Verständnisfrage

[epgd/epg2vdr] Daenbank wächst mit der Zeit

[epgd] nach Update auf mariadb 10.2.15 -> Felddefinitionen werden bei jedem Start angemault

Blockaden durch epg2vdr (oder scraper2vdr)

Tags

Share

Similar Threads

[EPGd] Zeilenumbruch bei <actors> in der Quelle von tvsp

Ztw. kein Bild nach Umschalten mit VDR ab Version 2.3.9

epgd/mysql Verständnisfrage

[epgd/epg2vdr] Daenbank wächst mit der Zeit

[epgd] nach Update auf mariadb 10.2.15 -> Felddefinitionen werden bei *jedem* Start angemault

Blockaden durch epg2vdr (oder scraper2vdr)

Tags

[epgd] nach Update auf mariadb 10.2.15 -> Felddefinitionen werden bei jedem Start angemault