Re: Solaris shared_buffers anomaly?

From: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
To: Mischa Sandberg <mischa(at)ca(dot)sophos(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Solaris shared_buffers anomaly?
Date: 2006-06-14 03:35:39
Message-ID: 20060614033539.GY34196@pervasive.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Tue, Jun 13, 2006 at 05:01:34PM -0700, Mischa Sandberg wrote:
> Jim C. Nasby wrote:
> >On Tue, Jun 13, 2006 at 04:20:34PM -0700, Mischa Sandberg wrote:
> >>Jim C. Nasby wrote:
> >>>What's sort_mem set to? I suspect you simply ran the machine out of
> >>>memory.
> >>8192 (8MB). No issue when shared_buffers was 2000; same apps always.
> >
> >So if all 50 backends were running a sort, you'd use 400MB. The box has
> >4G, right?
>
> Umm ... yes. "if". 35-40 of them are doing pure INSERTS.
> Not following your train.

If sort_mem is set too high and a bunch of sorts fire off at once,
you'll run the box out of memory and it'll start swapping. Won't really
matter much whether it's swapping shared buffers or not; performance
will just completely tank.

Actually, I think that Solaris can be pretty aggressive about swapping
stuff out to try and cache more data. Perhaps that's what's happening?

> >>Yep, tested /etc/system segmap_percent at 20,40,60.
> >>No significant difference between 20 and 60.
> >That's pretty disturbing... how large is your database?
>
> ~10GB. Good locality. Where heading?

I guess I should have asked what your working set size was... unless
that's very small, it doesn't make sense that changing the cache size
that much wouldn't help things.

BTW, on some versions of Solaris, segmap_percent doesn't actually work;
you have to change something else that's measured in bytes.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Greg Stark 2006-06-14 04:15:30 Re: OT - select + must have from - sql standard syntax?
Previous Message Tom Lane 2006-06-14 02:44:29 Re: OT - select + must have from - sql standard syntax?