On Tue, 2008-09-23 at 13:02 -0400, Bruce Momjian wrote:
> Merlin Moncure wrote:
> > > although for postgres the thing that you are doing the fsync on is the WAL
> > > log file. that is a single (usually) contiguous file. As such it is very
> > > efficiant to write large chunks of it. so while you
Merlin Moncure wrote:
> > although for postgres the thing that you are doing the fsync on is the WAL
> > log file. that is a single (usually) contiguous file. As such it is very
> > efficiant to write large chunks of it. so while you will degrade from the
> > battery-only mode, the fact that the co
On Sat, Sep 13, 2008 at 5:26 PM, <[EMAIL PROTECTED]> wrote:
> On Fri, 12 Sep 2008, Merlin Moncure wrote:
>>
>> While this is correct, if heavy writing is sustained, especially on
>> large databases, you will eventually outrun the write cache on the
>> controller and things will start to degrade to
On Fri, 12 Sep 2008, Merlin Moncure wrote:
On Fri, Sep 12, 2008 at 5:11 AM, Greg Smith <[EMAIL PROTECTED]> wrote:
On Fri, 12 Sep 2008, Guillaume Cottenceau wrote:
That's the main thing, and nothing else you can do will accelerate that.
Without a useful write cache (which usually means RAM with
On Fri, Sep 12, 2008 at 5:11 AM, Greg Smith <[EMAIL PROTECTED]> wrote:
> On Fri, 12 Sep 2008, Guillaume Cottenceau wrote:
>
> That's the main thing, and nothing else you can do will accelerate that.
> Without a useful write cache (which usually means RAM with a BBU), you'll at
> best get about 100-
On Fri, 12 Sep 2008, Guillaume Cottenceau wrote:
Out of the blue, is it just because when postgresql fsync's after a
write, on a normal system the write has to really happen on disk and
waiting for it to be complete, whereas with BBU cache the fsync is
almost immediate because the write cache
On Fri, 12 Sep 2008, Matthew Wakeling wrote:
Greg, it might be worth you listing a few good RAID controllers. It's almost
an FAQ.
I started doing that at the end of
http://wiki.postgresql.org/wiki/SCSI_vs._IDE/SATA_Disks , that still needs
some work. What I do periodically is sweep through
Craig James writes:
> The performance improvement of a BB cache is amazing.
Could some of you share the insight on why this is the case? I
cannot find much information on it on wikipedia, for example.
Even http://linuxfinances.info/info/diskusage.html doesn't
explain *why*.
Out of the blue, is
On Thu, 11 Sep 2008, Greg Smith wrote:
If you want your database to perform well on writes, the first thing you do
is select a disk controller that performs well, has a well-known stable
driver for your OS, has a reasonably large cache (>=256MB), and has a battery
backup on it.
Greg, it might
On Thu, 11 Sep 2008, Laszlo Nagy wrote:
The expert told me to use RAID 5 but I'm hesitating.
Your "expert" isn't--at least when it comes to database performance.
Trust yourself here, you've got the right general idea.
But I can't make any sense out of exactly how your disks are going to be
Laszlo Nagy wrote:
I cannot spend more money on this computer, but since you are all
talking about battery back up, I'll try to get money from the management
and buy this:
Intel® RAID Smart Battery AXXRSBBU3, optional battery back up for use
with AXXRAK18E and SRCSAS144E. RoHS Complaint.
T
On Thu, Sep 11, 2008 at 11:47 AM, Laszlo Nagy <[EMAIL PROTECTED]> wrote:
> I cannot spend more money on this computer, but since you are all talking
> about battery back up, I'll try to get money from the management and buy
> this:
>
> Intel(R) RAID Smart Battery AXXRSBBU3, optional battery back up
On Thu, Sep 11, 2008 at 10:29 AM, Laszlo Nagy <[EMAIL PROTECTED]> wrote:
> I'm about to buy a new server. It will be a Xeon system with two processors
> (4 cores per processor) and 16GB RAM. Two RAID extenders will be attached
> to an Intel s5000 series motherboard, providing 12 SAS/Serial ATA
> c
going to the same drives. This turns your fast sequential I/O into
random I/O with the accompaning 10x or more performance decrease.
Unless you have a good RAID controller with battery-backed-up cache.
All right. :-) This is what I'll have:
Boxed Intel Server Board S5000PSLROMB with
>>> Kenneth Marshall <[EMAIL PROTECTED]> wrote:
> On Thu, Sep 11, 2008 at 06:18:37PM +0100, Matthew Wakeling wrote:
>> On Thu, 11 Sep 2008, Laszlo Nagy wrote:
>>> So the basic system will reside on a RAID 1 array, created from two
SAS
>>> disks spinning at 15 000 rpm. I will buy 10 pieces of Seaga
On Thu, Sep 11, 2008 at 06:18:37PM +0100, Matthew Wakeling wrote:
> On Thu, 11 Sep 2008, Laszlo Nagy wrote:
>> So the basic system will reside on a RAID 1 array, created from two SAS
>> disks spinning at 15 000 rpm. I will buy 10 pieces of Seagate Barracuda
>> 320GB SATA (ES 7200) disks for the r
On Thu, 11 Sep 2008, Laszlo Nagy wrote:
So the basic system will reside on a RAID 1 array, created from two SAS
disks spinning at 15 000 rpm. I will buy 10 pieces of Seagate Barracuda
320GB SATA (ES 7200) disks for the rest.
That sounds good. Put RAID 1 on the pair, and RAID 1+0 on the rest. I
On Thu, Sep 11, 2008 at 06:29:36PM +0200, Laszlo Nagy wrote:
> The expert told me to use RAID 5 but I'm hesitating. I think that RAID 1+0
> would be much faster, and I/O performance is what I really need.
I think you're right. I think it's a big mistake to use RAID 5 in a
database server where
I'm about to buy a new server. It will be a Xeon system with two
processors (4 cores per processor) and 16GB RAM. Two RAID extenders
will be attached to an Intel s5000 series motherboard, providing 12
SAS/Serial ATA connectors.
The server will run FreeBSD 7.0, PostgreSQL 8, apache, PHP, mail
19 matches
Mail list logo
