(I’ll just mention here first, that the telnet test was flawed. For some reason I can’t connect to the http port on the Volumio Pi itself, even though the web UI works. This is irrelevant for the purpose of this post, though.)
I added a cifs mount and started scanning. Saw a surprising amount of memory pressure with 65M of swap. It does appear to be enough, though:
Every 1.0s: free -m Wed Sep 7 13:28:25 2016
total used free shared buffers cached
Mem: 482 473 9 32 30 314
-/+ buffers/cache: 128 353
Swap: 63 40 23
(watch -n 1 free -m)
Node seems to be quite the memory hog but the kernel is able to keep some free memory and most of the used memory is for cache anyway. Or maybe Node has some memory management of its own? I really dunno.
Then I saw that a bunch of my albums were missing, and remembered that cifs doesn’t allow album directory names like “A Brief History of Rhyme: MC Hawking’s Greatest Hits” so I deleted all the user data, rebooted and configured it with nfs4.
This time around I actually measured things.
45 seconds to a login prompt over hdmi and at about 2:15 I got the startup chime and at about 2:30 the browser responded. This was repeated almost to the second with 128MB of swap! Let’s see more below:
The numbers from watch -n1 free -m while updating the library with 65MB of swap:
Every 1.0s: free -m Wed Sep 7 13:58:08 2016
total used free shared buffers cached
Mem: 482 477 4 14 4 368
-/+ buffers/cache: 105 377
Swap: 63 52 11
Now that the library is scanned and I’m listening to music, those statistics are essentially unchanged.
And with 128MB and listening, which should be quite the same:
volumio@volumio:~$ free -m
total used free shared buffers cached
Mem: 482 475 6 4 69 247
-/+ buffers/cache: 158 323
Swap: 127 0 127
It would appear the kernel is more averse to swapping if there’s more of it!
So the next step was to go back to 65MB and set vm.swappiness = 40.
I did this by creating the file /etc/sysctl.d/10-swappiness.conf:
volumio@volumio:~$ cat /etc/sysctl.d/10-swappiness.conf
vm.swappiness = 40
Statistics during play:
Every 1.0s: free -m Wed Sep 7 14:41:33 2016
total used free shared buffers cached
Mem: 482 471 10 4 70 242
-/+ buffers/cache: 158 323
Swap: 63 0 63
During updating the library:
Every 1.0s: free -m Wed Sep 7 15:03:10 2016
total used free shared buffers cached
Mem: 482 472 10 26 3 301
-/+ buffers/cache: 167 314
Swap: 63 2 61
Sure, I’m listening to music while I’m doing this, but it isn’t a perfect experiment yet. Having said that, I believe that a smaller swap size would have the following advantages:
[list=]If there’s something wrong with the overlay fs, it’ll actually fit on the file system![/list]
[list=]Because swap is the kernel’s last refuge, on slow i/o, for running out of memory, its use should be discouraged[/list]
There seems to be no disadvantage so far, as most of the memory goes to caches and even large flacs play well.
Looking at the dpkg -l list there’s very little I’d consider redundant 
My favorite solution would be to go full appliance, like OpenELEC, but that’s quite a lot of effort and therefore infeasible.
For some reason the image I built myself shows the overlay filesystem as 1.6G big with only 78M used. This makes very little sense as only /usr/ reports 399MB for its size!
Why would it suddenly be different and report so little used space? Is there something in the flashing process that can affect the overlay filesystem’s size?
Would you consider dropping the swap file size and vm.swappiness?
Thanks a lot, love the new Volumio!
and telnet is not enabled in volumio…
