4

I am having problems where my various disks slow down from transfer rates of about 25 MB/s to about 0.3 MB/s. Sometimes a reboot works, but not necessarily for long. I had this with Ubuntu Mate, replaced that with Xubuntu, but no luck.

So searching, once more, at random, I found the thread Massive, unpredictable I/O performance drop in Linux

The author there said that

sudo sh -c 'echo 3 > /proc/sys/vm/drop_caches'

worked for him. I tried it and it worked. The USB disk stopped making grinding noises almost immediately and returned to normal speed.

But frankly, I have absolutely no clue what I am doing here. What is /proc/sys/vm/drop_caches? This file is still empty after the echo? Why does this work, and are there any problems doing this? Does it indicate a hardware problem?

Addendum 1: I have implemented this by calling a script running sync and the echo in the root crontab that runs the backup jobs. The main backup job starts at 3:30 am and I call the script just before it and also at 4 am and 5 am. The backup only seemed to have picked up speed after the 4 am script, so it is not quite straightforward to implement this. But I can now reasonably run overnight system backups again.

Addendum 2: Maybe I should also point out that at one point I saw the 0.3 MB/s transfer rates while, IIRC, copying a 30 GB or so file structure from the Internet to the internal system hard disk /. So it is not obvious to me that the problem is the slower USB hard disks (which are not particularly slow anyway, in my opinion, at 30 Mb/s or more when the system is working properly, like after writing to /proc/sys/vm/dropped_caches.)

Addendum 3: changing vm.dirty_background_ratio, vm.dirty_ratio, vm.dirty_expire_centisecs, and vm.dirty_writeback_centisecs to what they are on my OK Laptop did not make a difference.

Addendum 4: Apparently this is a known bug, https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts-trusty/+bug/1333294 A useful link from there is http://flaterco.com/kb/PAE_slowdown.html. Setting GRUB_CMDLINE_LINUX="mem=8192M" in /etc/default/grub, running update-grub, and rebooting seems to have returned disk writing to a reasonable speed without using drop_caches. (At the loss of 8GB of memory.)

Rui F Ribeiro
  • 56,709
  • 26
  • 150
  • 232
Leon van Dommelen
  • 41
  • Could be because of the "buffer bloat" problem described in this article: https://lwn.net/Articles/682582/ – Johan Myréen Jul 19 '17 at 11:12
  • @Johan Myréen: The fact that I have unusually large memory on the machine seems to fit. But this is really a fairly recent problem. AFAIK, it may have started when upgrading from 14.04 LTS to 16.04 LTS. – Leon van Dommelen Jul 19 '17 at 20:20
  • @myself: Yes, it started immediately after upgrading my 16 GB Windows 7 machine from 14.04 Xubuntu to 16.04 LTS MATE. I can see it from the times on my overnight backup slices. And MATE has nothing to do with it, it remains unchanged after switching to Xubuntu 16.04. And I also upgraded my 4 GB Vista machine, which did not develop the problem and has the same type of USB disk. – Leon van Dommelen Jul 20 '17 at 20:50

2 Answers2

1

It sounds like you are experiencing what is described here:

There is also the chance that a lot of I/O will overwhelm the cache, too. Ever written a lot of data to disk all at once, and seen large pauses on the system while it tries to deal with all that data? Those pauses are a result of the cache deciding that there’s too much data to be written asynchronously (as a non-blocking background operation, letting the application process continue), and switches to writing synchronously (blocking and making the process wait until the I/O is committed to disk)

This is also discussed in this LWN article. Basically your slow USB drive can handle constant small writes but when your backup job runs it fills the vm cache and now you get slow synchronous writes for a while. "echo 3 > /proc/sys/vm/drop_caches" removes clean objects from these caches allowing I/O to make use of the cache, thereby increasing performance.

As suggested in the links experiment with changing the values for "vm.dirty_*". E.g., vm.dirty_background_ratio and vm.dirty_ratio.

Mark Wagner
  • 1,911
0

https://www.kernel.org/doc/Documentation/sysctl/vm.txt

Writing to this will cause the kernel to drop clean caches, as well as reclaimable slab objects like dentries and inodes. Once dropped, their memory becomes free.

To free slab objects and pagecache: echo 3 > /proc/sys/vm/drop_caches

"clean cache" is cache that is the same as one on the disc, so you can simply drop it and reread it from disk later.

Page cache is cache of memory pages read from disk: https://en.wikipedia.org/wiki/Page_cache

Slab is contiguous piece of memory: https://en.wikipedia.org/wiki/Slab_allocation

user996142
  • 672