As a consequence, recommended swap space is considered a function of system memory workload , not system memory. Table 1 provides the Fedora Project's recommended size for a swap partition, depending on the amount of RAM in your system and whether you want enough memory for your system to hibernate. To allow for hibernation, you need to edit the swap space in the custom partitioning stage.
The "recommended" swap partition size is established automatically during a default installation, but I usually find it's either too large or too small for my needs. The Fedora 28 Installation Guide defines current thinking about swap space allocation. Note that other versions of Fedora and other Linux distributions may differ slightly, but this is the same table Red Hat Enterprise Linux uses for its recommendations.
These recommendations have not changed since Fedora Table 2 contains my recommendations based on my experiences in multiple environments over the years. It's possible that neither of these tables will work for your environment, but they will give you a place to start.
The main consideration is that as the amount of RAM increases, adding more swap space simply leads to thrashing well before the swap space comes close to being filled. If you have too little virtual memory, you should add more RAM, if possible, rather than more swap space. Even when running four or five VMs, multiple documents in LibreOffice, Thunderbird, the Chrome web browser, several terminal emulator sessions, the Xfe file manager, and a number of other background applications, the only time I see any use of swap is during backups I have scheduled for every morning at about 2am.
Even then, swap usage is no more than 16MB—yes megabytes. These results are for my system with my loads and do not necessarily apply to your real-world environment. I recently had a conversation about swap space with some of the other Community Moderators here at Opensource. This article was written in , and he told me later that he now recommends zero swap space.
I'm a bit old fashion, as I still support the idea of twice the physical RAM. That normally works as I aim for 8 GB for a two core system, which most of mine are. That keeps it simple and easy to remember. The only time I run into trouble is when I try to use pan2 for Usenet. Even with that much swap space, it can't handle the retention on NewsDemon. It once ran for 84 hours and used up all of the swap space downloading headers before it crashed with a segmentation fault. Unless I plan to over commit on the number of apps I run, I don't use swap space.
As for hibernation, I never turn my systems off. You have to aim for 4GB total. In the latter, that leaves about MB of shared Vram.
But Swap files are extremely bad for SSDs. They wear out the SSD quickly. So it's better to not have swap nor hibernation files, as most low end hardware usually has pretty good sleep states. If you have enough RAM, in my opinion you don't need any swap at all.
And in the latter, lower texture quality performs a lot better than running into swap. Another thing is that when you must have swap, at least make sure it is encrypted, as otherwise it defeats the purpose of any encryption you may use. Getting this to work with hibernation is left as an exercise to the reader. Usually you give a little more, for lack of a precise estimate of space requirements — which actually should be present in somebody's mind, and a great thing to learn about I think that it depends on your environment.
In my case, I have a lot of VMs. The majority of the VMs are either web servers or app servers. Given that we know exactly what's running inside JVM with limited heap size, httpd, monitoring tools, And I think that in a virtual environment, you already have the overhead of the hypervisor. And as a result swap in such an environment does not speed up things much. So, if you can, it is better to rely on RAM.
On a physical server, swap space may have more sense. This is not something worth spending much thought about. When I have looked at what my system is actually using with a monitoring tool, swap only rarely comes into play. Given the slow speed of hard drives, that much swapping, regardless of RAM size, would cripple performance. I maintain a similar philosophy today, but with larger numbers due to much much larger RAM sizes and much much faster storage. I will typically allocate GB of RAM to swap, primarily because I'd rather suffer a performance hit from swapping than have the kernel start terminating processes when memory runs out.
But I still believe that if you encounter any significant amount of swapping, then you really need more RAM. When creating virtual machines, that's a little different. I often create them with limited RAM GB because they're not running a GUI generally accessed via ssh sessions , run minimal daemons in the background and I don't want to take more than necessary from the host environment.
I will create a large 8GB swap partition in order to handle a worst-case scenario where I've woefully underestimated my RAM requirements and monitor the amount of swapping that takes place. I'll increase the RAM allocation as necessary to keep swapping to a minimum under expected loads and leave the swapfile to be available when loads are higher than expected. Either equal to the amount of installed RAM or none.
There are two factors to consider, when making this decision. I also prefer to fully shut down instead of ever hibernating. I suppose it could be useful on a system with a less or slower RAM, but realistically, I just don't think it's necessary for the majority of use cases.
Otherwise sistem will not hibernate or suspend correctly. I still almost double the ram: even with 32Gb of ram I often run out of memory while loading heavy 3d scenes. The only situation where I see swap space a must is editing large photos, like big panorama, with gimp: a lot of ram is needed, and if you don't have enough swap space, your system freezes and you are going to loose all your work. At university, at the computer laboratory where we spent our time analysing DNA sequences, there was a big DNA sequence alignment experiment I was trying to perform for phylogeny production.
The lab server computer had about 19GB of SWAP and probably 12GB of RAM I had helped set up months before and could not increase it further for a series of reasons at the time namely, I was not able to increase swap space with my then-Linux-knowledge and could not reinstall everything because the server had Windows on it, with lots of data from other people But I remember that the experiment algorithm I was using to process that data needed just a little more than 20 GB If we had , my experiment could have turned out to work out eventually I use a swapfile instead, which can grow dynamically.
My swapfile is mounted on my root partition, which I have given 64GB to. Of course, I never go that high, probably the most resource-intensive thing I ever run on my computer it's not even a computer, it's just a crappy tablet with a keyboard from my school with 4GB RAM is Android Studio.
Suspend to RAM is sufficient and works really well. Interesting article. I now know that I have 2G of Swap on Ubuntu Is that too little? I have since using Windows XP, disabled swap, never used it because I knew how to manage memory, Linux, gosh it never needed because it was so efficient at handling the memory, thus some of our friends point out under 8GB, and yeah maybe, those browsers are very memory hungry but I ran small Nix servers that use no more than Mb, sometimes growing to Mb, thus I feel if you sysadmin your machines correctly you can get away with very little ram and never even think of swap.
Some feel in the Microsoft world you need to enable swap to allow kernel swapping and some page functions require it How much should be the swap size? Perhaps these are the most common asked questions about choosing swap size while installing Linux. For a long time, the recommended swap size was double of the RAM size but that golden rule is not applicable to modern computers anymore. This will help you understand why swap is used. When there are only a few applications running your system manages with the available RAM.
But if there are too many applications running or if the applications need a lot of RAM, then your system gets into trouble. If an application needs more memory but entire RAM is already in use, the application will crash.
Swap acts as a breather to your system when the RAM is exhausted. What happens here is that when the RAM is exhausted, your Linux system uses part of the hard disk memory and allocates it to the running application.
That sounds cool. This means if you allocate like 50GB of swap size, your system can run hundreds or perhaps thousands of applications at the same time? You see, the speed matters here. RAM access data in the order of nanoseconds. An SSD access data in microseconds while as a normal hard disk accesses the data in milliseconds.
If an application relies too much on the swap, its performance will degrade as it cannot access the data at the same speed as it would have in RAM. So instead of taking 1 second for a task, it may take several minutes to complete the same task. It will leave the application almost useless. This is known as thrashing in computing terms. This is a good question indeed.
Now that we know our available storage space, we can go about creating a swap file within our filesystem. The file must allocate the amount of space that we want for our swap file, and it should be created in one contiguous block. The best way to do this is to use the dd utility.
This command will create a 4 gigabyte file:. After entering your password to authorize sudo privileges, the swap file will be created. This can take a few moments, then the prompt will be returned to you. We can verify that the correct amount of space was reserved for swap by using ls :. Right now, our file is created, but our system does not know that this is supposed to be used for swap. We need to tell our system to format this file as swap and then enable it.
Allowing other users to read or write to this file would be a huge security risk. We can lock down the permissions with chmod :. This will restrict both read and write permissions to the root account only.
We can verify that the swap file has the correct permissions by using ls -lh again:. Now that our swap file is more secure, we can tell our system to set up the swap space for use by typing:. To verify that the procedure was successful, we can check whether our system reports swap space now:.
This output confirms that we have a new swap file. We can use the free utility again to corroborate our findings:. Our swap file is enabled at the moment, but when we reboot, the server will not automatically enable the file for use.
We can change that by modifying the fstab file, which is a table that manages filesystems and partitions.
At the bottom of the file, you need to add a line that will tell the operating system to automatically use the swap file that you created:.
When you are finished adding the line, you can save and close the file. The server will check this file on each bootup, so the swap file will be ready for use from now on. These configurations are optional in most cases, and the changes that you make will depend on your application needs and your personal preference.
The swappiness parameter determines how often your system swaps data out of memory to the swap space. This is a value between 0 and that represents the percentage of memory usage that will trigger the use of swap. With values close to zero, the system will not swap data to the drive unless absolutely necessary. Telling the system not to rely on the swap as much will generally make your system faster. Values that are closer to will try to put more data into swap in an effort to keep more memory free.
We can see the current swappiness value by reading the swappiness configuration file:. CentOS 7 defaults to a swappiness setting of 30, which is a fair middle ground for most desktops and local servers. We can set the swappiness to a different value by using the sysctl command.
For instance, to set the swappiness to 10, we could type:. This setting will persist until the next reboot.
0コメント