<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 19, 2022 at 12:19 PM Jay Foster <<a href="mailto:jayf0ster@roadrunner.com" target="_blank">jayf0ster@roadrunner.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div>On 5/19/2022 10:03 AM, Kenneth Emerson
wrote:<br>
</div>
<blockquote type="cite">
<div dir="auto">
<div dir="auto"><br>
</div>
<div><br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Apr 11, 2022, 2:53
PM Kenneth Emerson <<a href="mailto:kenneth.emerson@gmail.com" target="_blank">kenneth.emerson@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="auto">
<div><br>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon, Apr 11,
2022, 1:04 PM Kenneth Emerson <<a href="mailto:kenneth.emerson@gmail.com" rel="noreferrer" target="_blank">kenneth.emerson@gmail.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="auto">
<div><br>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Mon,
Apr 11, 2022, 12:53 AM Stephen Worthington
<<a href="mailto:stephen_agent@jsw.gen.nz" rel="noreferrer noreferrer" target="_blank">stephen_agent@jsw.gen.nz</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Sun, 10
Apr 2022 23:00:17 -0500, you wrote:<br>
<br>
<br>
>> Stephen:<br>
><br>
><br>
><br>
>The system RAM is 8Gb. There is a 2Gb
swap space. There are about 3,000<br>
>recordings. Here is the output from
swap.sh:<br>
><br>
><br>
>ken@mythtv:~$ ./swap.sh<br>
><br>
><br>
>..............................<br>
><br>
>Overall swap used: 798096 kB<br>
><br>
><br>
>========================================<br>
><br>
>kB pid name<br>
><br>
><br>
>========================================<br>
><br>
>404072 1408 <a href="http://mythfrontend.re" rel="noreferrer noreferrer noreferrer
noreferrer" target="_blank">mythfrontend.re</a><br>
><br>
>77376 1365 xfdesktop<br>
><br>
>42080 1277 xfwm4<br>
><br>
>38504 1377 applet.py<br>
><br>
>37120 1509 blueman-tray<br>
><br>
>34504 1426 blueman-applet<br>
><br>
>15624 1131 xfce4-session<br>
><br>
>14224 1310 panel-1-whisker<br>
><br>
>12480 1321 panel-10-pulsea<br>
><br>
>12224 1317 panel-8-statusn<br>
><br>
>11536 1314 panel-6-notific<br>
><br>
>10552 1401 update-notifier<br>
><br>
>10216 1411 nm-applet<br>
><br>
>9408 1360 Thunar<br>
><br>
>9336 1282 xfsettingsd<br>
><br>
>8608 1313 panel-5-systray<br>
><br>
>8576 1318 panel-9-power-m<br>
><br>
>8528 1385 xfce4-power-man<br>
><br>
>8240 1315 panel-7-indicat<br>
><br>
>5840 1283 xfce4-panel<br>
><br>
>3280 12076 bash<br>
><br>
>3272 1382 xiccd<br>
><br>
>3032 3791 bash<br>
><br>
>2688 1123 systemd<br>
><br>
>2640 1442 polkit-gnome-au<br>
><br>
>1920 1130 pulseaudio<br>
><br>
>1224 1437 agent<br>
><br>
>504 1145 dbus-daemon<br>
><br>
>248 3784 tmux: server<br>
><br>
>240 1368 mythfrontend<br>
><br>
><br>
>ken@mythtv:~$ free -m<br>
><br>
><br>
> total used
free shared buff/cache<br>
>available<br>
>Mem: 7934 2964
202 7 4768<br>
> 4668<br>
><br>
>If it's meaningful the CPU is an Intel
i5-2500K 3.3GHz<br>
><br>
>Perhaps I am hitting some limit on
number of recordings, but I don't ever<br>
>remember there being a (soft?) limit.<br>
>The system is a bit old, but I would
hope it's powerful enough. I only use<br>
>it as a media center with only MythTv
as the main application.<br>
><br>
>Regards,<br>
><br>
>Ken Emerson<br>
<br>
With 8 Gibytes of RAM, it should be fine.
Only 3000 recordings is not<br>
a problem (I have 52880 on an 8 Gibyte
frontend/backend system). There<br>
is no fixed limit on recordings - the list
can grow as big as your<br>
system will allow, although things do slow
down a bit when you have as<br>
many as I do.<br>
<br>
It does look like the swap space is
filling up though - I would<br>
suggest increasing that to 8 Gibytes. But
it is currently using<br>
798096 kiB, which is under half full so it
is not obvious that it will<br>
run out of swap.<br>
<br>
I have my system and swap partitions on a
fast M.2 NVME SSD, which<br>
helps with swapping.<br>
<br>
The free command gives you the total RAM
and swap usage. This is my<br>
system with mythfrontend showing my
recordings list:<br>
<br>
root@mypvr:~# free -m<br>
total used
free shared buff/cache<br>
available<br>
Mem: 7902 2829
120 23 4952<br>
4752<br>
Swap: 10239 1556
8683<br>
<br>
(Sorry about the line wrapping - my email
client does that and it is<br>
not able to be turned off).<br>
<br>
So your frontend only system with only
3000 recordings should be just<br>
fine. So my best guess is that something
is triggering a bug that is<br>
causing a memory leak. But the problem
might be in another program,<br>
rather than mythfrontend. The OOM system
is known for killing the<br>
largest RAM user, when the problem program
that is suddenly using up<br>
RAM is a different program.<br>
<br>
There was one old bug that caused the
cache directory not to be<br>
cleaned up properly, and mythfrontend
would then load the cache and<br>
run out of RAM. That was fixed a while
ago, but it is possible that<br>
you still somehow have a huge cache. So
take a look at<br>
$(HOME)/.mythtv/cache and see how big it
is:<br>
<br>
root@mypvr:~# du -hcs
/home/stephen/.mythtv/cache/<br>
376M /home/stephen/.mythtv/cache/<br>
376M total<br>
<br>
This mine now, but when the bug was
happening, it was many gibytes. If<br>
yours is too large, shut down mythfrontend
and do:<br>
<br>
rm -r $(HOME)/.mythtv/cache<br>
<br>
Mythfrontend should then rebuild the cache
as required.<br>
<br>
I would suggest upgrading to v32. That is
the currently supported<br>
version, so if you have a problem that
needs the devs to fix it, you<br>
will need to be on v32 for them to be
interested. And it is vaguely<br>
possible your problem may be fixed already
in v32-fixes.<br>
<br>
</blockquote>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
</blockquote>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Stephen:</blockquote>
</div>
</div>
<div dir="auto">Unfortunately, I decided to take
the plunge and upgrade to 32. Looked simple;
however, in stuck years ago right at the
beginning running mythtv-setup with "Failed to
get schema upgrade lock". Can't go back or
forward at this point. I have a good DB backup
just don't know what to do with it.</div>
<div dir="auto"><br>
</div>
<div dir="auto">Ken Emerson</div>
</div>
</blockquote>
</div>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">Update:</div>
<div dir="auto"><br>
</div>
<div dir="auto">I changed the hostname in the setup
dialog from localhost to mythtv (the actual hostname)
and then rebooted. The master backend ran after the
reboot and asked me if I wanted to upgrade the schema;
answered yes and all I good now; upgraded from 1361 to
1376. Don't fully understand the problem. There were
no clues in the mythtv-setup log. Perhaps the backend
takes care of all that now?</div>
<div dir="auto"><br>
</div>
<div dir="auto">Anyway, sorry for all the cruft. </div>
<div dir="auto"><br>
</div>
<div dir="auto">BTW: 681Mb in .mythtv/cache</div>
<div dir="auto">Will have to wait several weeks to see
if the OOM kill problem is gone.</div>
<div dir="auto"><br>
</div>
<div dir="auto">Thanks for your time and help.</div>
<div dir="auto"><br>
</div>
<div dir="auto">Regards,</div>
<div dir="auto">Ken Emerson</div>
</div>
</blockquote>
</div>
</div>
<div dir="auto"><br>
</div>
<div dir="auto">It's been a month now, and I haven't seen a
re-occurance of the OOM killer taking out the frontend;
however, by keeping an eye out on resources I notice that
memory is still tight. I've updated myth to version 32 and
did maintenance on the cache disk space as suggested. This
morning when a OTA program was recording with no one watching
any recordings, the frontend.real task (using top) was using
the majority of resources, both cpu and memory. CPU was 47-80%
range with memory 80-90% range. Along with the frontend,
mythcommflag was also running using minimal resources as was
the backend. frontend.real was always first in listing using
top looking at both cpu and memory. </div>
<div dir="auto"><br>
</div>
<div dir="auto">Using free, there was only about 60mb memory
available (system has 8 gb installed). I don't understand what
the frontend is doing when there is nothing being played back:
just sitting at the recordings menu. I also have a 2gb swap
partition that is also more than 90% consumed.</div>
<div dir="auto"><br>
</div>
<div dir="auto">FYI: This is a dedicated frontend/backend server
with no other services running other than what myth requires.</div>
<div dir="auto"><br>
</div>
<div dir="auto">I've ordered and am now waiting for an
additional 8gb of memory but would appreciate any
enlightenment on what the frontend is busy doing.</div>
<div dir="auto"><br>
</div>
<div dir="auto">Regards, </div>
<div dir="auto"><br>
</div>
<div dir="auto">Ken Emerson </div>
<div dir="auto">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="auto">
<div dir="auto">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
mythtv-users mailing list
<a href="mailto:mythtv-users@mythtv.org" target="_blank">mythtv-users@mythtv.org</a>
<a href="http://lists.mythtv.org/mailman/listinfo/mythtv-users" target="_blank">http://lists.mythtv.org/mailman/listinfo/mythtv-users</a>
<a href="http://wiki.mythtv.org/Mailing_List_etiquette" target="_blank">http://wiki.mythtv.org/Mailing_List_etiquette</a>
MythTV Forums: <a href="https://forum.mythtv.org" target="_blank">https://forum.mythtv.org</a>
</pre>
</blockquote>
My combined FE/BE also has 8GB or RAM and has no issues (running
0.28). Something to keep in mind when looking at how much RAM is
'free' (/proc/meminfo) is that the linux kernel will use any
available RAM for caching, so the reported free RAM is usually low.
This is not indicative of a problem (i.e., memory leak).<br>
Jay<br>
</div><br></blockquote><div>Thanks for the input. The problem seems to be intermittent. I'm looking at the memory now with two programs recording (just for a test). The results from the 'free' command are:</div><br><font face="monospace"> total used free shared buff/cache available<br>Mem: 7.7Gi 6.8Gi 130Mi 5.0Mi 884Mi 752Mi<br>Swap: 2.0Gi 2.0Gi 0B<br></font><br></div><div class="gmail_quote">With the exception of the swap numbers, this seems reasonable. Maybe everything is fine. Watching the numbers it appears the kernel is doing what it's supposed to do. I still don't understand why swap is getting used. I'll see what happens when I add the addtional 8Gb of RAM next week.</div><div class="gmail_quote"><br></div><div class="gmail_quote">Regards,</div><div class="gmail_quote"><br></div><div class="gmail_quote">Ken Emerson</div></div>