对linux交换分区swap的一些认识总结

　　swap是所有linuxer都会接触，但是大部分人都不会关注的东西。实际上，小东西也有大学问，这不，一个关于swap的问题就在cu.linux上讨论得热火朝天的，我在这里总结在一起，绝对对各位大有帮助。要看具体讨论，请去这里。详细内容如下：

　　在debian 和 fedora的文档中，都看到有说明，swap分区最好不要超过2G。实际上，对于linux 2.6以上的内核，可以直接支持不大于64G的内存。ext3等日志型文件系统，也可以直接支持超过2G的单个文件，所以，对于64G以内的swap，在 文件系统支持的情况下，建立成一个单独的分区或文件，不会影响系统的performace。

　　Linus曾经在一个mail讨论中指出：

　　In the course of discussion, it became clear that Linux 2.4.x required more swap than previous versions. Rik van Riel mentioned, “2.4 keeps dirty pages in the swap cache, so you will need more swap to run the same programs…” He asked Linus Torvalds, “is this something we want to keep or should we give the user the option to run in a mode where swap space is freed when we swap in something non-shared ?” Linus replied:

　　I’d prefer just documenting it and keeping it. I’d hate to have two fairly different modes of behaviour. It’s always been the suggested “twice the amount of RAM”, although there’s historically been the “Linux doesn’t really need that much” that we just killed with 2.4.x.

　　If you have 512MB of RAM, you can probably afford another 40GB or so of harddisk. They are disgustingly cheap these days.

　　Zlatko Calusic worried that more data in swap would degrade performance because the disk head would need more seek time to find data. He asked if Linus was sure this would be okay, and Linus replied, “I’m not _sure_, obviously. However, one thing I _am_ sure of is that the sticky page-cache simplifies some things enormously, and make some things possible that simply weren’t possible before.” . But in a nearby post he admitted, “the sticky allocation _might_ make the IO we do be more spread out.” He felt it was important to consider these kinds of potential downsides, though he felt that in this case the benefits outweighed the drawbacks; and at one point Eric W. Biederman explained succinctly, “The tradeoff when implemented correctly is that writes will tend to be more spread out and reads should be better clustered together.”

　　Zlatko ran some tests, and could not find any problems with the 2.4.0 memory management logic, though he added, “I have found that new kernel allocates 4 times more swap space under some circumstances. That may or may not be alarming, it remains to be seen.” At one point, Linus gave his overall take on 2.2/2.4 performance issues. He said:

　　I personally think 2.4.x is going to be as fast or faster at just about anything. We do have some MM issues still to hash out, and tuning to do, but I’m absolutely convinced that 2.4.x is going to be a _lot_ easier to tune than 2.2.x ever was. The “scan the page tables without doing any IO” thing just makes the 2.4.x memory management several orders of magnitude more flexible than 2.2.x ever was.

　　(This is why I worked so hard at getting the PageDirty semantics right in the last two months or so - and why I released 2.4.0 when I did. Getting PageDirty right was the big step to make all of the VM stuff possible in the first place. Even if it probably looked a bit foolhardy to change the semantics of “writepage()” quite radically just before 2.4 was released).

　　Elsewhere, he considered the case of swapless or low-swap machines:

　　If you don’t have any swap, or if you run out of swap, the major difference between 2.2.x and 2.4.x is probably going to be the oom handling: I suspect that 2.4.x might be more likely to kill things off sooner (but it tries to be graceful about which processes to kill).

　　Not having any swap is going to be a performance issue for both 2.2.x and 2.4.x - Linux likes to push inactive dirty pages out to swap where they can lie around without bothering anybody, even if there is no _major_ memory crunch going on.

　　If you do have swap, but it’s smaller than your available physical RAM, I suspect that the Linux-2.4 swap pre-allocate may cause that kind of performance degradation earlier than 2.2.x would have. Another way of putting this: in 2.2.x you could use a fairly small swap partition to pick up some of the slack, and in 2.4.x a really small swap-partition doesn’t really buy you much anything.

　　在讨论中，Linus明确的说明了，在Linux2.4.x中，内存管理(MM)策略的改变。就如 Windows98向Windows2000转变一样，微软在内存和交换区中保存了更多的脏页，而不是及时回收内存，大幅提高了系统的效率。(见 Widnows核心编程第18章的论述)。

　　Linus还指出，即使是512M内存，也可以分配高达40G的交换区，以提高系统的性能。Zlatko 在向Linus提出性能的质疑后，自己进行了验证。实验表明大交换区策略，没有增加磁盘I/O的流量。

　　那么，swap是不是必须的?很多人认为是，其实，普通意义上所谓的swap是内存的2倍只是一个给新手使用的经验值，实际使用swap的大小是根据程序对内存使用状况需要调整的。如果机器在运行时对内存的需求量不大，就没有必要要swap。

　　这个问题就变成了 我不知道所有任务最大内存需求是多少，那怎么办?

　　可以1步1步来:

　　1 用swapoff 关掉所有swap 然后正常运行任务，如果出现内存不足的提示，就需要逐步增加swap。

　　2 一般来讲,物理内存达到256m，在安装时即可不用划分交换分区。

　　3 可以在安装后建立交换分区，或者建立交换文件。