After reading the replies to this, it is clear that this is a
Lintel-centric question, but I will throw in my experience.
> I am curious if there are any real life production
> quad processor setups running postgresql out there.
Yes. We are running a 24/7 operation on a quad CPU Sun V880.
> Sinc
I would recommend trying out several stripe sizes, and making your own
measurements.
A while ago I was involved in building a data warehouse system (Oracle,
DB2) and after several file and db benchmark exercises we used 256K
stripes, as these gave the best overall performance results for both
On Tue, 2004-05-11 at 15:46 -0700, Paul Tuckfield wrote:
> - the "cache" column shows that linux is using 2.3G for cache. (way too
> much) you generally want to give memory to postgres to keep it "close" to
> the user, not leave it unused to be claimed by linux cache (need to leave
> *some* for
One big caveat re. the "SAME" striping strategy, is that readahead can
really hurt an OLTP you.
Mind you, if you're going from a few disks to a caching array with many
disks, it'll be hard to not have a big improvement
But if you push the envelope of the array with a "SAME" configuration,
read
Hadley Willan wrote:
To answer question 1, if you use software raid the chunk size is part of
the /etc/raidtab file that is used on initial container creation. 4KB is
the standard and a LARGE chunk size of 1MB may affect performance if
you're not writing down to blocks in that size continuously.
Bjoern Metzdorf wrote:
You might also consider configuring the Postgres data drives for a
RAID 10 SAME configuration as described in the Oracle paper "Optimal
Storage Configuration Made Easy"
(http://otn.oracle.com/deploy/availability/pdf/oow2000_same.pdf). Has
anyone delved into this before?
O
James Thornton wrote:
This is what I am considering the ultimate platform for postgresql:
Hardware:
Tyan Thunder K8QS board
2-4 x Opteron 848 in NUMA mode
4-8 GB RAM (DDR400 ECC Registered 1 GB modules, 2 for each processor)
LSI Megaraid 320-2 with 256 MB cache ram and battery backup
6 x 36GB SCSI
Bjoern Metzdorf wrote:
Hi,
at first, many thanks for your valuable replies. On my quest for the
ultimate hardware platform I'll try to summarize the things I learned.
-
This is what I am considering the ultimate platform for postgresql:
This is somthing I wish more of us did on the lists. The list archives
have solutions and workarounds for every variety of problem but very few
summary emails exist. A good example of this practice is in the
sun-managers mailling list. The original poster sends a "SUMMARY" reply
to the list with
Hi,
at first, many thanks for your valuable replies. On my quest for the
ultimate hardware platform I'll try to summarize the things I learned.
-
This is our current setup:
Hardware:
Dual Xeon DP 2.4 on a TYAN S2722-533 with HT enabled
3
On Wed, 12 May 2004, Grega Bremec wrote:
> ...and on Tue, May 11, 2004 at 03:02:24PM -0600, scott.marlowe used the keyboard:
> >
> > If you get the LSI megaraid, make sure you're running the latest megaraid
> > 2 driver, not the older, slower 1.18 series. If you are running linux,
> > look for
On Tue, 11 May 2004 15:46:25 -0700, Paul Tuckfield <[EMAIL PROTECTED]>
wrote:
>- the "cache" column shows that linux is using 2.3G for cache. (way too
>much)
There is no such thing as "way too much cache".
> you generally want to give memory to postgres to keep it "close" to
>the user,
Yes,
BM> see my other mail.
BM> We are running Linux, Kernel 2.4. As soon as the next debian version
BM> comes out, I'll happily switch to 2.6 :)
it's very simple to use 2.6 with testing version, but if you like
woody - you can simple install several packets from testing or
backports.org
if you thin
...and on Tue, May 11, 2004 at 03:02:24PM -0600, scott.marlowe used the keyboard:
>
> If you get the LSI megaraid, make sure you're running the latest megaraid
> 2 driver, not the older, slower 1.18 series. If you are running linux,
> look for the dkms packaged version. dkms, (Dynamic Kernel M
On Tue, 11 May 2004, Bjoern Metzdorf wrote:
> I am curious if there are any real life production quad processor setups
> running postgresql out there. Since postgresql lacks a proper
> replication/cluster solution, we have to buy a bigger machine.
Du you run the latest version of PG? I've read
On Tue, 11 May 2004, Allan Wind wrote:
> On 2004-05-11T15:29:46-0600, scott.marlowe wrote:
> > The other nice thing about the LSI cards is that you can install >1 and
> > the act like one big RAID array. i.e. install two cards with a 20 drive
> > RAID0 then make a RAID1 across them, and if one
I'm confused why you say the system is 70% busy: the vmstat output
shows 70% *idle*.
The vmstat you sent shows good things and ambiguous things:
- si and so are zero, so your not paging/swapping. Thats always step
1. you're fine.
- bi and bo (physical IO) shows pretty high numbers for how many
On Tue, 2004-05-11 at 12:06, Bjoern Metzdorf wrote:
> Has anyone experiences with quad Xeon or quad Opteron setups? I am
> looking at the appropriate boards from Tyan, which would be the only
> option for us to buy such a beast. The 30k+ setups from Dell etc. don't
> fit our budget.
>
> I am th
On 2004-05-11T15:29:46-0600, scott.marlowe wrote:
> The other nice thing about the LSI cards is that you can install >1 and
> the act like one big RAID array. i.e. install two cards with a 20 drive
> RAID0 then make a RAID1 across them, and if one or the other cards itself
> fails, you've still
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bjoern Metzdorf
Sent: Tuesday, May 11, 2004 3:11 PM
To: scott.marlowe
Cc: [EMAIL PROTECTED]; Pgsql-Admin (E-mail)
Subject: Re: [PERFORM] Quad processor options
scott.marlowe wrote:
>>Next drives I&
On Tue, 11 May 2004, Bjoern Metzdorf wrote:
> scott.marlowe wrote:
> > Sure, adaptec makes one, so does lsi megaraid. Dell resells both of
> > these, the PERC3DI and the PERC3DC are adaptec, then lsi in that order, I
> > believe. We run the lsi megaraid with 64 megs battery backed cache.
>
>
scott.marlowe wrote:
Next drives I'll buy will certainly be 15k scsi drives.
Better to buy more 10k drives than fewer 15k drives. Other than slightly
faster select times, the 15ks aren't really any faster.
Good to know. I'll remember that.
In peak times we can get up to 700-800 connections at the
Anjan Dave wrote:
Did you mean to say the trigger-based clustering solution
> is loading the dual CPUs 60-70% right now?
No, this is without any triggers involved.
Performance will not be linear with more processors,
> but it does help with more processes.
> We haven't benchmarked it, but we have
Paul Tuckfield wrote:
Would you mind forwarding the output of "vmstat 10 120" under peak load
period? (I'm asusming this is linux or unix variant) a brief
description of what is happening during the vmstat sample would help a
lot too.
see my other mail.
We are running Linux, Kernel 2.4. As soo
On Tue, 11 May 2004, Bjoern Metzdorf wrote:
> scott.marlowe wrote:
>
> > Well, from what I've read elsewhere on the internet, it would seem the
> > Opterons scale better to 4 CPUs than the basic Xeons do. Of course, the
> > exception to this is SGI's altix, which uses their own chipset and run
: Tue 5/11/2004 4:28 PM
To: Anjan Dave
Cc: [EMAIL PROTECTED]; Pgsql-Admin (E-mail)
Subject: Re: [PERFORM] Quad processor options
Anjan Dave wrote:
> We use XEON Quads (PowerEdge 6650s) and they work nice,
> provided y
scott.marlowe wrote:
Well, from what I've read elsewhere on the internet, it would seem the
Opterons scale better to 4 CPUs than the basic Xeons do. Of course, the
exception to this is SGI's altix, which uses their own chipset and runs
the itanium with very good memory bandwidth.
This is basica
Anjan Dave wrote:
We use XEON Quads (PowerEdge 6650s) and they work nice,
> provided you configure the postgres properly.
> Dell is the cheapest quad you can buy i think.
> You shouldn't be paying 30K unless you are getting high CPU-cache
> on each processor and tons of memory.
good to hear, I trie
it's very good to understand specific choke points you're trying to
address by upgrading so you dont get disappointed. Are you truly CPU
constrained, or is it memory footprint or IO thruput that makes you
want to upgrade?
IMO The best way to begin understanding system choke points is vmstat
o
On Tue, 11 May 2004, Bjoern Metzdorf wrote:
> Hi,
>
> I am curious if there are any real life production quad processor setups
> running postgresql out there. Since postgresql lacks a proper
> replication/cluster solution, we have to buy a bigger machine.
>
> Right now we are running on a dual
n Metzdorf [mailto:[EMAIL PROTECTED]
Sent: Tue 5/11/2004 3:06 PM
To: [EMAIL PROTECTED]
Cc: Pgsql-Admin (E-mail)
Subject: [PERFORM] Quad processor options
Hi,
I am curious if there are any real life production quad proces
Hi,
I am curious if there are any real life production quad processor setups
running postgresql out there. Since postgresql lacks a proper
replication/cluster solution, we have to buy a bigger machine.
Right now we are running on a dual 2.4 Xeon, 3 GB Ram and U160 SCSI
hardware-raid 10.
Has an
32 matches
Mail list logo
