Re: Solaris ISM Testing

The attached email shows that Solaris benefits from the ISM or Intimate
Shared Memory setting during shmat() shared memory creation. It causes
processes mapping the same shared memory to shared mapping pages _and_
locks the pages in RAM.

I know many OS's lock shared memory in RAM anyway, or have OS parameters
that control this (FreeBSD), but it seems Solaris does this on a per
shmat() basis. Should we add this flag to shmat() calls for Solaris?

Josh, can you supply a patch for our review?

---------------------------------------------------------------------------

P.J. "Josh" Rovero wrote:
> Bruce,
>
> Here are our results to date. Kind of mixed. We tested on both
> single processor (ultra 5 and ultra 10) and dual processor (ultra 60).
> Results here are from the Ultra60. On single processor boxes, there
> was a clear change in the disk and cpu activity when ISM was used.
> Without ISM there appeared to be lower cpu load and lots of disk i/0.
> With ISM, disk activity decreased dramatically, but cpu pegged periodically.
>
> All we did was change the flags on the shmat calls. I don't know if
> that's all that is really needed. At any rate, ISM doesn't *hurt*
> performance on Solaris, and can sometimes significantly improve it.
>
> I realize that these cases don't cover all aspects of postgres performance.
> Our local tests (LTC) are using real world data, and really aren't
> suitable for other folks to run. If there's a more comprehensive
> benchmark suite for postgres around, we'd be happy to run it.
>
> pg_bench -- 247% increase in tps with ISM ***before tuning pgsql****
> (from 34 to 84 tps)
> pg_bench -- 3% increase in tps with ISM ***after tuning pgsq****
> (from 80.5 to 83 tps)
> LTC 1 -- 9% increase with ISM (local test, 4500 complex inserts)
> *** before tuning ***
> -- 1% increase with ISM ***after tuning***
>
> LTC 2 -- 5% increase with ISM (local test, 415000 inserts to one table,
> 415000 updates to another, before
> tuning)
> -- 3% increase with ISM *** after tuning ***
>
> ISM seems to make the largest difference when an arbitrary, non-optimum,
> pgsql configuration is used. There was not a huge difference in the
> before and after tuning configurations.
>
> Ultra 60 with 512 MB RAM, 2x450 MHz UltraSparc II.
>
> Before: max_connections = 24
> shared_buffers = 3072
> sort_mem = 8192
> vacuum_mem = 16384
> shmmax = 2640000
>
> After: max_connections = 32
> shared_buffers = 3294
> sort_mem = 8192
> vacuum_mem = 16384
> shmmax = 28278784
>
>
> --
> P. J. "Josh" Rovero Sonalysts, Inc.
> Email: rovero(at)sonalysts(dot)com www.sonalysts.com 215 Parkway North
> Work: (860)326-3671 or 442-4355 Waterford CT 06385
> ***********************************************************************
>
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026