SEO

Hi.

We are looking at upgrading our primary servers. The final boxes will have
128GB ram, fast disk arrays and 4 CPUs.

We currently have some eval units with 8GB ram and crappy disk to let us
benchmark CPU choice. One box has 4 3GHz dual core Opterons with 1MB cache,
the other box ha 4 3GHz quad core Xeons with 4MB cache.

model name : Intel(R) Xeon(R) CPU X7350 @ 2.93GHz
cache size : 4096 KB
model name : Dual-Core AMD Opteron(tm) Processor 8222 SE
cache size : 1024 KB

I haven't had a chance to play with the hardware myself yet. The sysadmins
have been running some benchmarks themselves though.

For every non PG related benchmark they have run, the Xeon wins by around20%.

For pgbench (PG 8.2 running Ubuntu), the Opteron is getting about 6x TPS
over the Xeon (3000+ TPS on Opteron vs ~500 on Xeon). Things get a little
better for Xeon with PG 8.3 (570-540 TPS).

Does this match what other people are seeing or expect, or have we screwed
our benchmarks somehow?

Is this a PG specific win for Opteron, or will we see similar results with
other DBs?

Do people see wins for non-PG databases on Xeon, and are they as dramaticas
we are seeing for PG on Opteron?

With PG 8.2 and 8.3, is it still pretty much limited to 8 cores making 2 of
the quad core Xeons redundant or detrimental?

I expect we will be running this hardware for 8.2, 8.3 and 8.4. Anyone aware
of anything that might change the landscape for 8.4?

--
Stuart Bishop <stuart@stuartbishop.net>
http://www.stuartbishop.net/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHaQi8AfqZj7rGN0oRArQXAJ9WIMgoE837pLYC6gHv4c mepIomwACdFc1c
lCnQoakaixRenvLvFbhWlus=
=eDwV
-----END PGP SIGNATURE-----

Stuart Bishop a écrit :
> Hi.
>
> We are looking at upgrading our primary servers. The final boxes will have
> 128GB ram, fast disk arrays and 4 CPUs.
>
> We currently have some eval units with 8GB ram and crappy disk to let us
> benchmark CPU choice. One box has 4 3GHz dual core Opterons with 1MB cache,
> the other box ha 4 3GHz quad core Xeons with 4MB cache.
>
> model name : Intel(R) Xeon(R) CPU X7350 @ 2.93GHz
> cache size : 4096 KB
> model name : Dual-Core AMD Opteron(tm) Processor 8222 SE
> cache size : 1024 KB
>
> I haven't had a chance to play with the hardware myself yet. The sysadmins
> have been running some benchmarks themselves though.
>
> For every non PG related benchmark they have run, the Xeon wins by around 20%.
>
> For pgbench (PG 8.2 running Ubuntu), the Opteron is getting about 6x TPS
> over the Xeon (3000+ TPS on Opteron vs ~500 on Xeon). Things get a little
> better for Xeon with PG 8.3 (570-540 TPS).
>
> Does this match what other people are seeing or expect, or have we screwed
> our benchmarks somehow?
>
http://tweakers.net/reviews/661/7

as an example

You can travel the website for other benchs... (there are about dual
and quad core)

> Is this a PG specific win for Opteron, or will we see similar results with
> other DBs?
>
> Do people see wins for non-PG databases on Xeon, and are they as dramatic as
> we are seeing for PG on Opteron?
>
> With PG 8.2 and 8.3, is it still pretty much limited to 8 cores making 2 of
> the quad core Xeons redundant or detrimental?
>
> I expect we will be running this hardware for 8.2, 8.3 and 8.4. Anyone aware
> of anything that might change the landscape for 8.4?
>
>


--
Cédric Villemain
Administrateur de Base de Données
Cel: +33 (0)6 74 15 56 53
http://dalibo.com - http://dalibo.org



---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

"Stuart Bishop" <stuart@stuartbishop.net> writes:

> For pgbench (PG 8.2 running Ubuntu), the Opteron is getting about 6x TPS
> over the Xeon (3000+ TPS on Opteron vs ~500 on Xeon). Things get a little
> better for Xeon with PG 8.3 (570-540 TPS).

There was a problem in the past which affected Xeons. But I thought it had
been mostly addressed. Xeons are (or were? these things are always changing)
more sensitive to interprocess contention due to their memory architecture
though.

