13

I believe that something strange is going on with my swap / hardware / drivers.

I'm trying to increase the swap size by swapoff, lvresize, then swapon again.

When I did swapoff /dev/swapdev, the command took 8mins 19seconds to move about 3.5GB of swapped pages into memory.

I ensured that my free RAM was greater than the swap usage before running swapoff, and this stayed true while it was running.

I have a Intel Core i5 laptop with SSD HDD. The processor was at less than 10% before swapoff, and when I checked in, swapoff was using 70%+ CPU.

There was nothing interesting in the journal the whole time.

Here's approximately how long I'd expect it to take to shunt 3.5G from disk to memory:

$ time dd if=/dev/urandom of=/tmp/del bs=1M count=3500
3500+0 records in
3500+0 records out
3670016000 bytes (3.7 GB, 3.4 GiB) copied, 23.7288 s, 155 MB/s

real    0m24.789s
user    0m0.000s
sys     0m22.743s

I'm running Linux svelte 4.9.53-1-MANJARO #1 SMP PREEMPT Thu Oct 5 15:11:15 UTC 2017 x86_64 GNU/Linux

Any reason that the command would take so long? This could be part of a larger issue, but this is the first thing that I can definitively point at which looks strange.

Improve this question
2
  • 1
    It may be useless after the fact but the -v flag may be useful going forward.
    – Raman Sailopal
    Commented Nov 9, 2017 at 9:28
  • 1
    It seems you should be happy with 8minutes,as this question complains about 4 hours, though that was for a rotating drive. The answers to that question have some explanations, and in particular this answer provides a speedup.
    – meuh
    Commented Nov 9, 2017 at 9:36

1 Answer 1

Reset to default
12

You're missing what swapoff really does.

Retiring swap space on a running machine, which is swapping, is extremely complex. 3.5G in 8min is likely very fast + is working as expected.

Running swapoff doesn't just simply move code off disk into memory.

Once you're swapping... well... you're swapping, which means your OS is starved for memory + you have disk i/o to your swap device + disk i/o to your other file systems + maybe even the OOM (out of memory killer) starting to run + then process thrash of OOM'ed processes restarting, if watchdogs or systemd auto restarts are involved.

If your system is swapping, that means swapping is the only thing keeping your system alive.

If you kill swap space, then your system can't use swap space anymore, so now your OS has to load code of normal filesystems + evict code when memory is exhausted + then rather then pulling code off fast swap space via optimized, raw disk reads, all your code has to come off normal filesystems, with directory walks. This is far more resource intensive, than pulling from swap space.

When you do a swapoff on a system that's swapping... usually you'll end up in a situation where this process will take hours + sometimes machines will crash.

If you have to retire a swap device for some reason, best to first create a secondary, filesystem based swap space + do a swapon for this new swap space, then do your swapoff on the old swap device.

If you take this approach, your system will always survive.

Improve this answer
2
  • 2
    The thing is, I closed chrome and thunderbird and ensured that my free RAM was greater than the swap usage first. I should have mentioned this in the question. I wouldn't ask it to do the impossible.
    – Tom Hale
    Commented Nov 9, 2017 at 15:39
  • False: “If your system is swapping, that means swapping is the only thing keeping your system alive.” Linux will proactively move seldom-accessed anonymous pages into swap to free up more physical RAM to cache the file system. This happens even if your system is not under memory pressure at all — swapping will occur even when MemAvailable is a large fraction of your total physical RAM. This is by design, as physical RAM holding seldom-used pages is wasted and is much better put to use as cache to speed up file-system accesses.
    – Matt Whitlock
    Commented Apr 30 at 22:11

Not the answer you're looking for? Browse other questions tagged .