Differences

This shows you the differences between two versions of the page.

--- start:zramswap [2022/09/11 13:10] – peter
+++ start:zramswap [2023/09/13 18:36] (current) – peter
@@ Line 1: / Line 1: @@
+DATE CHECKED THIS PAGE WAS VALID: 13/09/2023
 Ubuntu and Debian are fairly similar - zramswap lets you get more ram use/tricks system into thinking there is more by compressing parts of your RAM.
@@ Line 9: / Line 11: @@
 You do want to make sure your partitioning scheme is nice and logical so if you need to make any changes you can just boot a live Ubuntu CD and run gparted and move and resize partitions as needed (takes a long time to complete resize and move operations).
-The swap partition is abnormally large as I have 32GB of RAM and with zram you use 50% of your RAM size for zramswap. I have experimented with other values but any larger reduces performance. the compression is around 3 on average so you want to have enough swap to move out the 16GB when its uncompressed into a normal page file if need be or you can have weird issues. To ensure thats possible a disk swap of about double RAM works pretty well in testing. This allows me to allocate out about 44GB of RAM to virtual machines without any performance issues. Once you go over that you do notice a couple of pauses here and there as the base OS of Debian seems to like about 4GB to itself either some free, and a couple of GB for it to run nicely. Basically I just take my RAM + zram - 4GB so in my case 32+16-4=44 or there about. It is plenty when running a bunch of VM's.
+The swap partition is abnormally large in my case but typically you will have a swap partition equal to what you set zramswap to be. I have experimented with other values but this works well from what I can tell. the compression is around 2-3 on average so you want to have enough swap to move out when its uncompressed into a normal page file if need be or you can have weird issues. To ensure thats possible a disk swap of about a similar size works pretty well in testing. In my example it allows me to allocate out about 44GB of RAM to virtual machines without any performance issues. Once you go over that you do notice a couple of pauses here and there as the base OS of Debian seems to like about 4GB to itself either some free, and a couple of GB for it to run nicely. Around these values is plenty when running a bunch of VM's.
 Here is htop with 44GB of RAM allocated out to a bunch (6) of VM machines. As you can see my CPU on this laptop is starting to become the bottleneck now, as running the VM's tend to use a lot of the 12 threads I have. However being able to spin up many machines is very useful. Essentially I am able to comfortably use more than 32GB RAM on a system with less and not have massive performance issues. This is the goal:
 {{:images:htop.png|}}
+=== Actual Setup ===
 Either way, lets setup zramswap.
 You will remember that in selecting a compression algorithm, for our BTRFS disks we chose to compress with lzo (some people choose zstd for even better compression and faster reads but I prefer slightly faster writes to the disk and less memory used for operations). This is a capable compression algorithm that sacrifices some speed in compression and decompression for a slight compression improvement. For files on a disk this works well as the disk is generally the slowest part when collecting data and so retrieving a smaller file then decompressing it is worth the cpu hit.
-However for RAM this is not true. Selecting lzo is a poor choice because we need the RAM to be as fast as possible. After all that is where the system has placed files it needs right now. So instead we need to select the fastest decompression algorithm. This is lz4. While our compression ratios might not be as good, the fact that the data is accessible very quickly means we wont have pauses, or slowdowns while things are paged in and out of zramswap. This can happen if the compression algorithm chosen cannot keep up with the demands of the system.
+However for RAM this is not true. Selecting lzo is a poor choice because we need the RAM to be as fast as possible. After all that is where the system has placed files it needs right now. So instead we need to select the fastest decompression algorithm. This is lz4 (see end for some exceptions). While our compression ratios might not be as good, the fact that the data is accessible very quickly means we wont have pauses, or slowdowns while things are paged in and out of zramswap. This can happen if the compression algorithm chosen cannot keep up with the demands of the system.
 To get started we install zram tools:
@@ Line 93: / Line 97: @@
 If anyone has any other notes or useful commands or things about ZramSwap, add them here.
-Some suggestions: 64GB RAM? Try 24GB zramswap and 16GB disk swap. Increase disk swap if disk swap fills up too quickly. Dont use more than 32GB zramswap.
+Some suggested values:
+GB,2GB or 4GB systems : zramswap the same size as RAM but zstd compression and a swapfile the same size as zramswap value eg:
+GB RAM example - zramswap set to 4GB also and Swap partition of 4GB also. Thus you see 4GB RAM in htop and 8GB swap (4gb being zramswap). 1GB,2GB and 4GB systems tend to have too little RAM (eg: raspberry pi etc) and setting a large value and accepting a slower compression at cost of CPU can improve performance in most cases. (See swappiness page on systems for low ram - you may wish to set swappiness to 101).
+GB, 16GB systems : zramswap half the size of RAM, swapfile half the size of RAM (equal to zramswap value). lz4 for all RAM values 8GB or more (faster, not RAM constrained machines).
+GB RAM and beyond : zramswap 25% of RAM, swapfile same value.
+Reason for 32GB and more systems using this is that zramswap tends to be less speedy than just using RAM alone so if you already have a ton of RAM its benefit starts to tail off as you have more and more available RAM. In some cases you might find a use case for it but mostly when you start getting to the stage where you have ample RAM, its benefit is of lower value so you may as well not set large values anymore, or use it at all.
+Some exceptions might be a 64GB system with a large database and increasing RAM could be too costly so you are forced to increase RAM some other way. This situation it might be best to use zstd and a 75% value of ram for zramswap. This could be a balance until you can afford to pay for more RAM or upgrade your VPS.
-GB RAM - 16GB zramswap, 32GB disk swap to be safe.
+Note if you are running any sort of database do not go beyond 85% of your ram under any circumstances and regardless of how much or little ram you have. Dont do it.
-GB RAM - 32GB zramswap, 16GB disk swap.
-Etc. Test your own values. Milage might vary.
+Etc. Test your own values. Mileage might vary.

Make Debian Fun Again And Learn How To Do Other Cool Stuff Too

User Tools

Site Tools

Differences

Page Tools