Speicherverbrauch steigt mit der Zeit

MegaV0lt · Jun 3rd 2020

Mir ist schon vor langer Zeit aufgefallen, dass der VDR (oder ein Plugin) Speicher verbraucht. Beim Start ligt der VDR noch bei 12% und steigt dann stetig an, bis sogar der Swap verwendet wird. Meistens nach 5 oder 6 Stunden.

Hier mal 30 Minuten. ps_mem.py wird alle 10 Minuten gestartet:

Display Spoiler

Code

20-06-03 11:37 - ./checkmem.sh Start
Private + Shared = RAM used Program
144.0 KiB + 22.5 KiB = 166.5 KiB init
148.0 KiB + 46.5 KiB = 194.5 KiB logger
196.0 KiB + 25.5 KiB = 221.5 KiB acpid
192.0 KiB + 30.5 KiB = 222.5 KiB cron
288.0 KiB + 91.5 KiB = 379.5 KiB irexec
284.0 KiB + 100.5 KiB = 384.5 KiB rpcbind
348.0 KiB + 55.5 KiB = 403.5 KiB grep
308.0 KiB + 125.5 KiB = 433.5 KiB nalu_stat.sh
288.0 KiB + 160.0 KiB = 448.0 KiB sftp-server (2)
340.0 KiB + 111.5 KiB = 451.5 KiB xwatch.sh
340.0 KiB + 112.5 KiB = 452.5 KiB rec_not_complet
348.0 KiB + 109.5 KiB = 457.5 KiB gg_startapp.sh
252.0 KiB + 216.5 KiB = 468.5 KiB xinit
364.0 KiB + 110.5 KiB = 474.5 KiB g2v_netmount.sh
368.0 KiB + 106.5 KiB = 474.5 KiB gg_g2vgui.sh
364.0 KiB + 111.5 KiB = 475.5 KiB check_df.sh
368.0 KiB + 110.5 KiB = 478.5 KiB vdsb.sh
392.0 KiB + 108.5 KiB = 500.5 KiB g2v_automount.s
344.0 KiB + 179.5 KiB = 523.5 KiB runvdr
332.0 KiB + 200.0 KiB = 532.0 KiB sleep (4)
432.0 KiB + 109.5 KiB = 541.5 KiB lircd
340.0 KiB + 277.5 KiB = 617.5 KiB unclutter
596.0 KiB + 38.5 KiB = 634.5 KiB rpc.idmapd
652.0 KiB + 21.5 KiB = 673.5 KiB dhcpcd
576.0 KiB + 105.5 KiB = 681.5 KiB dbus-daemon
644.0 KiB + 151.5 KiB = 795.5 KiB chronyd
760.0 KiB + 108.5 KiB = 868.5 KiB rpc.statd
664.0 KiB + 262.0 KiB = 926.0 KiB su (2)
872.0 KiB + 237.0 KiB = 1.1 MiB agetty (6)
1.0 MiB + 490.5 KiB = 1.5 MiB ratpoison
1.2 MiB + 1.0 MiB = 2.2 MiB console-kit-daemon
2.4 MiB + 43.5 KiB = 2.4 MiB udevd
2.0 MiB + 822.5 KiB = 2.8 MiB nmbd
2.1 MiB + 991.5 KiB = 3.1 MiB bash (7)
2.6 MiB + 1.0 MiB = 3.6 MiB screen-4.6.1 (6)
2.5 MiB + 1.4 MiB = 3.9 MiB syslog-ng (2)
2.6 MiB + 2.1 MiB = 4.7 MiB sshd (4)
9.2 MiB + 1.2 MiB = 10.4 MiB epghttpd
6.5 MiB + 4.9 MiB = 11.3 MiB smbd (4)
10.3 MiB + 1.1 MiB = 11.5 MiB fail2ban-server
14.9 MiB + 1.3 MiB = 16.2 MiB polkitd
15.2 MiB + 1.4 MiB = 16.6 MiB epgd
43.1 MiB + 6.8 MiB = 49.9 MiB Xorg
73.0 MiB + 5.7 MiB = 78.8 MiB markad (2)
282.3 MiB + 994.5 KiB = 283.3 MiB mysqld
378.1 MiB + 98.5 KiB = 378.1 MiB vdradmind
440.4 MiB + 10.8 MiB = 451.2 MiB vdr
---------------------------------
1.3 GiB
=================================
Private + Shared = RAM used Program
144.0 KiB + 21.5 KiB = 165.5 KiB init
148.0 KiB + 44.5 KiB = 192.5 KiB logger
196.0 KiB + 25.5 KiB = 221.5 KiB acpid
192.0 KiB + 29.5 KiB = 221.5 KiB cron
288.0 KiB + 91.5 KiB = 379.5 KiB irexec
284.0 KiB + 99.5 KiB = 383.5 KiB rpcbind
348.0 KiB + 52.5 KiB = 400.5 KiB grep
308.0 KiB + 117.5 KiB = 425.5 KiB nalu_stat.sh
288.0 KiB + 158.0 KiB = 446.0 KiB sftp-server (2)
340.0 KiB + 106.5 KiB = 446.5 KiB rec_not_complet
340.0 KiB + 106.5 KiB = 446.5 KiB xwatch.sh
348.0 KiB + 104.5 KiB = 452.5 KiB gg_startapp.sh
368.0 KiB + 99.5 KiB = 467.5 KiB gg_g2vgui.sh
252.0 KiB + 216.5 KiB = 468.5 KiB xinit
364.0 KiB + 105.5 KiB = 469.5 KiB check_df.sh
364.0 KiB + 106.5 KiB = 470.5 KiB g2v_netmount.sh
368.0 KiB + 104.5 KiB = 472.5 KiB vdsb.sh
400.0 KiB + 102.5 KiB = 502.5 KiB g2v_automount.s
344.0 KiB + 173.5 KiB = 517.5 KiB runvdr
332.0 KiB + 194.0 KiB = 526.0 KiB sleep (4)
432.0 KiB + 108.5 KiB = 540.5 KiB lircd
340.0 KiB + 276.5 KiB = 616.5 KiB unclutter
596.0 KiB + 37.5 KiB = 633.5 KiB rpc.idmapd
652.0 KiB + 20.5 KiB = 672.5 KiB dhcpcd
576.0 KiB + 105.5 KiB = 681.5 KiB dbus-daemon
636.0 KiB + 150.5 KiB = 786.5 KiB chronyd
760.0 KiB + 108.5 KiB = 868.5 KiB rpc.statd
664.0 KiB + 256.0 KiB = 920.0 KiB su (2)
872.0 KiB + 231.0 KiB = 1.1 MiB agetty (6)
1.0 MiB + 487.5 KiB = 1.5 MiB ratpoison
1.2 MiB + 985.5 KiB = 2.1 MiB console-kit-daemon
2.4 MiB + 42.5 KiB = 2.4 MiB udevd
2.0 MiB + 820.5 KiB = 2.8 MiB nmbd
2.6 MiB + 962.0 KiB = 3.6 MiB screen-4.6.1 (6)
2.4 MiB + 1.3 MiB = 3.7 MiB syslog-ng (2)
2.5 MiB + 1.2 MiB = 3.7 MiB bash (8)
2.6 MiB + 2.0 MiB = 4.6 MiB sshd (4)
4.3 MiB + 690.5 KiB = 4.9 MiB mc
9.2 MiB + 1.2 MiB = 10.4 MiB epghttpd
6.5 MiB + 4.9 MiB = 11.3 MiB smbd (4)
10.3 MiB + 1.1 MiB = 11.5 MiB fail2ban-server
14.9 MiB + 1.2 MiB = 16.1 MiB polkitd
15.2 MiB + 1.4 MiB = 16.5 MiB epgd
43.1 MiB + 6.8 MiB = 49.9 MiB Xorg
84.7 MiB + 5.7 MiB = 90.4 MiB markad (2)
282.5 MiB + 989.5 KiB = 283.5 MiB mysqld
378.1 MiB + 95.5 KiB = 378.1 MiB vdradmind
449.1 MiB + 10.7 MiB = 459.8 MiB vdr
---------------------------------
1.3 GiB
=================================
Private + Shared = RAM used Program
144.0 KiB + 22.5 KiB = 166.5 KiB init
148.0 KiB + 48.5 KiB = 196.5 KiB logger
196.0 KiB + 26.5 KiB = 222.5 KiB acpid
192.0 KiB + 30.5 KiB = 222.5 KiB cron
288.0 KiB + 92.5 KiB = 380.5 KiB irexec
284.0 KiB + 101.5 KiB = 385.5 KiB rpcbind
348.0 KiB + 57.5 KiB = 405.5 KiB grep
340.0 KiB + 109.5 KiB = 449.5 KiB xwatch.sh
324.0 KiB + 127.5 KiB = 451.5 KiB nalu_stat.sh
292.0 KiB + 160.0 KiB = 452.0 KiB sftp-server (2)
340.0 KiB + 114.5 KiB = 454.5 KiB rec_not_complet
348.0 KiB + 111.5 KiB = 459.5 KiB gg_startapp.sh
252.0 KiB + 217.5 KiB = 469.5 KiB xinit
364.0 KiB + 108.5 KiB = 472.5 KiB check_df.sh
368.0 KiB + 106.5 KiB = 474.5 KiB gg_g2vgui.sh
364.0 KiB + 113.5 KiB = 477.5 KiB g2v_netmount.sh
368.0 KiB + 112.5 KiB = 480.5 KiB vdsb.sh
412.0 KiB + 109.5 KiB = 521.5 KiB g2v_automount.s
344.0 KiB + 181.5 KiB = 525.5 KiB runvdr
432.0 KiB + 111.5 KiB = 543.5 KiB lircd
336.0 KiB + 219.0 KiB = 555.0 KiB sleep (4)
340.0 KiB + 277.5 KiB = 617.5 KiB unclutter
596.0 KiB + 38.5 KiB = 634.5 KiB rpc.idmapd
652.0 KiB + 21.5 KiB = 673.5 KiB dhcpcd
580.0 KiB + 106.5 KiB = 686.5 KiB dbus-daemon
644.0 KiB + 166.5 KiB = 810.5 KiB chronyd
760.0 KiB + 109.5 KiB = 869.5 KiB rpc.statd
664.0 KiB + 263.0 KiB = 927.0 KiB su (2)
872.0 KiB + 239.0 KiB = 1.1 MiB agetty (6)
1.0 MiB + 497.5 KiB = 1.5 MiB ratpoison
1.2 MiB + 1.0 MiB = 2.2 MiB console-kit-daemon
2.2 MiB + 43.5 KiB = 2.3 MiB udevd
2.0 MiB + 823.5 KiB = 2.8 MiB nmbd
2.1 MiB + 995.5 KiB = 3.1 MiB bash (7)
2.6 MiB + 1.0 MiB = 3.6 MiB screen-4.6.1 (6)
2.4 MiB + 1.4 MiB = 3.8 MiB syslog-ng (2)
2.6 MiB + 2.1 MiB = 4.7 MiB sshd (4)
9.2 MiB + 1.2 MiB = 10.4 MiB epghttpd
6.5 MiB + 4.9 MiB = 11.3 MiB smbd (4)
10.3 MiB + 1.1 MiB = 11.5 MiB fail2ban-server
14.9 MiB + 1.3 MiB = 16.2 MiB polkitd
15.2 MiB + 1.4 MiB = 16.6 MiB epgd
46.7 MiB + 1.4 MiB = 48.0 MiB markad
43.0 MiB + 6.9 MiB = 49.9 MiB Xorg
282.7 MiB + 1.0 MiB = 283.7 MiB mysqld
378.1 MiB + 102.5 KiB = 378.2 MiB vdradmind
450.8 MiB + 11.1 MiB = 461.9 MiB vdr
---------------------------------
1.3 GiB
=================================