What are you actually doing in these transactions? Are they read-only? If not
is fsync=off (which you don't want if you care about your data but you do if
you're trying to benchmark the cpu).

Are the crappy disks *identical* crappy disks? If they have different
controllers or different drives (or different versions of the OS) then you
might be being deceived by write caching on one set and not the other. If
they're not read-only transactions and fsync=on then the TPS of 3000+ is not
credible and this is likely.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's RemoteDBA services!

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

On Dec 19, 2007 6:04 AM, Stuart Bishop <stuart@stuartbishop.net> wrote:
> Hi.
>
> We are looking at upgrading our primary servers. The final boxes will have
> 128GB ram, fast disk arrays and 4 CPUs.
>
> We currently have some eval units with 8GB ram and crappy disk to let us
> benchmark CPU choice. One box has 4 3GHz dual core Opterons with 1MB cache,
> the other box ha 4 3GHz quad core Xeons with 4MB cache.

Imagine two scenarios. In one you have an infinite number of hard
drives with an infinite amount of battery backed cache, and an
infinite I/O bandwidth. In the other you have one disk. Which one is
likely to be I/O bound?

Yep. So, it's not likely you'll be able to do a realistic benchmark
of the CPUs with such a limited disk subsystem...

> For pgbench (PG 8.2 running Ubuntu), the Opteron is getting about 6x TPS
> over the Xeon (3000+ TPS on Opteron vs ~500 on Xeon). Things get a little
> better for Xeon with PG 8.3 (570-540 TPS).

pgbench is a mostly I/O bound benchmark. What are your -c, -t and -s
settings btw?

It's would be much better if you could benchmark something like the
real load you'll be running in the future. Are you looking at
reporting, transactions, content management, etc...?

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

On Dec 19, 2007 12:59 PM, Joshua D. Drake <jd@commandprompt.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Wed, 19 Dec 2007 13:50:29 -0500 (EST)
> Greg Smith <gsmith@gregsmith.com> wrote:
>
> > > With PG 8.2 and 8.3, is it still pretty much limited to 8 cores
> > > making 2 of the quad core Xeons redundant or detrimental?
> >
> > Where'd you get the idea 8 cores was a limit? As cores go up
> > eventually you run out of disk or memory bandwidth, but how that
> > plays out is very application dependant and there's no hard line
> > anywhere.
>
> Actually this is not true. Although I have yet to test 8.3. It is
> pretty much common knowledge that after 8 cores the acceleration of
> performance drops with PostgreSQL...

I thought Tom had played with some simple hacks that got the scaling
pretty close to linear for up to 16 cores earlier this year...

---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

Joshua D. Drake wrote:
> Actually this is not true. Although I have yet to test 8.3. It is
> pretty much common knowledge that after 8 cores the acceleration of
> performance drops with PostgreSQL...
>
> This has gotten better every release. 8.1 for example handles 8 cores
> very well, 8.0 didn't and 7.4 well....

I agree with the spirit of what you say, but are you overstating
things a bit?

Benchmarks I see[1] suggest that 8.1.2 scaled pretty reasonably to 16
cores (from the chart on page 9 in the link below). But yeah, 8.0
scaled to maybe 2 cores if you're lucky. :-)

Agree with the rest of the things you say, tho. It's getting
way better every recent release.



[1] http://www.pgcon.org/2007/schedule/a...%20An%20Update

On Dec 19, 2007 1:07 PM, Joshua D. Drake <jd@commandprompt.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Wed, 19 Dec 2007 13:03:32 -0600
> "Scott Marlowe" <scott.marlowe@gmail.com> wrote:
>
>
> > > Actually this is not true. Although I have yet to test 8.3. It is
> > > pretty much common knowledge that after 8 cores the acceleration of
> > > performance drops with PostgreSQL...
> >
> > I thought Tom had played with some simple hacks that got the scaling
> > pretty close to linear for up to 16 cores earlier this year...
> >
>
> See.. have not tested 8.3 above and 8.2 is better than 8.1 etc...

Well, I'm not even sure if those got applied or were just Tom hacking
in the basement or, heck, my fevered imagination.

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq

On Wed, 19 Dec 2007, Ron Mayer wrote:

> Benchmarks I see[1] suggest that 8.1.2 scaled pretty reasonably to 16
> cores (from the chart on page 9 in the link below). But yeah, 8.0
> scaled to maybe 2 cores if you're lucky. :-)
> [1] http://www.pgcon.org/2007/schedule/a...%20An%20Update

Thank you, I was looking for that one but couldn't find it again. Note
that those results are using a TPC-C variant, which is not the most CPU
intensive of tests out there. It's certainly possible that an application
that has more processing to do per transaction (I'm thinking something
more in the scientific computing database realm) could scale even better.

While I'd expect the bang per buck to go down quite a bit beyond 8 cores,
I know I haven't seen any data on what new systems running 8.3 are capable
of, and extrapolating performance rules of thumb based on old data is
perilous. Bottlenecks shift around in unexpected ways. In that Unisys
example, they're running 32-bit single core Xeons circa 2004 with 4MB of
*L3* cache and there's evidence that scales >16 processors. Current Xeons
are considerably faster and you can get them with 4-8MB of *L2* cache.

What does that do to scalability? Beats me. Maybe since the individual
CPUs are faster, you bottleneck on something else way before you can use
16 of them usefully. Maybe the much better CPU cache means there's less
reliance on the memory bus and they scale better. It depends a lot on the
CPU vs. memory vs. disk requirements of your app, which is what I was
suggesting before.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD

---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

"Joshua D. Drake" <jd@commandprompt.com> writes:

> It is pretty much common knowledge that

I think we have too much "common knowledge".

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's PostGIS support!

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

"Scott Marlowe" <scott.marlowe@gmail.com> writes:
> Well, I'm not even sure if those got applied or were just Tom hacking
> in the basement or, heck, my fevered imagination.

For the record, I hack in the attic ... or what I tell the IRS is my
third-floor office ...

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate