Re: Linux2.6 overcommit behaviour
От | Andrew Dunstan |
---|---|
Тема | Re: Linux2.6 overcommit behaviour |
Дата | |
Msg-id | 3F51FFE0.4080503@dunslane.net обсуждение исходный текст |
Ответ на | Re: Linux2.6 overcommit behaviour (Manfred Spraul <manfred@colorfullife.com>) |
Ответы |
Re: Linux2.6 overcommit behaviour
|
Список | pgsql-hackers |
Manfred Spraul wrote: >> >> It is strange to choose 50% of RAM plus swap (what if your spam is >> small). I thought it would be 100% of RAM plus the swap that exceeds RAM >> size. >> >> > Linux doesn't release the swap file page when a page is read back: If > a page is only read by the user space app, then the swapped out page > remains valid, and thus the kernel can skip the write to disk on the > next swapout. Thus if you are paranoid, you must limit the total > address space to the size of your swap files. > If your swap space (your wrote "spam" - I assume a typo) is small, > then you'll run into problems. It's recommended that your swap space > should be 2*physical memory. I assume that many oom killer reports are > from system with too small swap files, and then an updatedb run pushes > the system into oom. I believe that the swap slot can be subsequently freed, though. In theory your available virtual memory should be (almost) RAM+swap. In practice, Linux can run too close to that limit, (or way over it if you turn the checks off). But restricting the maximum possible pages to RAM/2 + swap should normally be fine. IANAKH, though. Also note that the truly bad thing about the OOM killer is that it can affect a process that is not making any new memory demands at all. cheers andrew
В списке pgsql-hackers по дате отправления: