So last week I added some music files to my B3 and told LMS to rescan the folder and index these new files and the whole interface froze. I opened a console session and found mysql (I reconfigured LMS to use that rather than sqlite) running at almost 100% CPU. So apparently it was still doing something, but why did the interface become unresponsive? After a long while the page suddenly refreshed and stated that my media files were scanned and sure enough the new music files were listed in the index. So it wasn't broken, but it was terribly slow.
So what happened here? Running top I could see that I had some 100M in swap and 300M "cached". And then it hit me. I already knew that Microsoft servers are configured to favor file system cache, but I never realized that Linux does the same! And so there I have a bunch of services trying to claim memory, but the system only had 200M to grant and that was all already assigned. This is not how I want the system to behave. File system cache is important, but not as important as the services that I use to gain access to those files.
The solution appears to be in the vm settings and specifically vm.swappiness which controls the tendency of the kernel to swap out applications to enlarge the cache. The default value for this is 60 and by lowering it you can tell it to be less aggressive in this or even not do it at all. Opinions vary and I've seen suggestions of entering 0, 1 and 10. I'm okay with some amount of swapping and I chose 20 for now:
A second change I made was to vm.vfs_cache_pressure which controls the tendency of the kernel to reclaim memory from inode/directory caching. From the object of performance the usual advice is to lower this value from its default 100 to 50, which makes the system try to keep inode cache entries longer. Because the object in my case is to save memory for applications I did the opposite and raised it to 200:
Code: Select all
sysctl -w vm.vfs_cache_pressure=200
To instantly free the cache and start fresh with the new settings, run:
Code: Select all
sync
echo 3 > /proc/sys/vm/drop_caches
You'll be able to verify with top that cache was freed and you now have a significant amount of memory free. I ran a new music scan today and there's no more freezing with any of the services; not with LMS itself but other web based frontends also keep responding in an acceptable amount of time. So far I'm thus quite happy with this little hack.
Tips, hints, comments on this are most welcome.