erformance
Subject: 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 C
gt; -Original Message-
> From: Fred Moyer [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, March 02, 2004 5:57 AM
> To: William Yu; Anjan Dave
> Cc: [EMAIL PROTECTED]
> Subject: Re: [PERFORM] Scaling further up
>
> On Tue, 2004-03-02 at 17:42, William Yu wrote:
> > Anjan
: 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 l
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 reboot
Quoting Andrew Sullivan <[EMAIL PROTECTED]>:
> 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.
> >
> > S
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
AIL PROTECTED]>
To: <[EMAIL 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 mome
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 writes
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 syst
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 checkpointi
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
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 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 cell
On Wed, 3 Mar 2004, Paul Thomas wrote:
>
> 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 an
John,
> This would imply that an upgrade in drive RPM should be accompanied by
> a decrease in random_page_cost, correct?
Maybe. Maybe not. Tom's Hardware did some Bonnie++ testing with a variety
of new drives last year. They were moderately surprised to find that there
were "faster" drive
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 expe
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, wh
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
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 P
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 sp
> 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 can get a Quad Opteron with 16GB
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 te
ssage-
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 arra
--Original 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
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
Anjan,
> Question - Are 73GB drives supposed to give better performance because
> of higher number of platters?
Not for your situation, no. Your issue is random seek times for multiple
simultaneous seek requests and batched checkpoint updates. Things that help
with this are:
More spindles
B
ubject: Re: [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.
> >
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'
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 qui
After a long battle with technology, [EMAIL PROTECTED] (Josh Berkus), an earthling,
wrote:
>> 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
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 perf
> 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'
users executing either
> select, insert, update, statments.
> Wha
Title: Message
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' users executing
either select, insert, update, statments
33 matches
Mail list logo
