: Re: [PERFORM] Scaling further up
For speed, the X86 32 and 64 bit architectures seem to be noticeable
faster than Sparc. However, running Linux or BSD on Sparc make them
pretty fast too, but you lose the fault tolerant support for things
like
hot swappable CPUs or memory.
Agreed.. You
To: Anjan Dave; [EMAIL PROTECTED]
Subject: RE: [PERFORM] Scaling further up
All:
We have a Quad-Intel XEON 2.0GHz (1MB cache), 12GB memory, running
RH9, PG 7.4.0. There's
an internal U320, 10K RPM RAID-10 setup on 4 drives.
We are expecting a pretty high load, a few thousands of 'concurrent
On Fri, Mar 12, 2004 at 06:25:48PM -0500, Anjan Dave wrote:
We upgraded from 8GB to 12GB RAM a month or so ago, but even in the
past, I've never seen the system exhaust on it's system cache (~6GB, in
'top'), while it's swapping.
Some one had mentioned why not have the entire DB in memory?
On Tue, 2004-03-16 at 07:28, Matt Davies wrote:
This is the preferred method, but you could create a memory disk if running
linux. This has several caveats, though.
1. You may have to recompile the kernel for support.
2. You must store the database on a hard drive partition during reboots.
PROTECTED]
Sent: Wednesday, March 10, 2004 6:29 PM
Subject: Re: [PERFORM] Scaling further up
I have some suggestions based on my anecdotal experience.
1. This is a relatively small DB -- the working set will likely be in
RAM at any moment in time, making read I/O time mostly irrelevant.
2
I have some suggestions based on my anecdotal experience.
1. This is a relatively small DB -- the working set will likely be in
RAM at any moment in time, making read I/O time mostly irrelevant.
2. The killer will be write times -- specifically log writes. Small and
heavily synchronized
On Mon, 2004-03-08 at 11:40, William Yu wrote:
Anjan Dave wrote:
Great response, Thanks.
Regarding 12GB memory and 13G db, and almost no I/O, one thing I don't
understand is that even though the OS caches most of the memory and PG
can use it if it needs it, why would the system swap
I'd look at adding more disks first. Depending on what
type of query
load you get, that box sounds like it will be very
much I/O bound
Given a a 13G database on a 12G system, with a low
growth rate, it is likely that there is almost no I/O
for most activities. The exception is
Great response, Thanks.
Regarding 12GB memory and 13G db, and almost no I/O, one thing I don't
understand is that even though the OS caches most of the memory and PG
can use it if it needs it, why would the system swap (not much, only
during peak times)? The SHMMAX is set to 512MB, shared_buffers
On Thu, 4 Mar 2004, Paul Thomas wrote:
On 03/03/2004 18:23 scott.marlowe wrote:
[snip]
There are three factors that affect how fast you can get to the next
sector:
seek time
settle time
rotational latency
Most drives only list the first, and don't bother to mention the other
On 02/03/2004 23:25 johnn wrote:
[snip]
random_page_cost should be set with the following things taken into
account:
- seek speed
Which is not exactly the same thing as spindle speed as it's a combination
of spindle speed and track-to-track speed. I think you'll find that a 15K
rpm disk,
On Tue, Mar 02, 2004 at 04:50:04PM -0500, Anjan Dave wrote:
time/resources to do extensive testing, I am not sure if
Postgres/Solaris9 is really suggested by the community for
high-performance, as opposed to a XEON/Linux setup. Storage being a
separate discussion.
I can tell you from
On 03/03/2004 18:23 scott.marlowe wrote:
[snip]
There are three factors that affect how fast you can get to the next
sector:
seek time
settle time
rotational latency
Most drives only list the first, and don't bother to mention the other
two.
Ah yes, one of my (very) few still functioning brain
Anjan Dave wrote:
We have a Quad-Intel XEON 2.0GHz (1MB cache), 12GB memory, running RH9,
PG 7.4.0. There's an internal U320, 10K RPM RAID-10 setup on 4 drives.
We are expecting a pretty high load, a few thousands of 'concurrent'
users executing either select, insert, update, statments.
The
On Tue, 2004-03-02 at 17:42, William Yu wrote:
Anjan Dave wrote:
We have a Quad-Intel XEON 2.0GHz (1MB cache), 12GB memory, running RH9,
PG 7.4.0. There's an internal U320, 10K RPM RAID-10 setup on 4 drives.
We are expecting a pretty high load, a few thousands of 'concurrent'
users
: [PERFORM] Scaling further up
On Tue, 2004-03-02 at 17:42, William Yu wrote:
Anjan Dave wrote:
We have a Quad-Intel XEON 2.0GHz (1MB cache), 12GB memory, running
RH9,
PG 7.4.0. There's an internal U320, 10K RPM RAID-10 setup on 4
drives.
We are expecting a pretty high load, a few
On Tue, 2 Mar 2004, Anjan Dave wrote:
By lots I mean dozen(s) in a raid 10 array with a good controller.
I believe, for RAID-10, I will need even number of drives.
Correct.
Currently,
the size of the database is about 13GB, and is not expected to grow
exponentially with thousands of
Message-
From: Chris Ruprecht [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 02, 2004 4:17 PM
To: Anjan Dave; [EMAIL PROTECTED]; William Yu
Cc: [EMAIL PROTECTED]
Subject: Re: [PERFORM] Scaling further up
Hi all,
If you have a DB of 'only' 13 GB and you do not expect it to grow much
-
From: scott.marlowe [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 02, 2004 4:16 PM
To: Anjan Dave
Cc: [EMAIL PROTECTED]; William Yu; [EMAIL PROTECTED]
Subject: Re: [PERFORM] Scaling further up
On Tue, 2 Mar 2004, Anjan Dave wrote:
By lots I mean dozen(s) in a raid 10 array with a good
On Tue, 2 Mar 2004, Anjan Dave wrote:
That was part of my original question - whether it makes sense to go for
a mid-range SunFire machine (64bit HW, 64bit OS), which is scalable to
high amounts of memory, and shouldn't have any issues addressing it all.
I've had that kind of setup once
On Tue, Mar 02, 2004 at 02:16:24PM -0700, scott.marlowe wrote:
It's a common misconception that faster RPM drives are a lot faster,
when, in fact, their only speed advantage is slight faster seeks.
The areal density of faster spinning hard drives tends to be
somewhat less than the slower
On Mar 2, 2004, at 5:36 PM, scott.marlowe wrote:
Some folks on the list have experience with Postgresql on Solaris, and
they generally say they use Solaris not for performance reasons, but
for
reliability reasons. I.e. the bigger Sun hardware is fault tolerant.
Solaris isn't nearly as bad for
On Tue, 2004-03-02 at 18:24, Anjan Dave wrote:
Can you describe the vendors/components of a cheap SAN setup?
heh.. Excellent point.
My point was that you could get away with a smaller setup (number of
disks) if it doesn't have to deal with reads and writes are not time
dependent than you will
Title: Message
All:
We havea
Quad-Intel XEON 2.0GHz (1MB cache), 12GB memory, running RH9, PG 7.4.0. There's
an internal U320, 10K RPM RAID-10 setup on 4 drives.
We are expecting
apretty high load,a few thousands of 'concurrent' users executing
either select, insert, update, statments.
Anjan,
Other than the disks, I am curious what other people are using in terms
of the horsepower needed. The Quad server has been keeping up, but we
are expecting quite high loads in the near future, and I am not sure if
just by having the disks on a high-end storage will do it.
Do a
25 matches
Mail list logo
