On Thu, Jan 27, 2011 at 6:36 AM, Michael Kohl wrote:
> Cédric, thanks a lot for your answer so far!
>
> On Thu, Jan 27, 2011 at 12:24 PM, Cédric Villemain
> wrote:
>
>> you have swap used, IO on the swap partition ?
>
> Memory-wise we are fine.
>
>> can you paste the /proc/meminfo ?
>
> Sure:
>
>
On Mon, Jan 3, 2011 at 9:28 PM, Greg Smith wrote:
> Mladen Gogala wrote:
>>
>> Rich wrote:
>>>
>>> I am wondering why anyone would do that? Too much overhead and no
>>> reliable enough.
>>
>> Apparently, NetApp thinks that it is reliable. They're selling that
>> stuff for years. I know that O
On Tue, Dec 7, 2010 at 1:55 AM, Tom Lane wrote:
> Greg Smith writes:
>> And the expensive part of the overhead beyond the delay itself is
>> CountActiveBackends(), which iterates over the entire procArray
>> structure.
>
> I could have sworn we'd refactored that to something like
> bool Th
On Tue, Dec 7, 2010 at 10:59 AM, Jignesh Shah wrote:
> On Tue, Dec 7, 2010 at 1:10 AM, Robert Haas wrote:
>> On Sun, Nov 21, 2010 at 7:15 PM, Ivan Voras wrote:
>>> The "sbwait" part is from FreeBSD - IPC sockets, but so much blocking on
>>> semwait ind
On Tue, Dec 7, 2010 at 1:10 AM, Robert Haas wrote:
> On Sun, Nov 21, 2010 at 7:15 PM, Ivan Voras wrote:
>> The "sbwait" part is from FreeBSD - IPC sockets, but so much blocking on
>> semwait indicates large contention in PostgreSQL.
>
> I can reproduce this. I suspect, but cannot yet prove, that
On Mon, Dec 6, 2010 at 12:35 PM, Greg Smith wrote:
> Jignesh Shah wrote:
>>
>> The commit_siblings = 5 basically checks that it sleeps only when that
>> many backends are active. This I think is a very expensive check and I
>> would rather make commit_siblings=0 (whic
On Mon, Dec 6, 2010 at 10:47 AM, Rob Wultsch wrote:
> On Sun, Dec 5, 2010 at 7:30 PM, Jignesh Shah wrote:
>> The commit_siblings = 5 basically checks that it sleeps only when that
>> many backends are active. This I think is a very expensive check and I
>> would rather m
On Mon, Dec 6, 2010 at 4:40 AM, Rob Wultsch wrote:
> Manual:
> http://www.postgresql.org/docs/9.0/static/runtime-config-wal.html#RUNTIME-CONFIG-WAL-SETTINGS
> Recent discussion:
> http://www.facebook.com/notes/mysql-at-facebook/group-commit-in-postgresql/465781235932
>
> It is my understanding th
On Sun, Nov 21, 2010 at 9:18 PM, Ivan Voras wrote:
> On 11/22/10 02:47, Kevin Grittner wrote:
>>
>> Ivan Voras wrote:
>>
>>> After 16 clients (which is still good since there are only 12
>>> "real" cores in the system), the performance drops sharply
>>
>> Yet another data point to confirm the imp
On Tue, Nov 16, 2010 at 8:22 PM, Tom Lane wrote:
> Josh Berkus writes:
>>> Well, we're not going to increase the default to gigabytes, but we could
>>> very probably increase it by a factor of 10 or so without anyone
>>> squawking. It's been awhile since I heard of anyone trying to run PG in
>>>
On Tue, Jun 29, 2010 at 9:39 PM, Bruce Momjian wrote:
> Jignesh Shah wrote:
>> On Tue, Jun 29, 2010 at 2:45 PM, Bruce Momjian wrote:
>> > Tom Lane wrote:
>> >> Bruce Momjian writes:
>> >> >>> I asked on IRC and was told it is true, and l
On Tue, Jun 29, 2010 at 2:45 PM, Bruce Momjian wrote:
> Tom Lane wrote:
>> Bruce Momjian writes:
>> >>> I asked on IRC and was told it is true, and looking at the C code it
>> >>> looks true. ?What synchronous_commit = false does is to delay writing
>> >>> the wal buffers to disk and fsyncing the
On Fri, May 7, 2010 at 8:09 PM, Josh Berkus wrote:
> Jignesh, All:
>
> Most of our Solaris users have been, I think, following Jignesh's advice
> from his benchmark tests to set ZFS page size to 8K for the data zpool.
> However, I've discovered that this is sometimes a serious problem for
> some
But we still pay the penalty on WAL while writing them in the first
place I guess .. Is there an option to disable it.. I can test how much
is the impact I guess couple of %s but good to verify :-) )
Regards,
Jignesh
Alvaro Herrera wrote:
Jignesh Shah escribió:
Now comes the thing
Hello Ian,
I have done some testing with postgresql and ZFS on Solaris 10 11/06.
While I work for Sun, I dont claim to be a ZFS expert (for that matter
not even Solaris or PostgreSQL).
Lets first look at the scenarios of how postgresql can be deployed on
Solaris
First the Solaris Options
1.
Hello All,
I am using the latest 8.2 source that I compiled with Sun Studio 11 and
tested it on Solaris 10 11/06 against an app server. I find that the CPU
utilization was higher than I expected and started digging through it.
Aparently the top CPU usage comes from the following stack trace w
Steve,
Are you using the latest update release of Solaris 10 ?
When you are doing the copy, did you check with prstat -amL to see if it
is saturating on any CPU?
If it is saturating on a CPU then atleast it will narrow down that you
need to improve the CPU utilization of the copy process.
Hi Arjen,
I am curious about your Sun Studio compiler options also.
Can you send that too ?
Any other tweakings that you did on Solaris?
Thanks.
Regards,
Jignesh
Arjen van der Meijden wrote:
On 29-7-2006 19:01, Joshua D. Drake wrote:
Well I would be curious about the postgresql.conf and how
,
Jignesh
- Original Message -
From: Luke Lonergan <[EMAIL PROTECTED]>
Date: Monday, December 19, 2005 2:38 pm
Subject: Re: [PERFORM] PostgreSQL and Ultrasparc T1
To: Jignesh Shah <[EMAIL PROTECTED]>
Cc: Juan Casero <[EMAIL PROTECTED]>, pgsql-performance@postgresql.org
> J
PostgreSQL, do let me know also with your
experience.
Regards,
Jignesh
- Original Message -
From: Luke Lonergan <[EMAIL PROTECTED]>
Date: Monday, December 19, 2005 12:31 pm
Subject: Re: [PERFORM] PostgreSQL and Ultrasparc T1
To: Jignesh Shah <[EMAIL PROTECTED]>
Cc: Ju
solve
> this
> > problem.
> >
> > I actually vote for a multi-threaded solution for each connection
> while
> > still maintaining seperate process for each connections... This
> way the
> > fundamental architecture of Postgres doesn't change, however a
> >
> Does that include increasing the size of read/write blocks? I've
> noticedthat with a large enough table it takes a while to do a
> sequential scan,
> even if it's cached; I wonder if the fact that it takes a million
> read(2) calls to get through an 8G table is part of that.
>
Actually some
s,
Jignesh
Original Message Follows
From: Tom Lane <[EMAIL PROTECTED]>
To: "Jignesh Shah" <[EMAIL PROTECTED]>
CC: pgsql-performance@postgresql.org
Subject: Re: [PERFORM] MemoryContextSwitchTo during table scan?
Date: Mon, 22 Aug 2005 11:41:40 -0400
"Jignesh Shah&quo
Hello,
I am running PostgreSQL 8.0.x on Solaris 10 AMD64. My Tablesize for this
test is about 80G. When I run a query on a column which is not indexed, I
get a full table scan query and that's what I am testing right now. (I am
artificially creating that scenario to improve that corner case)
Hi Paul,
I was passed your message... regarding DSS workload with Postgres on Solaris.
(I am not in the alias).
Performance is relative to your workload. Can you actually send us what you are
doing in your queries, updates etc?
I have been running few tests myself and here are my rules of thum
25 matches
Mail list logo
