On Sat, Sep 29, 2001 at 06:48:56PM +0530, Chamanya wrote:
Number of threads should be equal to or twice that of number of CPUs. I don't
think more than those many threads would yield any performance improvement.
This expects that thread still runnig, but each process (thread) sometime
Tom Lane wrote:
snip
I think the default NBuffers (64) is too low to give meaningful
performance numbers, too. I've been thinking that maybe we should
raise it to 1000 or so by default. This would trigger startup failures
on platforms with small SHMMAX, but we could tell people to use -B
Bruce Momjian [EMAIL PROTECTED] wrote:
From postmaster startup, by default, could we try larger amounts of
buffer memory until it fails then back off and allocate that? Seems
like a nice default to me.
So performance would vary depending on the amount of shared memory
that could be
This is still missing a bet since it fails to mention the option of
adjusting -B and -N instead of changing kernel parameters, but that's
easily fixed. I propose that we reword this message and the semget
one to mention first the option of changing -B/-N and second the option
of changing
Bruce Momjian [EMAIL PROTECTED] writes:
From postmaster startup, by default, could we try larger amounts of
buffer memory until it fails then back off and allocate that? Seems
like a nice default to me.
Chewing all available memory is the very opposite of a nice default,
I'd think.
The real
Bruce Momjian [EMAIL PROTECTED] writes:
Tom Lane wrote:
I think the default NBuffers (64) is too low to give meaningful
performance numbers, too. I've been thinking that maybe we should
raise it to 1000 or so by default.
Maybe something simple like pg_ctl shell script message, or something
Tom Lane wrote:
snip
I think the default NBuffers (64) is too low to give meaningful
performance numbers, too. I've been thinking that maybe we should
raise it to 1000 or so by default. This would trigger startup failures
on platforms with small SHMMAX, but we could tell people to
Vadim Mikheev wrote:
I have committed changes to implement this proposal. I'm not seeing
any significant performance difference on pgbench on my single-CPU
system ... but pgbench is I/O bound anyway on this hardware, so that's
not very surprising. I'll be interested to see what other
I wrote:
The following proposal should improve performance substantially when
there is contention for a lock, but it creates no portability risks
...
I have committed changes to implement this proposal. I'm not seeing
any significant performance difference on pgbench on my single-CPU
system
I have committed changes to implement this proposal. I'm not seeing
any significant performance difference on pgbench on my single-CPU
system ... but pgbench is I/O bound anyway on this hardware, so that's
not very surprising. I'll be interested to see what other people
observe. (Tatsuo,
On Thursday 27 September 2001 04:09, you wrote:
This depends on your system. Solaris has a huge difference between
thread and process context switch times, whereas Linux has very little
difference (and in fact a Linux process context switch is about as
fast as a Solaris thread switch on the
Vadim Mikheev [EMAIL PROTECTED] writes:
I have committed changes to implement this proposal. I'm not seeing
any significant performance difference on pgbench on my single-CPU
system ... but pgbench is I/O bound anyway on this hardware, so that's
not very surprising. I'll be interested to
Good summary. I agree checkpoint should look like as normal a Proc as
possible.
At the just-past OSDN database conference, Bruce and I were annoyed by
some benchmark results showing that Postgres performed poorly on an
8-way SMP machine. Based on past discussion, it seems likely that the
* Doug McNaught [EMAIL PROTECTED] wrote:
|
| Depends on what you mean. For scaling well with many connections and
| simultaneous queries, there's no reason IMHO that the current
| process-per-backend model won't do, assuming the locking issues are
| addressed.
Wouldn't a threading model allow
Chamanya wrote:
On Thursday 27 September 2001 04:09, you wrote:
This depends on your system. Solaris has a huge difference between
thread and process context switch times, whereas Linux has very little
difference (and in fact a Linux process context switch is about as
fast as a
Bruce Momjian [EMAIL PROTECTED] writes:
No scale factor, as I illustrated from the initialization command I
used. Standard buffers too. Let me know what values I should use for
testing.
Scale factor has to be = max number of clients you use, else you're
just measuring serialization on the
OK, testing now with 1000 backends and 2000 buffers. Will report.
Bruce Momjian [EMAIL PROTECTED] writes:
No scale factor, as I illustrated from the initialization command I
used. Standard buffers too. Let me know what values I should use for
testing.
Scale factor has to be = max
Sounds cool to me ... definitely something to fix before v7.2, if its as
easy as you make it sound ... I'm expecting the new drive to be
installed today (if all goes well ... Thomas still has his date/time stuff
to finish off, now that CVSup is fixed ...
Let''s try and target Monday for
Bruce Momjian wrote:
Bruce Momjian wrote:
Save for the fact that the kernel can switch between threads faster then
it can switch processes considering threads share the same address space,
stack, code, etc. If need be sharing the data between threads is much
easier then
Bruce Momjian wrote:
Save for the fact that the kernel can switch between threads faster then
it can switch processes considering threads share the same address space,
stack, code, etc. If need be sharing the data between threads is much
easier then sharing between processes.
Just a
Lincoln Yeoh wrote:
At 10:02 AM 9/27/01 -0400, mlw wrote:
D. Hageman wrote:
I agree with everything you wrote above except for the first line. My
only comment is that process boundaries are only *truely* a powerful
barrier if the processes are different pieces of code and are not
At 10:02 AM 9/27/01 -0400, mlw wrote:
D. Hageman wrote:
I agree with everything you wrote above except for the first line. My
only comment is that process boundaries are only *truely* a powerful
barrier if the processes are different pieces of code and are not
dependent on each other in
Bruce Momjian wrote:
Save for the fact that the kernel can switch between threads faster then
it can switch processes considering threads share the same address space,
stack, code, etc. If need be sharing the data between threads is much
easier then sharing between processes.
We have been doing some scalability testing just recently here at Red
Hat. The machine I was using was a 4-way 550 MHz Xeon SMP machine, I
also ran the machine in uniprocessor mode to make some comparisons. All
runs were made on Red Hat Linux running 2.4.x series kernels. I've
examined a
FYI, I have added a number of these emails to the 'thread' TODO.detail list.
On Wed, 26 Sep 2001, D. Hageman wrote:
Save for the fact that the kernel can switch between threads faster then
it can switch processes considering threads share the same address space,
stack, code,
D. Hageman wrote:
On 26 Sep 2001, Ian Lance Taylor wrote:
Save for the fact that the kernel can switch between threads faster then
it can switch processes considering threads share the same address space,
stack, code, etc. If need be sharing the data between threads is much
Tom Lane wrote:
Neil Padgett [EMAIL PROTECTED] writes:
Well. Currently the runs are the typical pg_bench runs.
With what parameters? If you don't initialize the pg_bench database
with scale proportional to the number of clients you intend to use,
then you'll naturally get huge lock
At the just-past OSDN database conference, Bruce and I were annoyed by
some benchmark results showing that Postgres performed poorly on an
8-way SMP machine. Based on past discussion, it seems likely that the
culprit is the known inefficiency in our spinlock implementation.
After chewing on it
Sounds cool to me ... definitely something to fix before v7.2, if its as
easy as you make it sound ... I'm expecting the new drive to be
installed today (if all goes well ... Thomas still has his date/time stuff
to finish off, now that CVSup is fixed ...
Let''s try and target Monday for Beta
Marc G. Fournier [EMAIL PROTECTED] writes:
Let''s try and target Monday for Beta then?
Sounds like a plan.
regards, tom lane
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
Tom Lane wrote:
At the just-past OSDN database conference, Bruce and I were annoyed by
some benchmark results showing that Postgres performed poorly on an
8-way SMP machine. Based on past discussion, it seems likely that the
culprit is the known inefficiency in our spinlock implementation.
Neil Padgett [EMAIL PROTECTED] writes:
Initial results (top five -- if you would like a complete profile, let
me know):
Each sample counts as 1 samples.
% cumulative self self total
time samples samplescalls T1/call T1/call name
26.57
Neil Padgett [EMAIL PROTECTED] writes:
Well. Currently the runs are the typical pg_bench runs.
With what parameters? If you don't initialize the pg_bench database
with scale proportional to the number of clients you intend to use,
then you'll naturally get huge lock contention. For example,
Tom Lane wrote:
Neil Padgett [EMAIL PROTECTED] writes:
Initial results (top five -- if you would like a complete profile, let
me know):
Each sample counts as 1 samples.
% cumulative self self total
time samples samplescalls T1/call T1/call name
D. Hageman [EMAIL PROTECTED] writes:
you have a newer kernel scheduled implementation, then you will have the same
scheduling as separate processes. The only thing you will need to do is
switch your brain from figuring out how to share data, to trying to figure
out how to isolate data. A
On Wed, 26 Sep 2001, mlw wrote:
I can only think of two objectives for threading. (1) running the various
connections in their own thread instead of their own process. (2) running
complex queries across multiple threads.
I did a multi-threaded version of 7.0.2 using Solaris threads about
D. Hageman [EMAIL PROTECTED] writes:
Save for the fact that the kernel can switch between threads faster then
it can switch processes considering threads share the same address space,
stack, code, etc. If need be sharing the data between threads is much
easier then sharing between
On 26 Sep 2001, Ian Lance Taylor wrote:
Save for the fact that the kernel can switch between threads faster then
it can switch processes considering threads share the same address space,
stack, code, etc. If need be sharing the data between threads is much
easier then sharing between
On 26 Sep 2001, Doug McNaught wrote:
This depends on your system. Solaris has a huge difference between
thread and process context switch times, whereas Linux has very little
difference (and in fact a Linux process context switch is about as
fast as a Solaris thread switch on the same
Ian Lance Taylor [EMAIL PROTECTED] writes:
(Actually, though, Postgres is already vulnerable to erratic behaviour
because any backend process can corrupt the shared buffer pool.)
Not to mention the other parts of shared memory.
Nonetheless, our experience has been that cross-backend failures
... Thomas still has his date/time stuff
to finish off, now that CVSup is fixed ...
I'm now getting clean runs through the regression tests on a freshly
merged cvs tree. I'd like to look at it a little more to adjust
pg_proc.h attributes before I commit the changes.
There was a bit of a
On Wed, 26 Sep 2001, D. Hageman wrote:
Save for the fact that the kernel can switch between threads faster then
it can switch processes considering threads share the same address space,
stack, code, etc. If need be sharing the data between threads is much
easier then sharing
On Wed, 26 Sep 2001, Alex Pilosov wrote:
On Wed, 26 Sep 2001, D. Hageman wrote:
When you need data that is specific to a thread you use a TSD (Thread
Specific Data).
Which Linux does not support with a vengeance, to my knowledge.
I am not sure what that means. If it works it works.
On Wed, 26 Sep 2001, D. Hageman wrote:
Oh, man ... am I reading stuff into what you are writing or are you
reading stuff into what I am writing? Maybe a little bit of both? My
original contention is that I think that the best way to get the full
potential out of SMP machines is to use a
D. Hageman [EMAIL PROTECTED] writes:
If you look at Myron Scott's post today you will see that it had other
advantages going for it (like auto-vacuum!) and disadvantages ... rogue
thread corruption (already debated today).
But note that Myron did a number of things that are (IMHO)
But note that Myron did a number of things that are (IMHO) orthogonal
yes, I did :)
to process-to-thread conversion, such as adding prepared statements,
a separate thread/process/whateveryoucallit for buffer writing, ditto
for vacuuming, etc. I think his results cannot be taken as
The plan for the new spinlocks does look like it has some potential. My
only comment in regards to permformance when we start looking at SMP
machines is ... it is my belief that getting a true threaded backend may
be the only way to get the full potential out of SMP machines. I see that
is
D. Hageman [EMAIL PROTECTED] writes:
The plan for the new spinlocks does look like it has some potential. My
only comment in regards to permformance when we start looking at SMP
machines is ... it is my belief that getting a true threaded backend may
be the only way to get the full
On 26 Sep 2001, Doug McNaught wrote:
D. Hageman [EMAIL PROTECTED] writes:
The plan for the new spinlocks does look like it has some potential. My
only comment in regards to permformance when we start looking at SMP
machines is ... it is my belief that getting a true threaded backend
D. Hageman wrote:
The plan for the new spinlocks does look like it has some potential. My
only comment in regards to permformance when we start looking at SMP
machines is ... it is my belief that getting a true threaded backend may
be the only way to get the full potential out of SMP
On Wed, 26 Sep 2001, mlw wrote:
I can only think of two objectives for threading. (1) running the various
connections in their own thread instead of their own process. (2) running
complex queries across multiple threads.
For item (1) I see no value to this. It is a lot of work with no
51 matches
Mail list logo