Display More

Wie kommt man dem Verursacher auf die Spur. Hab keine Programmierkenntnisse...
Ich vermute eventuel markad, da sich der Verbrauch erhöht hat, seit dem Update auf die kfb77-Version. War aber vorher auch schon...

kls · Jun 3rd 2020

Ich beobachte auch schon seit einiger Zeit einen stetig ansteigenden Speicherbedarf, allerdings "nur" in der Größenordnung von ca. 100MB pro Woche (wenn der VDR 24/7 läuft). Ich hatte in Version 2.3.5 mal was in der Richtung gefixt:

- Fixed a memory leak in cSectionSyncerHash. The cSectionSyncerEntry objects put into

the hash were never explicitly deleted. Now the cSectionSyncerHash takes ownership of

these objects.

aber anscheinend war das noch nicht alles. Wenn bei dir bereits nach einigen Stunden der Speicher aufgebraucht ist, hat das vermutlich eine andere Ursache.

So ein Speicherleck mit 100MB/Woche zu finden ist mühsam, daher bin ich dem bisher noch nicht nachgegangen...

M-Reimer · Jun 3rd 2020

Etwas ähnliches hatte ich halt auch mit tvheadend. 100 MB pro Woche ist gefühlsmäßig sicher erstmal nicht viel aber wenn man sowas auf einem Raspberry fahren will dann sind 4GB RAM halt in endlicher Zeit voll. Man kann den VDR über systemd bei Überschreiten einer Speichergrenze hart restarten lassen, aber dann läuft man Gefahr eine Aufnahme zu killen.

