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
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.
I see you've got an LSI Megaraid card with oodles of Cache. However, don't underestimate the power of the software RAID implementation that Red Hat Linux comes with.
We're using RHE 2.1 and I can recommend Red Hat Enterprise Linux if you want an excellent implementation of software RAID. In
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:
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
It appears that your CPU is 'slow' while your disk subsystem is 'fast'.
I had once such situation with 15 kRPM drives and ~500MHz Pentium III. On that
system, the best solution was to either increase effective_cache_size or
decrease random_page_cost (the latter obviously has to do with the fast
On 12 May 2004, at 12:17 PM, Manfred Koizar wrote:
On Tue, 11 May 2004 15:46:25 -0700, Paul Tuckfield <[EMAIL PROTECTED]>
wrote:
- I'll bet you have a low value for shared buffers, like 1. On
your 3G system
you should ramp up the value to at least 1G (125000 8k buffers)
In most cases this i
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,
...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
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, 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
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
Did you mean to say the trigger-based clustering solution is loading the dual CPUs
60-70% right now?
Performance will not be linear with more processors, but it does help with more
processes. We haven't benchmarked it, but we haven't had any problems also so far in
terms of performance.
Pric
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
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.
I am actually curious, have you researched
25 matches
Mail list logo
