Scheduled Maintenance: We are aware of an issue with Google, AOL, and Yahoo services as email providers which are blocking new registrations. We are trying to fix the issue and we have several internal and external support tickets in process to resolve the issue. Please see: viewtopic.php?t=158230

 

 

 

Dimensioning of the SWAP space

Ask for help with issues regarding the Installations of the Debian O/S.
Message
Author
LE_746F6D617A7A69
Posts: 932
Joined: 2020-05-03 14:16
Has thanked: 7 times
Been thanked: 65 times

Re: Dimensioning of the SWAP space

#21 Post by LE_746F6D617A7A69 »

p.H wrote:
LE_746F6D617A7A69 wrote:You should avoid to use swap memory at all costs
You cannot be more wrong.
Uhm.
Avoid to use != Don't create a swap.
Try to use any modern OS with a 1GB of RAM and 16GB of swap - probably even a web browser will start to choke because of swappiness.
p.H wrote:
LE_746F6D617A7A69 wrote:Swap memory has just one purpose: to protect the system from triggering the OOM Killer.
You cannot be more wrong again.
But of course this is the *only* reason.
All the swap-related kernel activity, like swapping-out "unused" memory pages (containing code or data that was not referenced in some defined period of time) is serving exactly this single purpose: avoid OOM situations.
The costs are obvious: the higher swap usage, the higher probability of hitting swapped page, what means deadly slowdown in task switching/data access.
The problem is very serious, most of time-critical applications are usually entirely disabling swapping of their RAM areas, f.e. by calling mlockall(MCL_CURRENT|MCL_FUTURE).
p.H wrote:
LE_746F6D617A7A69 wrote:use sparse files as a swap
Sparse files cannot be used as swap. The kernel needs to map all the swap space to the underlying block device. Of course this is not possible with a sparse file which does not have allocated blocks for all its space. Swap files are a dirty hack which does not work with all files and filesystems.
Yes, I've made a mistake regarding the term "sparse" - it was late night, and my knowledge of english have failed me - again :cry:
Bill Gates: "(...) In my case, I went to the garbage cans at the Computer Science Center and I fished out listings of their operating system."
The_full_story and Nothing_have_changed

CwF
Global Moderator
Global Moderator
Posts: 2638
Joined: 2018-06-20 15:16
Location: Colorado
Has thanked: 41 times
Been thanked: 192 times

Re: Dimensioning of the SWAP space

#22 Post by CwF »

LE_746F6D617A7A69 wrote:But of course this is the *only* reason.
It's a matter of perspective. I relate OOM with a single task that runs out and while in focus, needs to pause for slow swap. That is one sense. When using fast compressed memory swap, spare cores and threads, the focus program need not be affected at all. In this sense, the use of swap is to intentionally manage an over committed condition.

The use of swap has evolved.

p.H
Global Moderator
Global Moderator
Posts: 3049
Joined: 2017-09-17 07:12
Has thanked: 5 times
Been thanked: 132 times

Re: Dimensioning of the SWAP space

#23 Post by p.H »

LE_746F6D617A7A69 wrote:Avoid to use != Don't create a swap.
I did not make that confusion. I understood "avoid to use swap" as "avoid to swap out pages".
LE_746F6D617A7A69 wrote:Try to use any modern OS with a 1GB of RAM and 16GB of swap - probably even a web browser will start to choke because of swappiness.
No, it will choke due to insufficient RAM. The main purpose of swap is not to replace insufficient RAM but to unload rarely used pages from RAM and make space for a better use, typically page cache (aka disk cache).
LE_746F6D617A7A69 wrote:All the swap-related kernel activity, like swapping-out "unused" memory pages (containing code or data that was not referenced in some defined period of time) is serving exactly this single purpose: avoid OOM situations.
Nope, swapping out unused pages has nothing to do with OOM. In an OOM situation the kernel will swap out even frequently used pages, creating thrashing.
What is to be avoided is thrashing, not swapping out.
LE_746F6D617A7A69 wrote:I've made a mistake regarding the term "sparse"
Then what did you mean ?

LE_746F6D617A7A69
Posts: 932
Joined: 2020-05-03 14:16
Has thanked: 7 times
Been thanked: 65 times

Re: Dimensioning of the SWAP space

#24 Post by LE_746F6D617A7A69 »

