Am Tue, 21 Mar 2017 23:22:48 +0200
schrieb Alan McKinnon <alan.mckin...@gmail.com>:
> On 21/03/2017 22:16, Kai Krakow wrote:
> > Test one by one... Either disable all, then enable one by one, or
> > vice-versa.
> >
> > Chances are that your FS may be blocking on sync. Do you maybe have
> > a very high value in /proc/sys/vm/dirty_background_{ratio,bytes}?
> >
> > If ratio is 0, then bytes is used. Ratio is a percent of your
> > physical RAM. With the default kernel value in modern systems, this
> > is ridiculously high for desktop systems. Maybe put a fixed value,
> > like 128MB. The dirty background value is the amount of outstanding
> > writes before a foreground process blocks on further writes. If
> > this value is high, a sync may cause processes to freeze for a long
> > time. Setting this to a lower value forces single processes to
> > block early and give the kernel a chance to write back dirty data.
> >
> > The next value to check is dirty_{ratio,bytes}. That is the combined
> > maximum of outstanding data before the cache must be flushed. If
> > this is hit, all writing processes freeze. So, having the
> > background value high gives a greater chance of hitting this early.
> >
> > The default values are 10% and 20% (ratio). I've made the 20% ratio
> > into 10% and put 128MB for background which works quite well:
> > Foreground processes are blocked for shorter times (because writing
> > 128MB can be a few seconds or less, where 1.6GB can be minutes in a
> > worse case, so if overall limit is hit, I'm screwed). The overall
> > dirty buffer is still big enough to let the system buffer writes of
> > multiple processes. My system has 16GB RAM, you may want to adjust
> > it or try different values.
> >
> > $ cat /etc/sysctl.d/98-caching.conf
> > vm.dirty_background_bytes = 134217728
> > vm.dirty_ratio = 10
> >
> > Maybe point your Firefox cache to a tmpfs. If you're using tmpfs,
> > don't put swappiness to low, otherwise data sitting in tmpfs cannot
> > be swapped out and will cause filesystem caches to be discarded to
> > early. I'm working with a 32GB tmpfs and standard swappiness for
> > emerge, and I see no problems although multiple gigabytes of emerge
> > build data may be swapped out. Still, emerge is so much faster now.
> > But then, my swaps are on different disks (and I have multiple for
> > getting some RAID-like striping of swap space).
> >
> > Also, depending on which FS you're using, trying deadline instead of
> > CFQ may greatly improve your desktop experience (browsers should
> > benefit most from this).
>
>
> You may be onto something here:
>
> This is an 8-core i7 latop, 16G RAM
>
> $ sudo cat /proc/sys/vm/dirty_background_bytes
> 0
> $ sudo cat /proc/sys/vm/dirty_background_ratio
> 5
> $ sudo cat /proc/sys/vm/dirty_bytes
> 0
> $ sudo cat /proc/sys/vm/dirty_ratio
> 10
With a 16 GB machine, I recommend to not work with the ratio values and
stick to bytes values. 1% steps is just so coarse. Put some reasonable
values there.
> browser cache is on a regular laptop spinning-rust 500G disk
Try moving the cache to tmpfs just for the sake of eliminating that...
Nowadays, /tmp is usually mounted with tmpfs (at least it should),
otherwise mount tmpfs somewhere below /mnt and make it chmod 1777. Then
create a cache directory there, rename your browser cache (while the
browser is not running) and instead put a symlink to the newly created
directory. Now do some tests without rebooting. If it works, create an
fstab entry to mount a tmpfs directly to your firefox cache directory
with correct permissions. Of course, it would be lost on reboots.
An alternative could be to put the cache on an FS with better write
performance, like NILFS2 (it does linear writes only but reading will
suffer, but reading is not that sensitive to blocking). Reiserfs can
also perform well when fsyncs are involved. But it doesn't scale well
to parallel accesses (which is not so relevant for desktop usage, and
especially as browser cache). Also, XFS always performed very well for
me (better than Ext4), for desktop and server usage. But that only
makes sense if you convert your whole system to that. And it cannot
play its benefits if used on single-disk systems.
> IO scheduler is BFQ, I use it for ages now.
Yes, good choice. I'd use it, too. But it causes troubles with btrfs
(results in system freezes with fs corruption when I run VirtualBox).
> I did tests some years back and found it overall the best for an
> interactive desktop with a DE. I haven't repeated those tests since,
> has there been significant changes in this are last year or three?
It still performance very well. The next best option for me was using
deadline. CFQ is an interactivity killer.
I'm combining this with bcache. That's a cache between kernel and
filesystem that you put on SSD. Apparently, it requires repartitioning
to map your filesystem through bcache (it has to add a protective
superblock in front of your FS). So, a small SSD + bcache can make your
complete 500GB spinning rust act mostly like SSD perfomance-wise.
I think there's a script that can move your FS 8 kB forward on HDD to
add that bcache superblock. But I wouldn't try that without backup and
some spare time. But it is a performance wonder.
Using 3x 1TB btrfs RAID + 500GB bcache here. The system feels like an
SSD system but I don't have to decide what to put on a small SSD and
what to put on big slow storage. Is just automagic. ;-)
BTW: Laptop disks are really slow usually because most manufacturers
only build them with 5400 RPM disks. Maybe get a hybrid disk instead if
you only have one slot. I think, Seagate still makes those. It should
have similar benefits like bcache.
--
Regards,
Kai
Replies to list-only preferred.
