Re: [GENERAL] Max Shared Memory
От | Andrew Sullivan |
---|---|
Тема | Re: [GENERAL] Max Shared Memory |
Дата | |
Msg-id | 20020830105120.B10695@mail.libertyrms.com обсуждение исходный текст |
Ответ на | Max Shared Memory (Ericson Smith <eric@did-it.com>) |
Список | pgsql-admin |
On Fri, Aug 30, 2002 at 08:33:08AM -0400, Ericson Smith wrote: > Hi, > > We have a server with 4GB of RAM running RH7.3 with stock kernel and > Postgresql 7.2 > > Currently we have 1.6GB Shared Memory installed. What is the max amount > of shared memory we can allocate here? Does anyone have any real world > experience with large shared memory installations that could help? There has been a _lot_ of discussion on this matter recently on the list -- you might want to check the archives from the last few months. There are three schools of thought: 1. Set the shared buffers to a large-ish, but not huge setting (maybe 25% of physical memory), and let the filesystem buffers handle the rest. 2. Keep increasing the shared buffers setting until you start to cause swapping, and then ease back. 3. Set the shared buffers to some basic, minimal setting -- a few thousand, perhaps -- and let the filesystem buffers handle most of the traffic, since a call to the filesystem buffer isn't that expensive anyway. The argument against 1 (and in favour of 3) is that 1 more or less causes you to cache twice: once in the shared buffer, and once in the filesystem buffer. The argument against 2 is that it is extremely easy to get it wrong, and to cause accidental swapping. The argument against 3 is that it costs more than nothing to make the kernel call to get the filesystem buffer, and all those little more than nothing costs add up. The best way to decide for your case is to try various settings, and run some benchmarks. But that is extremely tricky to get good results from; I have tried dozens of combinations, and each one has its limitations, at least on Solaris. I used to be a very big fan of 3, but I have found that some larger amount of memory in the shared buffer (more than half a gig, anyway) pays off on Solaris in a way I never found it doing on Linux. A -- ---- Andrew Sullivan 204-4141 Yonge Street Liberty RMS Toronto, Ontario Canada <andrew@libertyrms.info> M2P 2A8 +1 416 646 3304 x110
В списке pgsql-admin по дате отправления: