Thread: shared_buffer optimization
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I have a question with shared_buffer. Ok, I have a server with 4GB of RAM - ----- # cat /proc/meminfo MemTotal: 4086484 kB [...] - ----- So, if I want to, for example, shared_buffer to take 3 GB of RAM then shared_buffer would be 393216 (3 * 1024 * 1024 / 8) Postmaster dont start. Error: FATAL: shmat(id=360448) failed: Invalid argument I can set a less value, but not higher than 3 GB. Am I doing something wrong? Any idea? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE2GoAIo1XmbAXRboRAtPgAJ9HN7aL0lyFtyTZnOoIAJXmGNsomgCeI1ex II1MclZaaIjg/ryH08wCuAY= =cgwJ -----END PGP SIGNATURE-----
Quoth ruben@rentalia.com (Ruben Rubio): > Hi, I have a question with shared_buffer. > > Ok, I have a server with 4GB of RAM > ----- > # cat /proc/meminfo > MemTotal: 4086484 kB > [...] > ----- > > So, if I want to, for example, shared_buffer to take 3 GB of RAM then > shared_buffer would be 393216 (3 * 1024 * 1024 / 8) > > Postmaster dont start. > Error: FATAL: shmat(id=360448) failed: Invalid argument > > > I can set a less value, but not higher than 3 GB. > > Am I doing something wrong? > Any idea? Yes, you're trying to set the value way too high. The "rule of thumb" is to set shared buffers to the lesser of 10000 and 15% of system memory. In your case, that would be the lesser of 10000 and 78643, which is 10000. I'm not aware of any actual evidence having emerged that it is of any value to set shared buffers higher than 10000. -- let name="cbbrowne" and tld="acm.org" in name ^ "@" ^ tld;; http://linuxdatabases.info/info/x.html Rules of the Evil Overlord #25. "No matter how well it would perform, I will never construct any sort of machinery which is completely indestructible except for one small and virtually inaccessible vulnerable spot." <http://www.eviloverlord.com/>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 So ... I have tried different values. The best one for one day sentences seems to be 24576 IO in vmstat has the lowest values "id" (idle) has the biggest values. I have created an script that executes all day sentences to try that. By the way, could u explain a little bit this? "The "rule of thumb" is to set shared buffers to the lesser of 10000 and 15% of system memory. In your case, that would be the lesser of 10000 and 78643, which is 10000." Im sorry but im not understanding it at all. Thanks in advance. Christopher Browne wrote: > Quoth ruben@rentalia.com (Ruben Rubio): >> Hi, I have a question with shared_buffer. >> >> Ok, I have a server with 4GB of RAM >> ----- >> # cat /proc/meminfo >> MemTotal: 4086484 kB >> [...] >> ----- >> >> So, if I want to, for example, shared_buffer to take 3 GB of RAM then >> shared_buffer would be 393216 (3 * 1024 * 1024 / 8) >> >> Postmaster dont start. >> Error: FATAL: shmat(id=360448) failed: Invalid argument >> >> >> I can set a less value, but not higher than 3 GB. >> >> Am I doing something wrong? >> Any idea? > > Yes, you're trying to set the value way too high. > > The "rule of thumb" is to set shared buffers to the lesser of 10000 > and 15% of system memory. In your case, that would be the lesser of > 10000 and 78643, which is 10000. > > I'm not aware of any actual evidence having emerged that it is of any > value to set shared buffers higher than 10000. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFE2b3kIo1XmbAXRboRAh12AKCodmhmXZWamrG7MnAf9mhVfubjgwCfa75v 7bgmSzq4F7XpBoEkSpyDqnE= =3lMc -----END PGP SIGNATURE-----
On Tue, Aug 08, 2006 at 08:20:01AM -0400, Christopher Browne wrote: > I'm not aware of any actual evidence having emerged that it is of any > value to set shared buffers higher than 10000. http://flightaware.com They saw a large increase in how many concurrent connections they could handle when they bumped shared_buffers up from ~10% to 50% of memory. Back then they had 4G of memory. They're up to 12G right now, but haven't bumped shared_buffers up. Every single piece of advice I've seen on shared_buffers comes from the 7.x era, when our buffer management was extremely simplistic. IMO all of that knowledge was made obsolete when 8.0 came out, and our handling of shared_buffers has improved ever further since then. This is definately an area that could use a lot more testing. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
"Jim C. Nasby" <jnasby@pervasive.com> writes:
> Every single piece of advice I've seen on shared_buffers comes from the
> 7.x era, when our buffer management was extremely simplistic. IMO all of
> that knowledge was made obsolete when 8.0 came out, and our handling of
> shared_buffers has improved ever further since then. This is definately
> an area that could use a lot more testing.
Actually I think it was probably 8.1 that made the significant
difference there, by getting rid of the single point of contention
for shared-buffer management. I concur that 7.x-era rules of thumb
may well be obsolete --- we need some credible scaling tests ...
regards, tom lane