p.H wrote:No, it will choke due to insufficient RAM. The main purpose of swap is not to replace insufficient RAM but to unload rarely used pages from RAM and make space for a better use, typically page cache (aka disk cache).
Which is what I've already said - insufficient RAM space leads to higher swap usage -> performance drop.
p.H wrote:Nope, swapping out unused pages has nothing to do with OOM. In an OOM situation the kernel will swap out even frequently used pages, creating thrashing.
What is to be avoided is thrashing, not swapping out.
Uhm, excluding the fact that in most cases the kernel is swapping the memory above vm.swapiness treshold.
p.H wrote:
LE_746F6D617A7A69 wrote:I've made a mistake regarding the term "sparse"
Then what did you mean ?
Hmm... "dense" perhaps?
CwF wrote:
LE_746F6D617A7A69 wrote:But of course this is the *only* reason.
It's a matter of perspective. (...) When using fast compressed memory swap, spare cores and threads, the focus program need not be affected at all.
De-compression is at least 10'000 times slower than normal RAM data access (typically around 60 nano-seconds), but indeed it can be faster than reading swap data from HDD or from a 3-months old SSD ;)
Bill Gates: "(...) In my case, I went to the garbage cans at the Computer Science Center and I fished out listings of their operating system."
The_full_story and Nothing_have_changed

User avatar
MicroScreen
Posts: 23
Joined: 2019-01-10 17:20

Re: Dimensioning of the SWAP space

#25 Post by MicroScreen »

p.H wrote:
LE_746F6D617A7A69 wrote:All the swap-related kernel activity, like swapping-out "unused" memory pages (containing code or data that was not referenced in some defined period of time) is serving exactly this single purpose: avoid OOM situations.
Nope, swapping out unused pages has nothing to do with OOM. In an OOM situation the kernel will swap out even frequently used pages, creating thrashing. What is to be avoided is thrashing, not swapping out.
Oh man, as you can see, that's exactly the kind of discussion I wanted to avoid here, but there are always people who believe they know better than the rest of the world and then 90% of all statements turn out to be demonstrable totally wrong. It would have been better if he had gone to bed on time and read a good textbook on the subject first, than to spread his superfluous "intellectual" effusions here. :lol:
"Move forward and do what you think is best. If you make a mistake, you’ll learn something. But don't make the same mistake twice." - Akio Morita

LE_746F6D617A7A69
Posts: 932
Joined: 2020-05-03 14:16
Has thanked: 7 times
Been thanked: 65 times

Re: Dimensioning of the SWAP space

#26 Post by LE_746F6D617A7A69 »

Yeah, reading with understanding can be a challenging task ...
:lol:
Bill Gates: "(...) In my case, I went to the garbage cans at the Computer Science Center and I fished out listings of their operating system."
The_full_story and Nothing_have_changed

User avatar
MicroScreen
Posts: 23
Joined: 2019-01-10 17:20

Re: Dimensioning of the SWAP space

#27 Post by MicroScreen »

CwF wrote:I relate OOM with a single task that runs out and while in focus, needs to pause for slow swap. That is one sense.
Not really! Nowadays, OOM is a rather theoretical state that can only be reached when a task has already started at the limit and has to share the remaining memory with other tasks. What happens after that has p.H. already aptly explained. Process data loss would therefore occur much sooner than actually reaching the physical memory limits. Apart from that, an operating system should be set up in such a way that it warns of this in good time.
CwF wrote:When using fast compressed memory swap, spare cores and threads, the focus program need not be affected at all. In this sense, the use of swap is to intentionally manage an over committed condition.
That's exactly right, so it's a fallacy to assume that the compression or decompression process could slow down something here. In fact, the access time for this data is exactly the same as for everything else in RAM! 8)
"Move forward and do what you think is best. If you make a mistake, you’ll learn something. But don't make the same mistake twice." - Akio Morita

LE_746F6D617A7A69
Posts: 932
Joined: 2020-05-03 14:16
Has thanked: 7 times
Been thanked: 65 times

Re: Dimensioning of the SWAP space

#28 Post by LE_746F6D617A7A69 »