Ärgerlich für mich vor allem weil das eigentlich mein Hauptgrund war um von tvheadend auf VDR zu wechseln. Ich möchte einfach einen kleinen Mini-Server der wenig Strom braucht und einfach TV-Programm ins Haus-LAN streamt. Mit tvheadend wird das nix, denn da tut sich deutlich weniger wie aktuell im Bereich VDR.

Gibt es nicht Hilfstools die "verlorenen" Speicher erkennen und die Stelle wo der verloren gegangen ist melden?

Edit: https://www.cprogramming.com/debugging/valgrind.html

Ich erinnere mich aber das für irgendwas schonmal genutzt zu haben und der Erfolg war begrenzt.

Argus · Jun 3rd 2020

Johns hatte doch einige Jahre lang versucht, das Speicherleck in Softhddevice zu stopfen. Rofafor hatte dann 2017 dieses in seinem pesintta's github repo gefixt. Kann es sein, das es in den anderen Derivaten immer noch umherdümpelt?

(valgrind hatte damals auch nichts gefunden)

kfb77 · Jun 3rd 2020

MegaV0lt wrote:

Ich vermute eventuel markad, da sich der Verbrauch erhöht hat, seit dem Update auf die kfb77-Version. War aber vorher auch schon...

Nichts ist unmöglich, aber eher unwahrscheinlich, da das Plugin fast nichts macht, sondern nur im VDR Recording Event Händler hängt und wenn da was ankommt, markad startet. markad wird für jede Aufnahme neu gestartet und somit räumt spätestens am Ende der Bearbeitung das Betriebssystem den Speicher vollständig auf.

