5

I have been noticing that if I copy a file to some storage device (the system's HDD, SSD, or to a thumbdrive) a small amount of data (20 - 30 MB) is written to the swap space - and the count increases. Yes, even the systems have available RAM.

Writing to the swap space makes the device very slow. Thrashing is the obvious case.

If I turn swap off before copying, the files gets copied just fine!

Here's a screenshot:

enter image description here

I am copying a big file to /dev/sda2. I have available RAM, yet some data is always written to the swap. This behaviour is same across all the devices I own, and the devices I got time to play around.

I tried changing the swappiness with this command command:

sysctl vm.swappiness=n # n for a value from 0..100

Tried turning the swappiness to 0, and also tried turning the swappiness to 100. The behaviour doesn't change. Any system monitor says I am having a good amount of available RAM. It still writes data to the swap.

15 Volts
  • 2,069
  • 1
    Have you tuned swappiness? If you have, you may be seeing a similar issue to me. – Sparhawk Apr 07 '19 at 06:01
  • That's a good point. I haven't tuned the swappiness. It came all by default with the Arch Linux installation. BTW, this only happens when copying big files (with cp, rsync, GUI file managers). So, after copying files, I always have to restart my PC to clear the used swap space. – 15 Volts Apr 07 '19 at 06:07
  • 1
    Please try turning swappiness down (or off), test again, then report back here. – Sparhawk Apr 07 '19 at 06:15
  • So, I tried turning swappiness (with the command: sysctl vm.swappiness=0) to 0, copied a file. Same thing. It writes to swap space like before. I turned swappiness to 100, same behaviour. This is quite confusing. I updated the image above. – 15 Volts Apr 07 '19 at 06:41
  • I guess it's a dupe of the other question then. I'm presuming it's a bug. – Sparhawk Apr 07 '19 at 07:21
  • 1
    Modern applications use posix_madvise(3)/madvise(2) to avoid this unwanted but to be expected behaviour. – A.B Apr 07 '19 at 08:01
  • Same issue here. I've been meaning to write a question. – Faheem Mitha Apr 07 '19 at 08:28
  • Not sure if it's a bug. But this is not very convenient. As I said, turning off the swap before copying those big files, has no bad effect. So, I guess there's no need to write to the swap.

    Also note the screenshot I provided is taken after a reboot. When the swap usage was 0, it slowly increased as the copy progressed. When the copy was over, it reduced a bit. But this behaviour makes the system quite slower if you are using HDDs for swap (and swapping on SSDs makes it's life shorter, both ways you don't want that).

     – 15 Volts Apr 07 '19 at 09:28
  • Not a bug in the gnome-system-monitor 'cause I rechecked the contents of /proc/diskstats - which agrees with gnome-system-monitor – 15 Volts Apr 07 '19 at 09:29

2 Answers2

4

In general, that behavior is application-dependent on whether the copying application gives proper indication to the kernel as to how it will read the file that it will copy.

In your case I see your file is just slightly bigger than your overall memory, so it might be that your GUI’s file manager requests a full generic mmap on the file instead of copying it in chunks.

Try copying it with cp from a terminal window. The cp command diligently gives indications to the kernel and copies the file in whatever chunks it detects to be the most appropriate for the system. You might still see the cache filling the memory but swapping should not be triggered, if not for just a bunch of bytes due to a spike in memory pressure.

LL3
  • 5,418
1

What is probably happening, is that ram is being used for disk-cache. Disk-cache is not shown on the monitor that you show. The kernel may then decide to swap out inactive memory, in preference to dropping cache.

If there rely is a performance problem (not just a potential problem), then there are ways to tell the system to do something (e.g. copy a file) without writing to the disk-cache. This will not slow down the write, but will slow-down any future read of the file (i.e if you copy the file, then read it).

ctrl-alt-delor
  • 27,993