[mythtv-users] best use of limited RAM

Wed Nov 22 13:57:48 UTC 2017

You are most welcome Marius!

One problem with write caching: Every filesystem worth its weight right now
(ext*, ZFS, certainly others) have a design pattern of 'buffer enough data
until next scheduled write commences'; usually this is only 5 seconds or so
worth of data before the filesystem flushes the buffers to disk in an
attempt to keep journalling metadata current, and also to preserve files
which were written, but not explicitly sync()'d following write, if
catastrophic system failure were to happen thereafter.

This timeframe is also quite often tunable.

Tuning it would perhaps allow less-frequent smaller writes to be aggregated
into larger writes, thereby perhaps allowing the SSD more data to overwrite
a block with.  Your tradeoff however, is 'how long after I write a file
without sync() am I willing to wait before I know the file is safely on
disk?'  Databases for example almost always write in sync() mode expressly
to prevent data-loss unless you tune them in bad ways ;)

There'd actually be very little, if any, benefit to keeping anything in
zram/swap vs simply allowing the 8 gigs to be used as normal.  You'd only
be saving the (very rare) swap writes if your workload does not regularly
exceed 8 gigabytes.

Setting sysctl vm.swappiness=0 would prevent most continual writes to swap,
but when swap _does_ happen, it'll be with more data at the instant it
needs to swap;

Conversely setting vm.swappiness=100 would pre-swap certain things that are
unused, which may offer a bit more ram for workload processing demands; but
the point is entirely mooted if your workload simply isn't using more than
8GB to begin with.

Mike

On Wed, Nov 22, 2017 at 8:46 AM, Marius Schrecker <marius.schrecker at lyse.net
> wrote:

>
> On Wednesday, November 22, 2017 14:35 CET, Mike Hodson <mystica at gmail.com>
> wrote:
>
>
> Dear Marius,
>
> What kind of SSD?  Sandforce, or other? Model would be most helpful.
> What kind of NAND? Single-level? Multi-Level? Three-level?(almost
> assuredly not 3-level due to size/age)
>
> Could you paste a smartctl -a /dev/sdX ?
>
> What are you attempting to cache? Reads or writes?
>
> Reads, while potentially disruptive if you read the exact same sector
> enough times, are almost certainly mitigated in the wear-leveling action of
> the disk in question.
>
> Writes never will 100% cache, unless you use something insane like XFS
> which never seems to write data until sync() is called, if enough ram is
> free.  Maybe theyve fixed that by now, but I know I've lost files I saved
> when the system (after MANY hours) subsequently hard-locked due to kernel
> weirdness with graphics drivers..
>
> I've personally done a rather large amount of SSD usage over the past
> ..when was Sandforce 1 released? Many terabytes of writes per drive and not
> a single disk has died on me, not even a tiny old 60GB one.
>
> I've also worked for companies using consumer-grade (850Evo among others)
> SSDs in enterprise webhosting scenarios. They rarely die, and almost always
> give fair warning with SMART values before-hand.   Also, have you taken a
> look at The Tech Report's "SSD Endurance Experiment" ?  its final
> conclusion is that some disks can write PETABYTES before dying.
> http://techreport.com/review/27909/the-ssd-endurance-experiment-theyre-
> all-dead
>
> For MythTV use, the MySQL database would be the only major workload as
> long as all video goes to the spinner; its definitely not anywhere near as
> bad as shoving about 10-25 virtual private servers on each disk doing
> $entity-knows what for the course of a few years. In RAID5/6 no less.
>
> Periodic /var/log/messages and similar background OS daily workload is
> negligible.
>
> As for Swap?  why would your system need swap? Disable it entirely and let
> things OOMkill themselves if something goes awry.
>
> Or be like my desktop, and set 20GB of swap for a 16GB system (effectively
> 10GB for an 8GB system) to have room to hibernate, and potentially let some
> random process chew up all 10 gigs before OOMkilling itself, and bogging
> down the system for _minutes_ before the oomkiller responds properly.
>
> I've only run into massive swap usage in 2 scenarios:
> 1, if I allow processes like Chrome to continue to spawn new tabs like
> rabbits and never close them; sooner or later the swap finally fills, and
> things OOMkill. but this is _gradual_ swapping.
>
> 2, I attempt to compile something large with -j16 as Sabayon is by default
> setup to do, if you fail to tweak the out-of-the-box make.conf ... Ugh.
>
> In almost all cases, just use the SSD as you would a normal disk; almost
> industry-wide the wear-leveling algorithms were rock-solid as of about 4
> years ago.
>
> Hope this helps, and I would love to know the SMART data as well to make
> proper predictions.
>
> Mike
>
>
> On Wed, Nov 22, 2017 at 7:41 AM, Marius Schrecker <
> marius.schrecker at lyse.net> wrote:
>>
>> Hi,
>>
>>   I am repurposing an old, box that was previously used as a combined
>> mythtv backend/frontend, Logitech Media Server and nfs fileserver as a
>> mythtv backend only.
>>
>> The system has a maximum of 8GB RAM, a quite well used 120GB SSD (no
>> signs of failure yet) and I just replaced the 3TB media storage spindle
>> drive with a new 4TB unit.
>>
>> My main concern is offloading the SSD as much as possible to prolong its
>> life.
>>
>> I have started with a base install of xubuntu, set up fstab wioth tempfs
>> for /tmp, /var/tmp and /var/spool/mqueue and installed log2ram
>> <https://github.com/azlux/log2ram> to take care of /var/log. Relatime is
>> set by default on all partitions.
>>
>> The original plan was to increase the RAM to 16GB or even 32GB for
>> maximum disk caching, but I see that my mobo doesn't support that, even if
>> the physical dimm modules are available.
>>
>>   Does the group have any suggestions for tweaking to make my 8GB go as
>> far as possible to ghelp minimise disk writes?
>>
>> I am in two minds about creating a swapfile on the spindle drive, maybe
>> with zram and keeping swappiness relatively high. Would that encourage the
>> system to increase the amount of RAM used for disk caching?
>>
>> BR.
>>
>> --Marius--
>>
>
> Thank you very much Mike. That was most helpful.
>
> I can't remember the SSD disk right now but will take a look and read out
> from smartctl this evening and let you know. I did a quick smartctl readout
> yesterday, which reported no errors.
>
> I was intending to do a firmware update on the disk, before installing the
> system, but couldn't find a firmware, so just left it as is.
>
> Regarding swap area, I'm not expectuing any swapping to take place in
> normal usage, but thought that I might be able to force more agressive
> write caching (and fewer writes), by using zswap to force silly amounts of
> available ram (compared with intended usage).
>
>   Anyway, the stats on SSD's look promising.
>
> BR.
>
> --Marius--
>
>
>
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20171122/7b8b74d9/attachment.html>