MicroScreen wrote:
CwF wrote:I relate OOM with a single task that runs out and while in focus, needs to pause for slow swap. That is one sense.
Not really! Nowadays, OOM is a rather theoretical state that can only be reached when a task has already started at the limit and has to share the remaining memory with other tasks. What happens after that has p.H. already aptly explained. Process data loss would therefore occur much sooner than actually reaching the physical memory limits. Apart from that, an operating system should be set up in such a way that it warns of this in good time.
What happens is that newly starting process forces the kernel to swap RAM areas of other processes - and this is the beginning of a disaster.
Mr p.H is right only in one aspect: low RAM means smaller FileSystem/disk caches, but this has nothing to do with swapping of the memory.
MicroScreen wrote:
CwF wrote:When using fast compressed memory swap, spare cores and threads, the focus program need not be affected at all. In this sense, the use of swap is to intentionally manage an over committed condition.
That's exactly right, so it's a fallacy to assume that the compression or decompression process could slow down something here. In fact, the access time for this data is exactly the same as for everything else in RAM! 8)
It's rather typical, that forums are full of trolls which are spreading bullshits.

Explanation:
Let's assume a very simple (theorethical) situation: the only task that the kernel is performing is swapping of the RAM pages <SWP> and there's just one single-thread user program running <UProg>
Case 1:
The amount of free memory have dropped below vm.swapiness -> SWP is starting to save the memory pages to a swap storage.
This process can be executed in parallel to UProg, but it affects the UProg in at least two aspects:
1. On multicore CPUs at least the L3 cache is shared -> the SWP is partially invalidating the L3 cache, what means that UProg must share the cache with SWP,
2. In turn this means greater probability of cache misses -> slower data/code access -> slower execution of UProg.

