Thread: Re: [GENERAL] Multiple Indexing, performance impact
> Bruce Momjian <pgman@candle.pha.pa.us> writes: > > Strange that even at 1024 performance still drops off at 7. Seems it > > may be more than buffer thrashing. > > Yeah, if anything the knee in the curve seems to be worse at 1024 > buffers. Curious. Deserves more investigation, perhaps. > > This does remind me that I'd been thinking of suggesting that we > raise the default -B to something more reasonable, maybe 1000 or so > (yielding an 8-meg-plus shared memory area). This wouldn't prevent > people from setting it small if they have a small SHMMAX, but it's > probably time to stop letting that case drive our default setting. > Since 64 is already too much to let 7.1 fit in SHMMAX = 1MB, I think > the original rationale for using 64 is looking pretty broken anyway. > Comments? BSD/OS has a 4MB max but we document how to increase it by recompiling the kernel. Maybe if we fail the startup we can tell them how to decrease the buffers in postgresql.conf file. Seems quite clear. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> This does remind me that I'd been thinking of suggesting that we
>> raise the default -B to something more reasonable, maybe 1000 or so
>> (yielding an 8-meg-plus shared memory area).
> BSD/OS has a 4MB max but we document how to increase it by recompiling
> the kernel.
Hmm. Anyone like the idea of a platform-specific default established
by configure? We could set it in the template file on platforms where
the default SHMMAX is too small to allow 1000 buffers.
regards, tom lane
> Bruce Momjian <pgman@candle.pha.pa.us> writes: > >> This does remind me that I'd been thinking of suggesting that we > >> raise the default -B to something more reasonable, maybe 1000 or so > >> (yielding an 8-meg-plus shared memory area). > > > BSD/OS has a 4MB max but we document how to increase it by recompiling > > the kernel. > > Hmm. Anyone like the idea of a platform-specific default established > by configure? We could set it in the template file on platforms where > the default SHMMAX is too small to allow 1000 buffers. Template file seems like a good idea for platforms that can't handle the default. I don't think configure should be doing such tests because the target could be a different kernel. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> Hmm. Anyone like the idea of a platform-specific default established
>> by configure? We could set it in the template file on platforms where
>> the default SHMMAX is too small to allow 1000 buffers.
> Template file seems like a good idea for platforms that can't handle the
> default. I don't think configure should be doing such tests because the
> target could be a different kernel.
Right, I wasn't thinking of an actual run-time test in configure, just
that we could use it to let the OS-specific template file override the
normal default.
We could offer a --with switch to manually choose the default, too.
regards, tom lane
> Bruce Momjian <pgman@candle.pha.pa.us> writes: > >> Hmm. Anyone like the idea of a platform-specific default established > >> by configure? We could set it in the template file on platforms where > >> the default SHMMAX is too small to allow 1000 buffers. > > > Template file seems like a good idea for platforms that can't handle the > > default. I don't think configure should be doing such tests because the > > target could be a different kernel. > > Right, I wasn't thinking of an actual run-time test in configure, just > that we could use it to let the OS-specific template file override the > normal default. > > We could offer a --with switch to manually choose the default, too. Good idea, yes. Not sure if we need a --with switch because they can just edit the postgresql.conf or postgresql.conf.sample file. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> We could offer a --with switch to manually choose the default, too.
> Good idea, yes. Not sure if we need a --with switch because they can
> just edit the postgresql.conf or postgresql.conf.sample file.
Well, we have a --with switch for DEF_MAXBACKENDS, so one for the
default number of buffers doesn't seem too unreasonable. I wouldn't
bother with it if configure didn't have to touch the value anyway...
but it's just another line or two in configure.in...
regards, tom lane
> Bruce Momjian <pgman@candle.pha.pa.us> writes: > >> We could offer a --with switch to manually choose the default, too. > > > Good idea, yes. Not sure if we need a --with switch because they can > > just edit the postgresql.conf or postgresql.conf.sample file. > > Well, we have a --with switch for DEF_MAXBACKENDS, so one for the > default number of buffers doesn't seem too unreasonable. I wouldn't > bother with it if configure didn't have to touch the value anyway... > but it's just another line or two in configure.in... Yes, we could add that too, but now that we have postgresql.conf should we even be mentioning stuff like that in configure. In the old days we had a compiled-in limit but that is not true anymore, right? -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026
At 05:56 PM 22-06-2001 -0400, Bruce Momjian wrote: >> Bruce Momjian <pgman@candle.pha.pa.us> writes: >> Since 64 is already too much to let 7.1 fit in SHMMAX = 1MB, I think >> the original rationale for using 64 is looking pretty broken anyway. >> Comments? > >BSD/OS has a 4MB max but we document how to increase it by recompiling >the kernel. Maybe if we fail the startup we can tell them how to >decrease the buffers in postgresql.conf file. Seems quite clear. > Why is SHMMAX so low on some O/Ses? What are the advantages? My guess is it's a minimum vs median/popular situation. Get the same thing looking at the default www.kernel.org linux kernel settings vs the Redhat kernel settings. I'd personally prefer the popular situation. But would that mean the minimum case can't even boot up to recompile? Maybe the BSD guys should ship with two kernels then. FreeBSD esp, since it's easy to recompile the kernel, just do two, during installation default to "Regular", with an option for "Tiny". It's more fair that the people trying the extraordinary (16MB 386) should be the ones doing the extra work. Cheerio, Link.
Lincoln Yeoh <lyeoh@pop.jaring.my> writes:
> Why is SHMMAX so low on some O/Ses?
Historical artifact, I think: the SysV IPC code was developed on
machines that were tiny by current standards. Unfortunately, vendors
haven't stopped to review their kernel parameters and scale them up
appropriately.
regards, tom lane
> At 05:56 PM 22-06-2001 -0400, Bruce Momjian wrote: > >> Bruce Momjian <pgman@candle.pha.pa.us> writes: > >> Since 64 is already too much to let 7.1 fit in SHMMAX = 1MB, I think > >> the original rationale for using 64 is looking pretty broken anyway. > >> Comments? > > > >BSD/OS has a 4MB max but we document how to increase it by recompiling > >the kernel. Maybe if we fail the startup we can tell them how to > >decrease the buffers in postgresql.conf file. Seems quite clear. > > > > Why is SHMMAX so low on some O/Ses? What are the advantages? > > My guess is it's a minimum vs median/popular situation. Get the same thing > looking at the default www.kernel.org linux kernel settings vs the Redhat > kernel settings. > > I'd personally prefer the popular situation. But would that mean the > minimum case can't even boot up to recompile? Maybe the BSD guys should > ship with two kernels then. FreeBSD esp, since it's easy to recompile the > kernel, just do two, during installation default to "Regular", with an > option for "Tiny". > > It's more fair that the people trying the extraordinary (16MB 386) should > be the ones doing the extra work. I think the problem is that with a default-sized kernel, the little guys couldn't even boot the OS. Also, some of the OS's hard-wire things into the kernel for performance reasons. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026