<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, May 20, 2022 at 10:36 AM James Linder <<a href="mailto:jam@tigger.ws">jam@tigger.ws</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"><br>
<br>
> On 20 May 2022, at 4:30 am, Kenneth Emerson <<a href="mailto:kenneth.emerson@gmail.com" target="_blank">kenneth.emerson@gmail.com</a>> wrote:<br>
> <br>
> <br>
> <br>
> 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>
> On 5/19/2022 10:03 AM, Kenneth Emerson wrote:<br>
>> <br>
>> <br>
>> 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>
>> <br>
>> <br>
>> On Mon, Apr 11, 2022, 1:04 PM Kenneth Emerson <<a href="mailto:kenneth.emerson@gmail.com" target="_blank">kenneth.emerson@gmail.com</a>> wrote:<br>
>> <br>
>> <br>
>> On Mon, Apr 11, 2022, 12:53 AM Stephen Worthington <<a href="mailto:stephen_agent@jsw.gen.nz" target="_blank">stephen_agent@jsw.gen.nz</a>> wrote:<br>
>> 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" 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>
>> <br>
>> Stephen:<br>
>> 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.<br>
>> <br>
>> Ken Emerson<br>
>> <br>
>> Update:<br>
>> <br>
>> 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?<br>
>> <br>
>> Anyway, sorry for all the cruft. <br>
>> <br>
>> BTW: 681Mb in .mythtv/cache<br>
>> Will have to wait several weeks to see if the OOM kill problem is gone.<br>
>> <br>
>> Thanks for your time and help.<br>
>> <br>
>> Regards,<br>
>> Ken Emerson<br>
>> <br>
>> 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. <br>
>> <br>
>> 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.<br>
>> <br>
>> FYI: This is a dedicated frontend/backend server with no other services running other than what myth requires.<br>
>> <br>
>> 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.<br>
>> <br>
>> Regards, <br>
>> <br>
>> Ken Emerson <br>
>> <br>
>> <br>
>> _______________________________________________<br>
>> mythtv-users mailing list<br>
>> <br>
>> <a href="mailto:mythtv-users@mythtv.org" target="_blank">mythtv-users@mythtv.org</a><br>
>> <a href="http://lists.mythtv.org/mailman/listinfo/mythtv-users" rel="noreferrer" target="_blank">http://lists.mythtv.org/mailman/listinfo/mythtv-users</a><br>
>> <a href="http://wiki.mythtv.org/Mailing_List_etiquette" rel="noreferrer" target="_blank">http://wiki.mythtv.org/Mailing_List_etiquette</a><br>
>> <br>
>> MythTV Forums: <br>
>> <a href="https://forum.mythtv.org" rel="noreferrer" target="_blank">https://forum.mythtv.org</a><br>
> 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>
> <br>
> 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:<br>
> <br>
> 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>
> <br>
> 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.<br>
<br>
The trouble is when us mere mortals try to understand ,,,<br>
If you have oodles of ram and some of it is untouched (as opposed to unused) then the kernel will swap that out so that you’ve got more cache that is *touched* and there are *signicant* arguments on ram vs swap with tuning available.<br>
So you might go from<br>
<br>
4G used 4G free swap 0<br>
to<br>
2G used 6G free swap 2G<br>
<br>
eg consider these<br>
<br>
'echo 'vm.swappiness=1' > /etc/sysctl.d/99-sysctl.conf'<br>
'echo 'vm.vfs_cache_pressure=50' >> /etc/sysctl.d/99-sysctl.conf’<br>
<br>
James<br><br></blockquote><div><br></div><div>Kenneth,</div><div></div><div>please state the theme you are using (including version).</div><div>Do you use plugins from MythTV?</div><div>Is mythwelcome part of the game?</div><div>How often does the frontend restart because of an error?<br></div><div>What is the output of</div><div><span style="font-family:monospace">dpkg -l | grep -i mythtv</span></div><div><br></div><div>Roland<br></div><div><br></div><div><br></div></div></div>