Ich habe (bis jetzt) am Plugin fast nichts geändert, sondern nur ein paar zusätzliche Parameter eingebaut. Die eigentliche Funktion ist ja außerhalb dem Plugin.

Entferne doch zum Test einfach mal den Link /etc/vdr/conf.d/50-markad.conf, dann wird nach einem Neustart des VDRs das Plugin nicht mit gestartet. Interessant wäre, ob dann der Memory Leak immer noch da ist.

Unter contrib im Source Code liegt ein Script, mit dem man markad auf vorhandene Aufnahmen starten kann ohne das Plugin.

MegaV0lt · Jun 3rd 2020

kls wrote:

... in der Größenordnung von ca. 100MB pro Woche

Das kann man vernachlässigen. Bei mir läuft der VDR nur bei Aufnahmen und wenn ich was schaue. In der Regel abends so 6 Stunden. Und da im Skinflatplus der Speicherverbrauch angezeigt wird, ist mir das aufgefallen. Aber letztens wurde dann sogar geswapped...

Ich vermute dass es eher ein Plugin ist, oder was ganz anderes wie z.B vdradmind oder MySql...

Die meisten werden das kaum bemerken, weil der VDR nur zum Schauen kurz läuft, oder mehr als 4GB verbaut sind. Woche 4GB ja eigentlich dicker reichen sollten

lnj · Jun 3rd 2020

There is a decrease in free memory with cuvid, with softhddevice, softhdcuvid, mpv. With vdpau did not notice, vaapi did not tested.

I think this is ffmpeg problem.

This is clearly visible if you have no more than 2 GB of RAM.

MegaV0lt · Jun 3rd 2020

Ich verwende VDPAU. Daran liegt es dann wohl nicht.

Wäre halt schön, wenn man erst mal raus finden könnte, wo (bei welchem Plugin) man ansetzen muss...

MegaV0lt · Jun 3rd 2020

Würde es sich lohnen so ein Tool mal zu testen?
https://github.com/WuBingzheng/libleak

Ich bin gerade nicht da und kann nichts machen...

Oder wie ist es damit:

https://unix.stackexchange.com…leak-of-a-running-process

Erste Antwort

M-Reimer · Jun 3rd 2020

Ein Versuch ist letztlich nie verkehrt. Schaut beides gut aus. Kenne ich beides nicht. Wäre aber für beide interessiert wie so deine Erfahrung damit ist.

Wegen des 100MB-Problems muss ich dann wohl selber mal schauen. So grob überschlagen ist das deutlich weniger als TVHeadend bei mir "gefressen" hat und vielleicht habe ich ja auch das Glück das das Problem gar nicht auftritt wenn der VDR keine Ausgabe macht. Bei mir soll der eigentlich nämlich tatsächlich 24/7 als reiner Server laufen. Wenn es aber "nur" 100MB pro Woche sind ist durchaus möglich das in der Zwischenzeit sowieso geplante Reboots fällig werden wegen Sicherheitsupdates.

davie2000 · Jun 3rd 2020

Wie kann ich denn den Speicherverbrauch vom VDR sinnvoll und dauerhaft (über Stunden, Tage) monitoren?

Bzw. wie ist dir der steigende Verbrauch aufgefallen?

Ich verwende zwar nur das alte softhddevice openglosd für ffmpeg 2.8, aber interessieren würds mich (und euch evtl.) auch.

Aus den Zahlenwerten von ganz oben werd ich nicht schlau: der VDR verbraucht knapp unter 500 MB (leicht schwankend) und markad - das du erwähnst - braucht sogar weniger im Laufe der Zeit (von ca. 100 MB auf ca. 50MB im letzten Log). Oder sind die Logs von unten nach oben chronologisch zu lesen?

Edit:

Bei mir scheint der mysqld am meisten zu brauchen (eh klar, is ja auch so eingestellt) - VDR braucht so um die 550 MB:

Code

ps -e -orss=,args= | sort -rn | pr -TW$COLUMNS
1641220 /usr/sbin/mysqld
569920 /usr/bin/vdr
47708 /usr/lib/xorg/Xorg -noreset vt7
...

Der Rest ist (einzeln betrachtet) vernachlässigbar.

Ich nehm den Timeout mal raus und werde den Wert vom VDR beobachten ...

rkp · Jun 3rd 2020

Wow, das ist ja eine Menge Speicherverbrauch. Hier:

Code

root@ubuntuwz:~# ps -e -orss=,args= | sort -rn | pr -TW$COLUMNS
243456 /usr/sbin/mysqld
171200 /usr/bin/vdr
92252 /lib/systemd/systemd-journald
63300 /usr/lib/xorg/Xorg -noreset vt7
...

kls · Jun 3rd 2020

davie2000 wrote:

Wie kann ich denn den Speicherverbrauch vom VDR sinnvoll und dauerhaft (über Stunden, Tage) monitoren?

Bzw. wie ist dir der steigende Verbrauch aufgefallen?

Ich mache das mit rrdtool. Die Daten hole ich mit

/usr/bin/top -b -n 1 | grep -w vdr | head -1

und nehme davon die Felder 4 und 5.

Damit bekomme ich dann sowas:

kfb77 · Jun 3rd 2020

davie2000 wrote:

markad - das du erwähnst - braucht sogar weniger im Laufe der Zeit (von ca. 100 MB auf ca. 50MB im letzten Log)

markad verbraucht nur Speicher, wenn es gerade eine Aufnahme bearbeitet. Wieviel, hängt stark vom Codec der Aufnahme und ob es gerade versucht ein Logo in der Aufnahme zu finden. Dabei kann es auch kurzzeitig noch viel mehr sein. Auf jeden Fall wird am Ende der Bearbeitung das Programm beendet und vom Betriebssystem vollständig aus dem Speicher geworfen. markad läuft als eigenes Programm im eigenen Speicherbereich und kann nicht den Speicherverbrauch vom VDR erhöhen.

Die libvdr-markad.so (also das Plugin, das markad startet) hat nur die Funktion markad zu starten und eine Konfigurationsoberfläche. Ich bin gerade dabei den Code zu prüfen. Da dauert noch, bei fremdem Code muss man sich zuerst zurechtfinden, aber auf den ersten Blick habe ich da schon ein paar memory leaks in der Konfigurationsoberfläche gefunden. Das sind nur ein paar kBytes und nur, wenn man an der Konfiguration was ändert. Kann nicht die Ursache für o.g. Leaks sein, aber schön ist das nicht. Ich werde mich drum kümmern.

kfb77 · Jun 3rd 2020

kls

Kann es sein, dass Speicher für Konfigurationsmenue Punkte, die über z.B. "new cMenuEditBoolItem" erzeugt werden, vom VDR selbst beim Schießen des Menues wieder freigegeben werden ? Ich kann keine Stelle finden, wo ich das wieder freigeben könnte.

davie2000 · Jun 3rd 2020

rkp wrote:

Wow, das ist ja eine Menge Speicherverbrauch.

Ja stimmt, jetzt wo ich deinen lese. mysqld ist egal, das ist absichtlich so eingestellt (cache).
Aber dass mein VDR doppelt soviel RAM braucht wie deiner? Aber vermutlich schwankt das so stark, dass man das nicht vergleichen kann.

kls wrote:

Ich mache das mit rrdtool. Die Daten hole ich mit
/usr/bin/top -b -n 1 | grep -w vdr | head -1 ...

Danke dafür! rrdtool muss ich mir noch anschauen. Jetzt gerade sinds sogar schon über 600 MB!

/usr/bin/top -b -n 1 | grep -w vdr | head -1

1901 vdr 20 0 3122020 629452 61916 S 12,5 15,6 14:54.95 vdr
Scheint (in dem kurzen Beobachtungszeitraum) tatsächlich zu steigen.

Interessant bzw. komisch ist, dass der Befehl zwar meist den VDR ausspuckt, oft aber auch was anderes???

