- 论坛徽章:
- 0
|
关于linux交换分区大小的问题
关于本贴的最后答案，来自于Linus Torvalds和他的朋友们的讨论
2. Greater 2.4 Swap Requirements
7 Jan 2001 - 18 Jan 2001 (100 posts) Archive Link: "Subtle MM bug"
Topics: Virtual Memory
People: Rik van Riel, Linus Torvalds, Eric W. Biederman, Zlatko Calusic
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的流量。
最后，关于本贴早先的问题，究竟分多大的分区为宜，在查阅了一些资料后，对本问题我目前的最终看法，并且我也将按照如下方法分配交换区：
1. 交换区最小不低于4G
建立两个各为2G的交换区，做为基础的4G交换分区
2. 建立8个2G的交换文件，做为扩展的交换分区
这样总的交换分区大概在20G左右，如果硬盘更大，可以增加最多。
谢谢网中人提出的一系列问题，我也可以对您的按照系统运行状况来分配交换区的提议，做出答复：按照Linus的建议，可以不必要考虑这些。Linux 2.4.x内核会在大的交换区情况下，运行的更好。 |
|
免费注册
楼主: wangrujun
发表于 2005-06-23 10:32
