On 3/15/09 1:40 PM, Jignesh K. Shah wrote:
decibel wrote:
On Mar 11, 2009, at 10:48 PM, Jignesh K. Shah wrote:
Fair enough.. Well I am now appealing to all who has a fairly decent
sized hardware want to try it out and see whether there are "gains",
"no-changes" or "regressions" based on your
Robert Haas wrote:
On Fri, Mar 20, 2009 at 7:39 PM, Jignesh K. Shah wrote:
Alvaro Herrera wrote:
So Simon's correct.
And perhaps this explains why Jignesh is measuring an improvement on his
benchmark. Perhaps an useful experiment would be to turn this behavior
off and comp
On Fri, 2009-03-20 at 15:28 +, Matthew Wakeling wrote:
> On Thu, 19 Mar 2009, Scott Carey wrote:
> > In type B, the ratio of requests that must context switch is always ==
> > 1. Every request must queue and wait!
>
> A remarkably good point, although not completely correct. Every request
On Fri, Mar 20, 2009 at 7:39 PM, Jignesh K. Shah wrote:
> Alvaro Herrera wrote:
>>> So Simon's correct.
>> And perhaps this explains why Jignesh is measuring an improvement on his
>> benchmark. Perhaps an useful experiment would be to turn this behavior
>> off and compare performance. This lack
Alvaro Herrera wrote:
Alvaro Herrera escribió:
So Simon's correct.
And perhaps this explains why Jignesh is measuring an improvement on his
benchmark. Perhaps an useful experiment would be to turn this behavior
off and compare performance. This lack of measurement is probably the
Alvaro Herrera escribió:
> So Simon's correct.
And perhaps this explains why Jignesh is measuring an improvement on his
benchmark. Perhaps an useful experiment would be to turn this behavior
off and compare performance. This lack of measurement is probably the
cause that the suggested patch to
Alvaro Herrera escribió:
> Simon's explanation, however, is at odds with the code.
>
> http://git.postgresql.org/?p=postgresql.git;a=blob;f=src/backend/storage/lmgr/lwlock.c
>
> There is "queue jumping" in the regular (heavyweight) lock manager, but
> that's a pretty different body of code.
I'l
On 3/20/09 8:28 AM, "Matthew Wakeling" wrote:
> On Thu, 19 Mar 2009, Scott Carey wrote:
>> In type B, the ratio of requests that must context switch is always ==
>> 1. Every request must queue and wait!
>
> A remarkably good point, although not completely correct. Every request
> that arrives
Matthew Wakeling writes:
> As for ProcArrayLock, it sounds like it is very much a special case.
Quite. Read the section "Interlocking Transaction Begin, Transaction
End, and Snapshots" in src/backend/access/transam/README before
proposing any changes in this area --- it's a lot more delicate tha
Scott Carey escribió:
> Your description (much of which I cut out) is exactly how I understood
> it until Simon Riggs' post which changed my view and understanding.
> Under that situation, waking all shared will leave all X at the
> front and hence alternate shared/exclusive/shared/exclusive a
On Thu, 19 Mar 2009, Scott Carey wrote:
In type B, the ratio of requests that must context switch is always ==
1. Every request must queue and wait!
A remarkably good point, although not completely correct. Every request
that arrives when the lock is held in any way already will queue and wai
] Proposal of tunable fix for scalability of 8.4
> On Mon, 2009-03-16 at 16:26 +, Matthew Wakeling wrote:
> > One possibility would be for the locks to alternate between exclusive
> > and
> > shared - that is:
> >
> > 1. Take a snapshot of all shared waits, an
From: Robert Haas [robertmh...@gmail.com]
Sent: Thursday, March 19, 2009 8:45 PM
To: Scott Carey
Cc: Jignesh K. Shah; Greg Smith; Kevin Grittner;
pgsql-performance@postgresql.org
Subject: Re: [PERFORM] Proposal of tunable fix for scalability of 8.4
>
> >On Thu, Mar 19, 2009 at 5:43
On Thu, Mar 19, 2009 at 5:43 PM, Scott Carey wrote:
>> Well, unless I'm misunderstanding something, waking all waiters every
>> time could lead to arbitrarily long delays for writers on mostly
>> read-only workloads... and by arbitrarily along, we mean to say
>> "potentially just about forever".
Scott Carey wrote:
> On 3/19/09 10:37 AM, "Bruce Momjian" wrote:
>
> > Robert Haas wrote:
> >>> The original poster's request is for a config parameter, for
> >>> experimentation
> >>> and testing by the brave. My own request was for that version of the lock
> >>> to
> >>> prevent possible star
Robert Haas wrote:
Actually the patch I submitted shows no overhead from what I have seen and I
think it is useful depending on workloads where it can be turned on even on
production.
Well, unless I'm misunderstanding something, waking all waiters every
time could lead to arbitrarily lo
On 3/19/09 1:49 PM, "Robert Haas" wrote:
>> Actually the patch I submitted shows no overhead from what I have seen and I
>> think it is useful depending on workloads where it can be turned on even on
>> production.
>
> Well, unless I'm misunderstanding something, waking all waiters every
> tim
On 3/19/09 10:37 AM, "Bruce Momjian" wrote:
> Robert Haas wrote:
>>> The original poster's request is for a config parameter, for experimentation
>>> and testing by the brave. My own request was for that version of the lock to
>>> prevent possible starvation but improve performance by unlocking a
On 3/18/09 2:25 PM, "Robert Haas" wrote:
> On Wed, Mar 18, 2009 at 1:43 PM, Scott Carey wrote:
Its worth ruling out given that even if the likelihood is small, the fix is
easy. However, I don¹t see the throughput drop from peak as more
concurrency is added that is the hallmark of
> Actually the patch I submitted shows no overhead from what I have seen and I
> think it is useful depending on workloads where it can be turned on even on
> production.
Well, unless I'm misunderstanding something, waking all waiters every
time could lead to arbitrarily long delays for writers o
Robert Haas wrote:
> > The original poster's request is for a config parameter, for experimentation
> > and testing by the brave. My own request was for that version of the lock to
> > prevent possible starvation but improve performance by unlocking all shared
> > at once, then doing all exclusives
On Wed, 2009-03-18 at 13:49 +, Matthew Wakeling wrote:
> On Wed, 18 Mar 2009, Jignesh K. Shah wrote:
> > I thought about that.. Except without putting a restriction a huge queue
> > will cause lot of time spent in manipulating the lock
> > list every time. One more thing will be to maintain t
On Wed, 2009-03-18 at 16:26 -0400, Tom Lane wrote:
> Simon Riggs writes:
> > On Mon, 2009-03-16 at 16:26 +, Matthew Wakeling wrote:
> >> One possibility would be for the locks to alternate between exclusive
> >> and
> >> shared - that is:
> >>
> >> 1. Take a snapshot of all shared waits, an
On 03/18/09 17:25, Robert Haas wrote:
On Wed, Mar 18, 2009 at 1:43 PM, Scott Carey wrote:
Its worth ruling out given that even if the likelihood is small, the fix is
easy. However, I don¹t see the throughput drop from peak as more
concurrency is added that is the hallmark of this problem
On 03/18/09 17:16, Scott Carey wrote:
On 3/18/09 4:36 AM, "Gregory Stark" wrote:
"Jignesh K. Shah" writes:
In next couple of weeks I plan to test the patch on a different x64 based
system to do a sanity testing on lower number of cores and also try out other
workloads ...
On Wed, Mar 18, 2009 at 1:43 PM, Scott Carey wrote:
>>> Its worth ruling out given that even if the likelihood is small, the fix is
>>> easy. However, I don¹t see the throughput drop from peak as more
>>> concurrency is added that is the hallmark of this problem < usually with a
>>> lot of contex
On 3/18/09 4:36 AM, "Gregory Stark" wrote:
>
>
> "Jignesh K. Shah" writes:
>
>> In next couple of weeks I plan to test the patch on a different x64 based
>> system to do a sanity testing on lower number of cores and also try out other
>> workloads ...
>
> I'm actually more interested in the
Simon Riggs writes:
> On Mon, 2009-03-16 at 16:26 +, Matthew Wakeling wrote:
>> One possibility would be for the locks to alternate between exclusive
>> and
>> shared - that is:
>>
>> 1. Take a snapshot of all shared waits, and grant them all -
>> thundering
>> herd style.
>> 2. Wait until A
On 3/12/09 6:29 PM, "Robert Haas" wrote:
>> Its worth ruling out given that even if the likelihood is small, the fix is
>> easy. However, I don¹t see the throughput drop from peak as more
>> concurrency is added that is the hallmark of this problem < usually with a
>> lot of context switching an
On Wed, 18 Mar 2009, Jignesh K. Shah wrote:
I thought about that.. Except without putting a restriction a huge queue will
cause lot of time spent in manipulating the lock
list every time. One more thing will be to maintain two list shared and
exclusive and round robin through them for every tim
On 03/18/09 08:06, Simon Riggs wrote:
On Wed, 2009-03-18 at 11:45 +, Matthew Wakeling wrote:
On Wed, 18 Mar 2009, Simon Riggs wrote:
I agree with that, apart from the "granting no more" bit.
The most useful behaviour is just to have two modes:
* exclusive-lock held - all other x
On Wed, 18 Mar 2009, Simon Riggs wrote:
On Wed, 2009-03-18 at 11:45 +, Matthew Wakeling wrote:
The problem with making all other locks welcome is that there is a
possibility of starvation. Imagine a case where there is a constant stream
of shared locks - the exclusive locks may never actuall
On Wed, 2009-03-18 at 11:45 +, Matthew Wakeling wrote:
> On Wed, 18 Mar 2009, Simon Riggs wrote:
> > I agree with that, apart from the "granting no more" bit.
> >
> > The most useful behaviour is just to have two modes:
> > * exclusive-lock held - all other x locks welcome, s locks queue
> > *
On Wed, 18 Mar 2009, Heikki Linnakangas wrote:
A linked list or an array of in-progress writes was my first thought as well.
But the real problem is: how does the reader wait until all WAL up to X have
been written? It could poll, but that's inefficient.
Good point - waiting for an exclusive l
Matthew Wakeling wrote:
On Sat, 14 Mar 2009, Heikki Linnakangas wrote:
It's going require some hard thinking to bust that bottleneck. I've
sometimes thought about maintaining a pre-calculated array of
in-progress XIDs in shared memory. GetSnapshotData would simply
memcpy() that to private memo
On Wed, 18 Mar 2009, Simon Riggs wrote:
I agree with that, apart from the "granting no more" bit.
The most useful behaviour is just to have two modes:
* exclusive-lock held - all other x locks welcome, s locks queue
* shared-lock held - all other s locks welcome, x locks queue
The problem with
"Jignesh K. Shah" writes:
> In next couple of weeks I plan to test the patch on a different x64 based
> system to do a sanity testing on lower number of cores and also try out other
> workloads ...
I'm actually more interested in the large number of cores but fewer processes
and lower max_conne
On Mon, 2009-03-16 at 16:26 +, Matthew Wakeling wrote:
> One possibility would be for the locks to alternate between exclusive
> and
> shared - that is:
>
> 1. Take a snapshot of all shared waits, and grant them all -
> thundering
> herd style.
> 2. Wait until ALL of them have finished,
On Sat, 2009-03-14 at 12:09 -0400, Tom Lane wrote:
> Heikki Linnakangas writes:
> > WALInsertLock is also quite high on Jignesh's list. That I've seen
> > become the bottleneck on other tests too.
>
> Yeah, that's been seen to be an issue before. I had the germ of an idea
> about how to fix th
On Tue, 2009-03-17 at 19:54 -0400, Jignesh K. Shah wrote:
>
> Simon Riggs wrote:
> > On Tue, 2009-03-17 at 17:41 -0400, Jignesh K. Shah wrote:
> >
> >
> >> I did a quick test with patch. Unfortunately it improves my number
> >> even with default setting 0 (not sure whether I should be pleased
Simon Riggs wrote:
On Tue, 2009-03-17 at 17:41 -0400, Jignesh K. Shah wrote:
I did a quick test with patch. Unfortunately it improves my number
even with default setting 0 (not sure whether I should be pleased or
sad - Definitely no overhead infact seems to help performance a bit.
NOTE: Lo
On Tue, 2009-03-17 at 17:41 -0400, Jignesh K. Shah wrote:
> I did a quick test with patch. Unfortunately it improves my number
> even with default setting 0 (not sure whether I should be pleased or
> sad - Definitely no overhead infact seems to help performance a bit.
> NOTE: Logic is same, imple
On 03/16/09 13:39, Simon Riggs wrote:
On Wed, 2009-03-11 at 22:20 -0400, Jignesh K. Shah wrote:
A tunable does not impact existing behavior
Why not put the tunable parameter into the patch and then show the test
results with it in? If there is no overhead, we should then be able to
see that
Simon Riggs wrote:
On Wed, 2009-03-11 at 22:20 -0400, Jignesh K. Shah wrote:
A tunable does not impact existing behavior
Why not put the tunable parameter into the patch and then show the test
results with it in? If there is no overhead, we should then be able to
see that.
Can
On Wed, 2009-03-11 at 22:20 -0400, Jignesh K. Shah wrote:
> A tunable does not impact existing behavior
Why not put the tunable parameter into the patch and then show the test
results with it in? If there is no overhead, we should then be able to
see that.
--
Simon Riggs www.2ndQuad
On 03/16/09 11:08, Gregory Stark wrote:
"Jignesh K. Shah" writes:
Generally when there is dead constant.. signs of classic bottleneck ;-) We
will be fixing one to get to another.. but knocking bottlenecks is the name of
the game I think
Indeed. I think the bottleneck we're interes
Note, some have mentioned that my client breaks inline formatting. My only
comment is after Kevin's signature below:
On 3/16/09 9:53 AM, "Kevin Grittner" wrote:
I wrote:
> One more reason this point is an interesting one is that it is one
> that gets *worse* with the suggested patch, if only b
I wrote:
> One more reason this point is an interesting one is that it is one
> that gets *worse* with the suggested patch, if only by half a
percent.
>
> Without:
>
> 600: 80: Medium Throughput: 82632.000 Avg Medium Resp: 0.005
>
> with:
>
> 600: 80: Medium Throughput: 82241.000 Avg Mediu
On Sat, 14 Mar 2009, Heikki Linnakangas wrote:
I think the elephant in the room is that we have a single lock that needs to
be acquired every time a transaction commits, and every time a backend takes
a snapshot.
I like this line of thinking.
There are two valid sides to this. One is the elep
wrote:
> On Fri, 13 Mar 2009, Kevin Grittner wrote:
>> If all data access is in RAM, why can't 80 processes
>> keep 64 threads (on 8 processors) busy? Does anybody else think
>> that's an interesting question, or am I off in left field here?
>
> I don't think that anyone is arguing that it's no
"Jignesh K. Shah" writes:
> Generally when there is dead constant.. signs of classic bottleneck ;-) We
> will be fixing one to get to another.. but knocking bottlenecks is the name of
> the game I think
Indeed. I think the bottleneck we're interested in addressing here is why you
say you weren'
decibel wrote:
On Mar 13, 2009, at 3:02 PM, Jignesh K. Shah wrote:
vmstat seems similar to wakeup some
kthr memorypagedisk faults
cpu
r b w swap free re mf pi po fr de sr s0 s1 s2 sd in sy cs
us sy id
63 0 0 45535728 38689856 0 14 0 0 0
decibel wrote:
On Mar 11, 2009, at 10:48 PM, Jignesh K. Shah wrote:
Fair enough.. Well I am now appealing to all who has a fairly
decent sized hardware want to try it out and see whether there are
"gains", "no-changes" or "regressions" based on your workload. Also
it will help if you rep
Simon Riggs wrote:
On Wed, 2009-03-11 at 16:53 -0400, Jignesh K. Shah wrote:
1200: 2000: Medium Throughput: -1781969.000 Avg Medium Resp: 0.019
I think you need to iron out bugs in your test script before we put too
much stock into the results generated. Your throughput should not b
: [PERFORM] Proposal of tunable fix for scalability of 8.4
Yeah, that's been seen to be an issue before. I had the germ of an idea
about how to fix that:
... with no lock, determine size of WAL record ...
obtain WALInsertLock
identify WAL start address of my record, ad
On Mar 13, 2009, at 3:02 PM, Jignesh K. Shah wrote:
vmstat seems similar to wakeup some
kthr memorypagedisk
faults cpu
r b w swap free re mf pi po fr de sr s0 s1 s2 sd in sy
cs us sy id
63 0 0 45535728 38689856 0 14 0 0 0 0 0 0 0 0 0
On Mar 13, 2009, at 8:05 AM, Gregory Stark wrote:
"Jignesh K. Shah" writes:
Scott Carey wrote:
On 3/12/09 11:37 AM, "Jignesh K. Shah" wrote:
In general, I suggest that it is useful to run tests with a few
different
types of pacing. Zero delay pacing will not have realistic number of
conn
On Mar 12, 2009, at 2:22 PM, Jignesh K. Shah wrote:
Something that might be useful for him to report is the avg number
of active backends for each data point ...
short of doing select * from pg_stat_activity and removing the IDLE
entries, any other clean way to get that information.
Uh, isn
On Mar 11, 2009, at 10:48 PM, Jignesh K. Shah wrote:
Fair enough.. Well I am now appealing to all who has a fairly
decent sized hardware want to try it out and see whether there are
"gains", "no-changes" or "regressions" based on your workload. Also
it will help if you report number of c
Heikki Linnakangas writes:
> WALInsertLock is also quite high on Jignesh's list. That I've seen
> become the bottleneck on other tests too.
Yeah, that's been seen to be an issue before. I had the germ of an idea
about how to fix that:
... with no lock, determine size of WAL record ...
On Wed, 2009-03-11 at 16:53 -0400, Jignesh K. Shah wrote:
> 1200: 2000: Medium Throughput: -1781969.000 Avg Medium Resp: 0.019
I think you need to iron out bugs in your test script before we put too
much stock into the results generated. Your throughput should not be
negative.
I'd be interested
Tom Lane wrote:
Robert Haas writes:
I think that changing the locking behavior is attacking the problem at
the wrong level anyway.
Right. By the time a patch here could have any effect, you've already
lost the game --- having to deschedule and reschedule a process is a
large cost compared to
On Fri, 13 Mar 2009, Kevin Grittner wrote:
Tom Lane wrote:
Robert Haas writes:
I think that changing the locking behavior is attacking the problem
at the wrong level anyway.
Right. By the time a patch here could have any effect, you've
already lost the game --- having to deschedule and re
Redid the test with - waking up all waiters irrespective of shared,
exclusive
480: 64: Medium Throughput: 66688.000 Avg Medium Resp: 0.005
540: 72: Medium Throughput: 74355.000 Avg Medium Resp: 0.005
600: 80: Medium Throughput: 82920.000 Avg Medium Resp: 0.005
660: 88: Medium Throughput: 91466.0
Somebody else asked a question: This is actually a two socket machine
(128) threads but one socket is disabled by the OS so only 64-threads
are available... The idea being let me choke one socket first with 100%
CPU ..
Forgot some data: with the second test above, CPU: 48% user, 18% sys,
35% id
Its an interesting question, but the answer is most likely simply that the
client can't keep up. And in the real world, no matter how incredible your
connection pool is, there will be some inefficiency, there will be some network
delay, there will be some client side time, etc.
I'm still not s
Tom Lane wrote:
> Robert Haas writes:
>> I think that changing the locking behavior is attacking the problem
>> at the wrong level anyway.
>
> Right. By the time a patch here could have any effect, you've
> already lost the game --- having to deschedule and reschedule a
> process is a large co
On 3/13/09 10:29 AM, "Scott Carey" wrote:
-
Now, with 0ms delay, no threading change:
Throughput is 136000/min @184 users, response time 13ms. Response time has not
jumped too drastically yet, but linear performance increases stopped at about
130 users or so. ProcArrayLock bus
On 3/13/09 10:16 AM, "Tom Lane" wrote:
Robert Haas writes:
> I think that changing the locking behavior is attacking the problem at
> the wrong level anyway.
Right. By the time a patch here could have any effect, you've already
lost the game --- having to deschedule and reschedule a process i
On 3/13/09 9:42 AM, "Jignesh K. Shah" wrote:
Now with a modified Fix (not the original one that I proposed but
something that works like a heart valve : Opens and shuts to minimum
default way thus controlling how many waiters are waked up )
Is this the server with 128 thread capability or 64
Scott Carey wrote:
On 3/13/09 8:55 AM, "Kevin Grittner" wrote:
>>> "Jignesh K. Shah" wrote:
> usr sys wt idl sze
> 38 11 0 50 64
The fact that you're maxing out at 50% CPU utilization has me
wondering -- are there really 64 CPUs here, or are there 32 CPUs with
"hyper
Robert Haas writes:
> I think that changing the locking behavior is attacking the problem at
> the wrong level anyway.
Right. By the time a patch here could have any effect, you've already
lost the game --- having to deschedule and reschedule a process is a
large cost compared to the typical loc
On Fri, 13 Mar 2009, Jignesh K. Shah wrote:
I can use dbt2, dbt3 tests to see how 8.4 performs and compare it with
8.3?
That would be very helpful. There's been some work at updating the DTrace
capabilities available too; you might compare what that's reporting too.
* Visibility map - Redu
On 3/13/09 8:55 AM, "Kevin Grittner" wrote:
>>> "Jignesh K. Shah" wrote:
> usr sys wt idl sze
> 38 11 0 50 64
The fact that you're maxing out at 50% CPU utilization has me
wondering -- are there really 64 CPUs here, or are there 32 CPUs with
"hyperthreading" technology (or something conc
Now with a modified Fix (not the original one that I proposed but
something that works like a heart valve : Opens and shuts to minimum
default way thus controlling how many waiters are waked up )
Time:Users:throughput: Reponse
60: 8: Medium Throughput: 7774.000 Avg Medium Resp: 0.004
120: 1
>>> "Jignesh K. Shah" wrote:
> 600: 80: Medium Throughput: 82632.000 Avg Medium Resp: 0.005
Personally, I'd be pretty interested in seeing what the sampling shows
in a steady state at this level. Any blocking at this level which
wasn't waiting for input or output in communications with the cli
>>> "Jignesh K. Shah" wrote:
> usr sys wt idl sze
> 38 11 0 50 64
The fact that you're maxing out at 50% CPU utilization has me
wondering -- are there really 64 CPUs here, or are there 32 CPUs with
"hyperthreading" technology (or something conceptually similar)?
-Kevin
--
Sent via pg
In general, I suggest that it is useful to run tests with a few
different types of pacing. Zero delay pacing will not have realistic
number of connections, but will expose bottlenecks that are
universal, and less controversial. Small latency (100ms to 1s) tests
are easy to make from the ze
"Jignesh K. Shah" writes:
> Gregory Stark wrote:
>> Keep in mind when you do this that it's not interesting to test a number of
>> connections much larger than the number of processors you have. Once the
>> system reaches 100% cpu usage it would be a misconfigured connection pooler
>> that kept m
Gregory Stark wrote:
"Jignesh K. Shah" writes:
Scott Carey wrote:
On 3/12/09 11:37 AM, "Jignesh K. Shah" wrote:
In general, I suggest that it is useful to run tests with a few different
types of pacing. Zero delay pacing will not have realistic number of
connections, but will expo
"Jignesh K. Shah" writes:
> Scott Carey wrote:
>> On 3/12/09 11:37 AM, "Jignesh K. Shah" wrote:
>>
>> In general, I suggest that it is useful to run tests with a few different
>> types of pacing. Zero delay pacing will not have realistic number of
>> connections, but will expose bottlenecks that
"Jignesh K. Shah" writes:
> Scott Carey wrote:
>> On 3/12/09 11:37 AM, "Jignesh K. Shah" wrote:
>>
>> In general, I suggest that it is useful to run tests with a few different
>> types of pacing. Zero delay pacing will not have realistic number of
>> connections, but will expose bottlenecks that
Greg Smith wrote:
On Thu, 12 Mar 2009, Jignesh K. Shah wrote:
As soon as I get more "cycles" I will try variations of it but it
would help if others can try it out in their own environments to see
if it helps their instances.
What you should do next is see whether you can remove the bottle
Scott Carey wrote:
On 3/12/09 11:37 AM, "Jignesh K. Shah" wrote:
And again this is the third time I am saying.. the test users also
have some latency build up in them which is what generally is
exploited to get more users than number of CPUS on the system but
that's the point
On Thu, 12 Mar 2009, Jignesh K. Shah wrote:
That said the testkit that I am using is a lightweight OLTP typish
workload which a user runs against a preknown schema and between various
transactions that it does it emulates a wait time of 200ms.
After re-reading about this all again at
http://
On Thu, 12 Mar 2009, Scott Carey wrote:
Furthermore, if the problem was due to too much concurrency in the
database with active connections, its hard to see how changing the lock
code would change the result the way it did ?
What I wonder about is if the locking mechanism is accidentally turn
> Its worth ruling out given that even if the likelihood is small, the fix is
> easy. However, I don’t see the throughput drop from peak as more
> concurrency is added that is the hallmark of this problem — usually with a
> lot of context switching and a sudden increase in CPU use per transaction.
On 3/12/09 11:37 AM, "Jignesh K. Shah" wrote:
And again this is the third time I am saying.. the test users also have some
latency build up in them which is what generally is exploited to get more users
than number of CPUS on the system but that's the point we want to exploit..
Otherwise if a
On 3/12/09 1:35 PM, "Greg Smith" wrote:
On Thu, 12 Mar 2009, Jignesh K. Shah wrote:
> As soon as I get more "cycles" I will try variations of it but it would
> help if others can try it out in their own environments to see if it
> helps their instances.
What you should do next is see whether y
On 3/12/09 11:28 AM, "Tom Lane" wrote:
Scott Carey writes:
> They are not meaningless. It is certainly more to understand, but the test
> is entirely valid without that. In a CPU bound / RAM bound case, as
> concurrency increases you look for the throughput trend, the %CPU use trend
> and t
On Thu, 12 Mar 2009, Jignesh K. Shah wrote:
As soon as I get more "cycles" I will try variations of it but it would
help if others can try it out in their own environments to see if it
helps their instances.
What you should do next is see whether you can remove the bottleneck your
test is ru
On 03/12/09 15:10, Alvaro Herrera wrote:
Tom Lane wrote:
Scott Carey writes:
They are not meaningless. It is certainly more to understand, but the test is
entirely valid without that. In a CPU bound / RAM bound case, as concurrency
increases you look for the throughput trend, the
>>> "Jignesh K. Shah" wrote:
> What we have is a pool of 2000 users and we start making each user
> do series of transactions on different rows and see how much the
> database can handle linearly before some bottleneck (system or
> database) kicks in and there can be no more linear increase in
>
Tom Lane wrote:
> Scott Carey writes:
> > They are not meaningless. It is certainly more to understand, but the test
> > is entirely valid without that. In a CPU bound / RAM bound case, as
> > concurrency increases you look for the throughput trend, the %CPU use trend
> > and the context swit
On 03/12/09 13:48, Scott Carey wrote:
On 3/11/09 7:47 PM, "Tom Lane" wrote:
All I'm adding, is that it makes some sense to me based on my
experience in CPU / RAM bound scalability tuning. It was expressed
that the test itself didn't even make sense.
I was wrong in my understanding of wha
At 11:44 AM 3/12/2009, Kevin Grittner wrote:
I'm probably more inclined to believe that his change may have merit
than many here, but I can't accept anything based on this test until
someone answers the question, so far ignored by all responses, of
where the bottleneck is at the low end which
Scott Carey writes:
> They are not meaningless. It is certainly more to understand, but the test
> is entirely valid without that. In a CPU bound / RAM bound case, as
> concurrency increases you look for the throughput trend, the %CPU use trend
> and the context switch rate trend. More infor
On 3/12/09 10:53 AM, "Tom Lane" wrote:
"Kevin Grittner" writes:
> You misunderstood me. I wasn't addressing the affects of his change,
> but rather the fact that his test shows a linear improvement in TPS up
> to 1000 connections for a 64 thread machine which is dealing entirely
> with RAM -- n
On 3/12/09 10:09 AM, "Gregory Stark" wrote:
Ram-resident use cases are entirely valid and worth testing, but in those use
cases you would want to have about as many processes as you have processes.
Within a factor of two or so, yes. However, where in his results does it show
that there are 10
On 03/12/09 11:13, Kevin Grittner wrote:
Scott Carey wrote:
"Kevin Grittner" wrote:
I'm a lot more interested in what's happening between 60 and 180
than over 1000, personally. If there was a RAID involved, I'd put
it down to better use of the numerous spindles, but when it'
1 - 100 of 118 matches
Mail list logo
