Hi, Zydoon,
Zydoon wrote:
> Now I'm trying to make my tests, and I'm not that sure I will make the
> switch to the PSeries, since my dual xeon with 4 G RAM can handle 3500
> concurrent postmasters consuming 3.7 G of the RAM. I cannot reach this
> number on the PSeries with 2 G.
This sounds like
Hi, Fzied,
[EMAIL PROTECTED] wrote:
> I'm using httperf/autobench for measurments and the best result I can
> get is that my system can handle a trafiic of almost 1600 New
> con/sec.
Are you using connection pooling or persistent connections between
PostgreSQL and the Apaches?
Maybe it simply i
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> On Tue, Jun 13, 2006 at 06:21:21PM -0400, John Vincent wrote:
>> Actually it's on my radar. I was looking for a precompiled build first (we
>> actually checked the Pervasive and Bizgres sites first since we're
>> considering a support contract) before go
Well, pre-compiled isn't going to make much of a difference
stability-wise. What you will run into is that very few people arerunning PostgreSQL on your hardware, so it's possible you'd run intosome odd corner cases. I think it's pretty unlikely you'd lose data, but
you could end up with performanc
On Tue, Jun 13, 2006 at 06:21:21PM -0400, John Vincent wrote:
> On 6/13/06, Jim C. Nasby <[EMAIL PROTECTED]> wrote:
> >
> >On Tue, Jun 13, 2006 at 05:40:58PM -0400, John Vincent wrote:
> >> Maybe from a postgresql perspective the cpus may be useless but the
> >memory
> >> on the pSeries can't be be
On 6/13/06, Jim C. Nasby <[EMAIL PROTECTED]> wrote:
On Tue, Jun 13, 2006 at 05:40:58PM -0400, John Vincent wrote:> Maybe from a postgresql perspective the cpus may be useless but the memory> on the pSeries can't be beat. We've been looking at running our warehouse
> (PGSQL) in a LoP lpar but I wasn
On Tue, Jun 13, 2006 at 05:40:58PM -0400, John Vincent wrote:
> Maybe from a postgresql perspective the cpus may be useless but the memory
> on the pSeries can't be beat. We've been looking at running our warehouse
> (PGSQL) in a LoP lpar but I wasn't able to find a LoP build of 8.1.
Probably jus
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Gavin Hamill wrote:
> On Tue, 13 Jun 2006 14:28:49 -0500
> Scott Marlowe <[EMAIL PROTECTED]> wrote:
>
>> Search the performance archives for the last 4 or 5 months for PPC /
>> pseries machines.
>>
>> You'll find a very long thread about the disappoin
Maybe from a postgresql perspective the cpus may be useless but the memory on the pSeries can't be beat. We've been looking at running our warehouse (PGSQL) in a LoP lpar but I wasn't able to find a LoP build of 8.1.
We've been thrilled with the performance of our DB2 systems that run on AIX/Power
On Tue, Jun 13, 2006 at 10:14:44PM +0200, PFC wrote:
>
> >Uhm... stick with commodity CPUs?
>
> Hehe, does this include Opterons ?
Absolutely. Heck, it wouldn't surprise me if a single model # of Opteron
sold more than all Power CPUs put together...
> Still, I looked on the "custom
Uhm... stick with commodity CPUs?
Hehe, does this include Opterons ?
Still, I looked on the "customize your server" link someone posted and
it's amazing ; these things have become cheaper while I wasn't looking...
You can buy 10 of these boxes with raptors and 4 opteron cores and
On Tue, 13 Jun 2006 14:28:49 -0500
Scott Marlowe <[EMAIL PROTECTED]> wrote:
> Search the performance archives for the last 4 or 5 months for PPC /
> pseries machines.
>
> You'll find a very long thread about the disappointing performance the
> tester got with a rather expensive P Series machine.
On Mon, 2006-06-12 at 16:47, Zydoon wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Thank you for sharing this.
> Coming back to my problem :) A very faithful partner accepted to
> gracefully borrow us 3 Pseries (bi-ppc + 2G RAM not more). with linux on
> them.
> Now I'm trying to make my tests, and
On Mon, Jun 12, 2006 at 11:47:07PM +0200, Zydoon wrote:
> Thank you for sharing this.
> Coming back to my problem :) A very faithful partner accepted to
> gracefully borrow us 3 Pseries (bi-ppc + 2G RAM not more). with linux on
> them.
> Now I'm trying to make my tests, and I'm not that sure I will
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Sven Geisler wrote:
> Hi Mario,
>
> I did run pgbench on several production servers:
> HP DL585 - 4-way AMD Opteron 875
> HP DL585 - 4-way AMD Opteron 880
> HP DL580 G3 - 4-way Intel XEON MP 3.0 GHz
> FSC RX600 S2 - 4-way Intel XEON MP DC 2.66 GHz
> F
Hi all,
Joshua D. Drake schrieb:
Mario Splivalo wrote:
Could you point out to some more detailed reading on why Xeons are
poorer choice than Opterons when used with PostgreSQL?
It isn't just PostgreSQL. It is any database. Opterons can move memory
and whole lot faster then Xeons.
Yes. You
On 12 Jun 2006, at 00:21, Joshua D. Drake wrote:
Mario Splivalo wrote:
On Sat, 2006-06-03 at 11:43 +0200, Steinar H. Gunderson wrote:
On Sat, Jun 03, 2006 at 10:31:03AM +0100, [EMAIL PROTECTED] wrote:
I do have 2 identical beasts (4G - biproc Xeon 3.2 - 2 Gig NIC)
One beast will be apache, an
Hi Mario,
I did run pgbench on several production servers:
HP DL585 - 4-way AMD Opteron 875
HP DL585 - 4-way AMD Opteron 880
HP DL580 G3 - 4-way Intel XEON MP 3.0 GHz
FSC RX600 S2 - 4-way Intel XEON MP DC 2.66 GHz
FSC RX600 - 4-way Intel XEON MP 2.5 GHz
This test has been done with 8.1.4. I incr
Mario Splivalo wrote:
On Sat, 2006-06-03 at 11:43 +0200, Steinar H. Gunderson wrote:
On Sat, Jun 03, 2006 at 10:31:03AM +0100, [EMAIL PROTECTED] wrote:
I do have 2 identical beasts (4G - biproc Xeon 3.2 - 2 Gig NIC)
One beast will be apache, and the other will be postgres.
I'm using httperf/aut
On Sat, 2006-06-03 at 11:43 +0200, Steinar H. Gunderson wrote:
> On Sat, Jun 03, 2006 at 10:31:03AM +0100, [EMAIL PROTECTED] wrote:
> > I do have 2 identical beasts (4G - biproc Xeon 3.2 - 2 Gig NIC)
> > One beast will be apache, and the other will be postgres.
> > I'm using httperf/autobench for m
On Sun, Jun 11, 2006 at 11:42:20PM +0200, Mario Splivalo wrote:
> Could you point out to some more detailed reading on why Xeons are
> poorer choice than Opterons when used with PostgreSQL?
There are lots of theories, none conclusive, but the benchmarks certainly
point that way consistently. Read
Tom Lane wrote:
As per PFC's comment, if connections/sec is a bottleneck for you then
the
answer is to use persistent connections. Launching a new backend
is a fairly
heavyweight operation in Postgres.
In which case maybe pgpool could help in this respect?
http://pgpool.projects.postgresql
Tom Lane wrote:
[EMAIL PROTECTED] writes:
I'm using httperf/autobench for measurments and the best result I can get
is that my system can handle a trafiic of almost 1600 New con/sec.
As per PFC's comment, if connections/sec is a bottleneck for you then
the answer is to
[EMAIL PROTECTED] writes:
> I'm using httperf/autobench for measurments and the best result I can get
> is that my system can handle a trafiic of almost 1600 New con/sec.
As per PFC's comment, if connections/sec is a bottleneck for you then
the answer is to use persistent connections. Launching
I cannot scale beyond that value and the funny thing, is that none of the
servers is swapping, or heavy loaded, neither postgres nor apache are
refusing connexions.
Hearing a story like this (throughput hits a hard limit, but
hardware doesn't appear to be 100% utilized), I'd suspect
insuffi
One beast will be apache, and the other will be postgres.
I'm using httperf/autobench for measurments and the best result I can get
is that my system can handle a trafiic of almost 1600 New con/sec.
NB : apache when stressed for a static page, i can handle more 16k new
con/sec
T
On Sat, Jun 03, 2006 at 10:31:03AM +0100, [EMAIL PROTECTED] wrote:
> I do have 2 identical beasts (4G - biproc Xeon 3.2 - 2 Gig NIC)
> One beast will be apache, and the other will be postgres.
> I'm using httperf/autobench for measurments and the best result I can get
> is that my system can handl
27 matches
Mail list logo