Case 2:
UProg needs to access a memory page which has been swapped (saved in swap storage).
When UProg tries to access such page, it is "frozen" by the kernel until the page is loaded from a swap storage -> it is completely meaningless whether the page data is loaded or decompressed - the UProg can't continue until the operation is finished.
Even if the decompression is running on a separate CPU core, it does not change anything -> the UProg still has to wait until the page becomes ready (loaded or decompressed into UProg process' RAM area)
Bill Gates: "(...) In my case, I went to the garbage cans at the Computer Science Center and I fished out listings of their operating system."
The_full_story and Nothing_have_changed

User avatar
MicroScreen
Posts: 23
Joined: 2019-01-10 17:20

Re: Dimensioning of the SWAP space

#29 Post by MicroScreen »

LE_746F6D617A7A69 wrote:It's rather typical, that forums are full of trolls which are spreading bullshits.
Right, that's why you should finally stop spreading this hypothetical bullshit! :P
Your utterances have clearly shown recently that you have no idea what you are talking about and p.H was completely right, he is competent and to be taken seriously. People like you should be constantly ignored! :roll:
"Move forward and do what you think is best. If you make a mistake, you’ll learn something. But don't make the same mistake twice." - Akio Morita

p.H
Global Moderator
Global Moderator
Posts: 3049
Joined: 2017-09-17 07:12
Has thanked: 5 times
Been thanked: 132 times

Re: Dimensioning of the SWAP space

#30 Post by p.H »

LE_746F6D617A7A69 wrote:low RAM means smaller FileSystem/disk caches, but this has nothing to do with swapping of the memory.
Yes it does. Filesystem cache and swap are the two sides of a single coin : virtual memory management.
Under memory pressure, the kernel has two options : either discard anonymous pages (process data) to swap or cache pages (filesystem data). Both may cause I/O to write the discarded data to swap or filesystem (if unclean), and will cause I/O to reload the data from swap or filesystem into memory when they are needed again.
LE_746F6D617A7A69 wrote:The amount of free memory have dropped below vm.swapiness
Nonsense. vm.swappiness is not a threshold.

trinidad
Posts: 290
Joined: 2016-08-04 14:58
Been thanked: 14 times

Re: Dimensioning of the SWAP space

#31 Post by trinidad »

Basically the three tools to optimize a given machine's performance (bare metal) regarding swap have been mentioned, and in fact when dealing with any processes that carry a heavy RAM tax all of them may be employed for performance optimization. They are somewhat interrelated and optimization during heavy RAM usage may require tweaking all three. They are as follows: cache pressure settings, swappiness, and earlyOOM. Swap has also proved to be convenient for some processes where slower linked and staged, or timed data processing is necessary. Theoretically speaking, journaling file systems should have a swap partition for stability (this applies importantly to scientific machines), and as we have discovered with the Intel CPU vulnerabilities, a swap partition is no less secure than encrypted chip memory. More than any other, specific software design and integration should be the determining factor for specific swap sizing. So you see, it really depends what software you are using, and what you are doing with it. In the end, at the consumer baseline, modern hardware design gives back some stability in favour of cheaper performance anyway, so for a home user there is really no guarantee of trouble free computing at the hardware level. As far as software... Debian stable is the way to go.

TC
You can't believe your eyes if your imagination is out of focus.

LE_746F6D617A7A69
Posts: 932
Joined: 2020-05-03 14:16
Has thanked: 7 times
Been thanked: 65 times

Re: Dimensioning of the SWAP space

#32 Post by LE_746F6D617A7A69 »

p.H wrote:Nonsense. vm.swappiness is not a threshold.
It's better to call it "threshold" (while it is in fact "aggressiveness") to explain basic rules for people who don't want to read the kernel code - this hides the fuzzy logic behind the swapiness.
For the same reason I've used the term "frozen by the kernel" instead of: "the MMU is raising page fault interrupt, which stops the execution of the process"

@TC
+1, great post.
Bill Gates: "(...) In my case, I went to the garbage cans at the Computer Science Center and I fished out listings of their operating system."
The_full_story and Nothing_have_changed

User avatar
MicroScreen
Posts: 23
Joined: 2019-01-10 17:20

Re: Dimensioning of the SWAP space

#33 Post by MicroScreen »

trinidad wrote:Theoretically speaking, journaling file systems should have a swap partition for stability (this applies importantly to scientific machines), and as we have discovered with the Intel CPU vulnerabilities, a swap partition is no less secure than encrypted chip memory. More than any other, specific software design and integration should be the determining factor for specific swap sizing. So you see, it really depends what software you are using, and what you are doing with it.
This is largely in line with what I have already said. It always depends on how software was written and what amounts of data are moved in the ongoing process. It is therefore completely pointless to discuss purely theoretical scenarios when each user works under completely different conditions. Generalizations, as presented here by a single discussant, completely miss the topic and should therefore be ignored if possible!
"Move forward and do what you think is best. If you make a mistake, you’ll learn something. But don't make the same mistake twice." - Akio Morita

LE_746F6D617A7A69
Posts: 932
Joined: 2020-05-03 14:16
Has thanked: 7 times
Been thanked: 65 times

Re: Dimensioning of the SWAP space

#34 Post by LE_746F6D617A7A69 »

MicroScreen wrote:(...) It always depends on how software was written and what amounts of data are moved in the ongoing process. It is therefore completely pointless to discuss purely theoretical scenarios when each user works under completely different conditions. Generalizations, as presented here by a single discussant, completely miss the topic and should therefore be ignored if possible!
"Purely theoretical scenarios" are used to explain the basic rules/typical cases.
Typical Linux system runs tens of services (processes) - and excluding Real-Time projects (rare cases), all other applications are creating *regular* processes - which are subject to generating problems resulting from insufficient RAM size/problems with using swap memory.
Only privileged process can call mlockall() - so only special applications can disable swapping of their RAM areas - in all other cases, typical applications are becoming a victims of memory swapping.

It is obvious, that You have no idea of "how software is written", starting from how the process' virtual memory is managed and ending with how to write the software in general - I think this is the main reason behind Your stupid aggressiveness.
Bill Gates: "(...) In my case, I went to the garbage cans at the Computer Science Center and I fished out listings of their operating system."
The_full_story and Nothing_have_changed

CwF
Global Moderator
Global Moderator
Posts: 2638
Joined: 2018-06-20 15:16
Location: Colorado
Has thanked: 41 times
Been thanked: 192 times

Re: Dimensioning of the SWAP space

#35 Post by CwF »

Well LE, I did give real examples and did say it's 'observational'. There's nothing theoretical about it. I've tested zramswap to lock, it works and manages better than nothing. I don't notice its operation...

So question; In my prior post both machines have a small swap occupied, both with >60% memory free --What is the swap, when did it happen, why is it there?

Ya see, I don't care why. But your suggestion is the existence of that swap represents a negative performance impact occurred at some point? I didn't notice, because no - it doesn't impact performance, IMO it increases performance.

The first machine now has 340.8MB in swap, and 38GB free memory. The second machines swap also dropped, 293.8MB with 16GB free. Neither has rebooted. I hardly think it's there only to prevent OOM, that view simply has no merit in such a case as this. Something wants to swap out, so let it...

Perhaps if swap were on a SSD I'd notice? No, I don't. Maybe on a spinner, but I'd notice before swap started...I now prefer only memory as swap because it works and can be designed in, specifically to eliminate a physical device, my #1 reason. To go without swap is not a valid option since my testing shows performance is lower. Oh, and I 'dimension' that allocation to 10%

note: the etc/default/zramswap changes for Bullseye. New option language and defaults - 50%!

User avatar
MicroScreen
Posts: 23
Joined: 2019-01-10 17:20

Re: Dimensioning of the SWAP space

#36 Post by MicroScreen »

CwF wrote:I hardly think it's there only to prevent OOM, that view simply has no merit in such a case as this. Something wants to swap out, so let it.

I now prefer only memory as swap because it works and can be designed in, specifically to eliminate a physical device, my #1 reason. To go without swap is not a valid option since my testing shows performance is lower. Oh, and I 'dimension' that allocation to 10%.
That's the way it is, and 99% of that is consistent with the experience of all those users who are more involved in the subject. The very idea that swapping would be something negative is completely absurd and only proves that this troll does not have the slightest knowledge of the matter. The memory management of individual applications is often fundamentally different from what one expects and should therefore always be observed first. There are a lot of programs that start outsourcing their process data early in any case, long before the RAM even threatens to become full, simply because the program was written in this way. But this dilettante will probably never understand that, because he simply has too little sense for it.
It's better to just ignore him and his nonsense!
"Move forward and do what you think is best. If you make a mistake, you’ll learn something. But don't make the same mistake twice." - Akio Morita

trinidad
Posts: 290
Joined: 2016-08-04 14:58
Been thanked: 14 times

Re: Dimensioning of the SWAP space

#37 Post by trinidad »

On servers that run many virtual machines or containers, zramswap allows you to optimise memory usage by swapping out data that's not often accessed, but when a user needs to access it, it will be available fast. It allows you to overcommit on memory with a negligible hit on your application performance (and often an improvement in performance where you can use more main memory for filesystem cache).
https://manpages.debian.org/buster/zram ... .1.en.html

https://fedoraproject.org/wiki/Changes/SwapOnZRAM

Are there any comparative figures on data loss/errors with zramswap to alternatively using specifically targeted disk swap partitions?

Compression caching... is still compression caching.

TC
You can't believe your eyes if your imagination is out of focus.

CwF
Global Moderator
Global Moderator
Posts: 2638
Joined: 2018-06-20 15:16
Location: Colorado
Has thanked: 41 times
Been thanked: 192 times

Re: Dimensioning of the SWAP space

#38 Post by CwF »

trinidad wrote: data loss/errors with zramswap to alternatively using specifically targeted disk swap partitions?
If this translates to "Is data recovered from swap on next reboot after a crash?"
I think the answer is NO, could it be, sure.

Good quote!

trinidad
Posts: 290
Joined: 2016-08-04 14:58
Been thanked: 14 times

Re: Dimensioning of the SWAP space

#39 Post by trinidad »

@CwF I know that the obvious trade-off with multi-voltage SSDs or any multi voltage chip storage involves wear levelling and certainly zramswap can alleviate that issue to some degree, but I always wonder about performance versus accuracy, and I remain a little reticent over our headlong rush into hardware chip performance these days almost fearing an event horizon that could leave us with no older actually working technology having been pushed out of the market by newer faster stuff. I've read a few papers on VM memory management with some new promising ideas that make deployments and cloning/testing much more efficient, and some of the ideas are creative and amazing compared to what I used to have to slug through. I don't think software in general was quite prepared for these new possibilities and I think as things go along there are going to be many improvements in how software uses swap. Swap is definitely an interesting subject for discussion and it is currently cutting edge for sys admins.

@MicroScreen
There are a lot of programs that start outsourcing their process data early in any case, long before the RAM even threatens to become full, simply because the program was written in this way
Yes indeed, and there are new ways of handling swap more efficiently in such cases such as "lazy" paging.

TC
You can't believe your eyes if your imagination is out of focus.

CwF
Global Moderator
Global Moderator
Posts: 2638
Joined: 2018-06-20 15:16
Location: Colorado
Has thanked: 41 times
Been thanked: 192 times

Re: Dimensioning of the SWAP space

#40 Post by CwF »

trinidad wrote:wear levelling and certainly zramswap can alleviate that issue to some degree
No alleviation, zramswap totally eliminates the issue the same as no swap.
trinidad wrote:I always wonder about performance versus accuracy
I'm not sure I get the point. Accuracy where?

If memory is the concern, maybe, but I do use ECC. I've had VM's and nested layers entirely in memory for weeks at a time. I do move their images to disk and back and am more concerned with integrity while on storage. Never have had issue with cosmic rays!

Locked