Code

/usr/bin/top -b -n 1 | grep -w vdr | head -1
1901 vdr 20 0 3122020 626808 59272 S 6,2 15,6 15:02.89 vdr
/usr/bin/top -b -n 1 | grep -w vdr | head -1
1121 root 20 0 149676 10504 5412 S 0,0 0,3 0:00.08 vdr-update-moni
/usr/bin/top -b -n 1 | grep -w vdr | head -1
1121 root 20 0 149676 10504 5412 S 0,0 0,3 0:00.08 vdr-update-moni
/usr/bin/top -b -n 1 | grep -w vdr | head -1
1905 vdr 20 0 1121628 12776 8744 S 6,2 0,3 3:09.68 pulseaudio
/usr/bin/top -b -n 1 | grep -w vdr | head -1
1121 root 20 0 149676 10504 5412 S 0,0 0,3 0:00.08 vdr-update-moni
/usr/bin/top -b -n 1 | grep -w vdr | head -1
1901 vdr 20 0 3122020 626820 59272 S 12,5 15,6 15:04.36 vdr

Display More

Ist das normal?

Und Klaus: du lässt den Befehl vermutlich alle paar Minuten in eine Datei ausgeben (anhängen) und wertest diese dann mit dem Tool aus, richtig?

Oder filterst du die Nicht-VDR Prozesse (siehe oberhalb) dann vorher aus?

kfb77 wrote:

markad verbraucht nur Speicher, wenn es gerade eine Aufnahme bearbeitet. ...

Danke für die ausführliche Antwort! Wieder was gelernt.

kls · Jun 3rd 2020

kfb77 wrote:

Kann es sein, dass Speicher für Konfigurationsmenue Punkte, die über z.B. "new cMenuEditBoolItem" erzeugt werden, vom VDR selbst beim Schießen des Menues wieder freigegeben werden ?

Alle Menü-Items werden beim Schließen des Menüs über cListBase::~cListBase() gelöscht.

kfb77 · Jun 3rd 2020

kls

danke, dann habe ich zumindest mal an der Stelle kein Leak

davie2000 · Jun 3rd 2020

Sorry, aber ich muss nochmal fragen: die 600 MB vom VDR - da sind aber auch alle Plugins miteingerechnet, oder?
Ich denke da zB an skindesigner oder epg2vdr, die ich wirklich sehr viel cachen lasse.

rkp : kann es sein, dass du nur sehr wenige Plugins laufen hast bzw. diese sehr speicherfreundlich eingestellt hast?

kls · Jun 3rd 2020

davie2000 wrote:

Und Klaus: du lässt den Befehl vermutlich alle paar Minuten in eine Datei ausgeben (anhängen) und wertest diese dann mit dem Tool aus, richtig?

Oder filterst du die Nicht-VDR Prozesse (siehe oberhalb) dann vorher aus?

Bei mir gibt es keinen User namens 'vdr', daher liefert mir die angegebene Zeile nur den Prozess des laufenden VDRs.

Genau genommen müsste man grep wohl noch etwas genauer formulieren.

Der Aufruf erfolgt alle 5 Minuten über rrdtool.

Hier das gesamte Script um die Daten zu erzeugen (wird mit "vdr" als Parameter aufgerufen):

Perl

#!/usr/bin/perl
$Virt = "U";
$Res = "U";
sub MB
{
my $s = shift;
if ($s =~ s/g$//) { $s *= 1000; }
elsif ($s =~ s/m$//) { }
else { $s /= 1000; }
return $s;
}
if ($ARGV[0]) {
$s = `/usr/bin/top -b -n 1 | grep -w $ARGV[0] | head -1`;
chomp($s);
if ($s) {
$s =~ s/^ *//;
@a = split(/ +/, $s);
$Virt = MB($a[4]);
$Res = MB($a[5]);
}
}
print "$Virt\n$Res\n";

Display More

Share