Horton
Menu

Thread

  1. which Xeon processors don't have the context switching problem

    Geoffrey <esoteric@3times25.net> — 2007-02-23T19:05:57Z

    I recall a reference on the list indicating that newer Xeon processors 
don't suffer from the context switching problem reported last year.

In searching the archives, I can't find any specific info indentifying 
which Xeon processors don't have this problem.

Anyone point me to a reference?

Is this in any way related to the version of Postgresql one is running? 
  We're headed for 8, but have a bit of work before we can get there. 
We are currently on 7.4.16.

Thanks for any info.
-- 
Until later, Geoffrey

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety.
  - Benjamin Franklin

  2. Re: which Xeon processors don't have the context switching problem

    Claus Guttesen <kometen@gmail.com> — 2007-02-23T19:33:41Z

    > I recall a reference on the list indicating that newer Xeon processors
> don't suffer from the context switching problem reported last year.
>
> In searching the archives, I can't find any specific info indentifying
> which Xeon processors don't have this problem.
>
> Anyone point me to a reference?

We recently migrated to a woodcrest @ 3 GHz from a 2 Ghz opteron. The
woodcrest seems to be enjoying doing db-related work. I don't have
numbers other than load is much lower now.

> Is this in any way related to the version of Postgresql one is running?
>   We're headed for 8, but have a bit of work before we can get there.
> We are currently on 7.4.16.

We are at 7.4.14 which works fine atm.

regards
Claus

  3. Re: which Xeon processors don't have the context switching problem

    Steinar H. Gunderson <sgunderson@bigfoot.com> — 2007-02-23T19:38:54Z

    On Fri, Feb 23, 2007 at 02:05:57PM -0500, Geoffrey wrote:
> In searching the archives, I can't find any specific info indentifying 
> which Xeon processors don't have this problem.

AFAIK the cut-off point is at the Woodcrests. They are overall much better
suited to PostgreSQL than the older Xeons were.

It's slightly unfortunate that AMD and Intel cling to the Opteron and Xeon
names even though they're making significant architecture changes, but that's
life, I guess.

/* Steinar */
-- 
Homepage: http://www.sesse.net/

  4. Re: which Xeon processors don't have the context switching problem

    Alvaro Herrera <alvherre@commandprompt.com> — 2007-02-23T19:53:18Z

    Steinar H. Gunderson wrote:
> On Fri, Feb 23, 2007 at 02:05:57PM -0500, Geoffrey wrote:
> > In searching the archives, I can't find any specific info indentifying 
> > which Xeon processors don't have this problem.
> 
> AFAIK the cut-off point is at the Woodcrests. They are overall much better
> suited to PostgreSQL than the older Xeons were.
> 
> It's slightly unfortunate that AMD and Intel cling to the Opteron and Xeon
> names even though they're making significant architecture changes, but that's
> life, I guess.

AFAIR Intel has been calling their server processors Xeon since Pentium
Pro's, at least.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

  5. Re: which Xeon processors don't have the context switching problem

    Steinar H. Gunderson <sgunderson@bigfoot.com> — 2007-02-23T20:01:01Z

    On Fri, Feb 23, 2007 at 04:53:18PM -0300, Alvaro Herrera wrote:
>> It's slightly unfortunate that AMD and Intel cling to the Opteron and Xeon
>> names even though they're making significant architecture changes, but that's
>> life, I guess.
> AFAIR Intel has been calling their server processors Xeon since Pentium
> Pro's, at least.

Yes, that was sort of my point. :-)

/* Steinar */
-- 
Homepage: http://www.sesse.net/

  6. Re: which Xeon processors don't have the context switching problem

    Josh Berkus <josh@agliodbs.com> — 2007-02-23T21:30:56Z

    Geoffrey,

> I recall a reference on the list indicating that newer Xeon processors
> don't suffer from the context switching problem reported last year.

Just to be clear, it's a software problem which affects all architectures, 
including AMD and Sparc.  It's just *worse* on the PIII and P4 generation 
Xeons.

-- 
--Josh

Josh Berkus
PostgreSQL @ Sun
San Francisco

  7. Re: which Xeon processors don't have the context switching problem

    Geoffrey <esoteric@3times25.net> — 2007-02-23T21:33:19Z

    Josh Berkus wrote:
> Geoffrey,
> 
>> I recall a reference on the list indicating that newer Xeon processors
>> don't suffer from the context switching problem reported last year.
> 
> Just to be clear, it's a software problem which affects all architectures, 
> including AMD and Sparc.  It's just *worse* on the PIII and P4 generation 
> Xeons.

Thanks, that's what I need to hear.  They've since cut a deal for 
Operton based hardware, so the point is now moot.

-- 
Until later, Geoffrey

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety.
  - Benjamin Franklin

  8. Re: which Xeon processors don't have the context switching problem

    Joshua D. Drake <jd@commandprompt.com> — 2007-02-23T21:33:29Z

    Josh Berkus wrote:
> Geoffrey,
> 
>> I recall a reference on the list indicating that newer Xeon processors
>> don't suffer from the context switching problem reported last year.
> 
> Just to be clear, it's a software problem which affects all architectures, 
> including AMD and Sparc.  It's just *worse* on the PIII and P4 generation 
> Xeons.
> 

Also isn't it pretty much *not* a problem with current versions of
PostgreSQL?

Joshua D. Drake

-- 

      === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive  PostgreSQL solutions since 1997
             http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/

  9. Re: which Xeon processors don't have the context switching problem

    Geoffrey <esoteric@3times25.net> — 2007-02-23T21:49:08Z

    Joshua D. Drake wrote:
> Josh Berkus wrote:
>> Geoffrey,
>>
>>> I recall a reference on the list indicating that newer Xeon processors
>>> don't suffer from the context switching problem reported last year.
>> Just to be clear, it's a software problem which affects all architectures, 
>> including AMD and Sparc.  It's just *worse* on the PIII and P4 generation 
>> Xeons.
>>
> 
> Also isn't it pretty much *not* a problem with current versions of
> PostgreSQL?

As I've heard.  We're headed for 8 as soon as possible, but until we get 
our code ready, we're on 7.4.16.

-- 
Until later, Geoffrey

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety.
  - Benjamin Franklin

  10. Re: which Xeon processors don't have the context switching problem

    Guillaume Smet <guillaume.smet@gmail.com> — 2007-02-23T22:23:10Z

    On 2/23/07, Joshua D. Drake <jd@commandprompt.com> wrote:
> Also isn't it pretty much *not* a problem with current versions of
> PostgreSQL?

We had a really *big* scalability problem with a quad Xeon MP 2.2 and
PostgreSQL 7.4. The problem is mostly gone since we upgraded to 8.1 a
year ago.

Woodcrest seems to perform really well with PostgreSQL according to
what I can read on the Internet so we will probably change the server
for a dual Woodcrest in a few months.

--
Guillaume

  11. Re: which Xeon processors don't have the context switching problem

    Guillaume Smet <guillaume.smet@gmail.com> — 2007-02-23T22:25:04Z

    On 2/23/07, Geoffrey <esoteric@3times25.net> wrote:
> As I've heard.  We're headed for 8 as soon as possible, but until we get
> our code ready, we're on 7.4.16.

You should move to at least 8.1 and possibly 8.2. It's not a good idea
to upgrade only to 8 IMHO.

--
Guillaume

  12. Re: which Xeon processors don't have the context switching problem

    Magnus Hagander <magnus@hagander.net> — 2007-02-24T00:56:22Z

    Alvaro Herrera wrote:
> Steinar H. Gunderson wrote:
>> On Fri, Feb 23, 2007 at 02:05:57PM -0500, Geoffrey wrote:
>>> In searching the archives, I can't find any specific info indentifying 
>>> which Xeon processors don't have this problem.
>> AFAIK the cut-off point is at the Woodcrests. They are overall much better
>> suited to PostgreSQL than the older Xeons were.
>>
>> It's slightly unfortunate that AMD and Intel cling to the Opteron and Xeon
>> names even though they're making significant architecture changes, but that's
>> life, I guess.
> 
> AFAIR Intel has been calling their server processors Xeon since Pentium
> Pro's, at least.
> 
Almost. Xeon was the new name for the "Pro" series. Instead of Pentium
II Pro, we got Pentium II Xeon. The whole Pentium Pro line was a server
line, which is why initial Pentium-II CPUs were significantly slower for
server apps than the much older ppro (which still runs pg at a
reasonable speed if you have enough of them and a low budget, btw)

//Magnus

  13. Re: which Xeon processors don't have the context switching problem

    Geoffrey <esoteric@3times25.net> — 2007-02-24T01:28:31Z

    Guillaume Smet wrote:
> On 2/23/07, Geoffrey <esoteric@3times25.net> wrote:
>> As I've heard.  We're headed for 8 as soon as possible, but until we get
>> our code ready, we're on 7.4.16.
> 
> You should move to at least 8.1 and possibly 8.2. It's not a good idea
> to upgrade only to 8 IMHO.

When I said 8, I meant whatever the latest greatest 8 is.  Right now, 
that looks like 8.2.3.

-- 
Until later, Geoffrey

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety.
  - Benjamin Franklin

  14. Re: which Xeon processors don't have the context switching problem

    Joshua D. Drake <jd@commandprompt.com> — 2007-02-24T20:50:08Z

    Geoffrey wrote:
> Guillaume Smet wrote:
>> On 2/23/07, Geoffrey <esoteric@3times25.net> wrote:
>>> As I've heard.  We're headed for 8 as soon as possible, but until we get
>>> our code ready, we're on 7.4.16.
>>
>> You should move to at least 8.1 and possibly 8.2. It's not a good idea
>> to upgrade only to 8 IMHO.
> 
> When I said 8, I meant whatever the latest greatest 8 is.  Right now,
> that looks like 8.2.3.

No. The latest version of 8.2 is 8.2.3, there is also 8.1 which is at
8.1.8 and 8.0 which is at 8.0.12.

They are all different *major* releases.

IMO, nobody should be running anything less than 8.1.8.

Sincerely,

Joshua D. Drake


-- 

      === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive  PostgreSQL solutions since 1997
             http://www.commandprompt.com/

Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
PostgreSQL Replication: http://www.commandprompt.com/products/

  15. Two hard drives --- what to do with them?

    Carlos Moreno <moreno_pg@mochima.com> — 2007-02-25T03:39:09Z

    Say that I have a dual-core processor  (AMD64), with, say, 2GB of memory
to run PostgreSQL 8.2.3 on Fedora Core X.

I have the option to put two hard disks (SATA2, most likely);  I'm 
wondering
what would be the optimal configuration from the point of view of 
performance.

I do have the option to configure it in RAID-0, but I'm sort of 
reluctant;  I think
there's the possibility that having two filesystems that can be accessed 
truly
simultaneously can be more beneficial.  The question is:  does PostgreSQL
have separate, independent areas that require storage such that performance
would be noticeably boosted if the multiple storage operations could be 
done
simultaneously?

Notice that even with RAID-0, the "twice the performance" may turn into
an illusion --- if the system requires access from "distant" areas of 
the disk
("distant" as in  many tracks apart), then the back-and-forth travelling of
the heads would take precedence over the doubled access speed ...  Though
maybe it depends on whether accesses are in small chunks  (in which case
the cache of the hard disks could take precedence).

Coming back to the option of two independent disks --- the thing is:  if it
turns out that two independent disks are a better option, how should I
configure the system and the mount points?  And how would I configure
PostgreSQL to take advantage of that?

Advice, anyone?

Thanks,

Carlos
--

  16. Re: Two hard drives --- what to do with them?

    Tom Lane <tgl@sss.pgh.pa.us> — 2007-02-25T03:58:51Z

    Carlos Moreno <moreno_pg@mochima.com> writes:
> The question is: does PostgreSQL have separate, independent areas that
> require storage such that performance would be noticeably boosted if
> the multiple storage operations could be done simultaneously?

The standard advice in this area is to put pg_xlog on a separate
spindle; although that probably is only important for update-intensive
applications.  You did not tell us anything about your application...

			regards, tom lane

  17. Re: Two hard drives --- what to do with them?

    Alexander Staubo <alex@purefiction.net> — 2007-02-25T04:08:34Z

    On Feb 25, 2007, at 04:39 , Carlos Moreno wrote:

> I do have the option to configure it in RAID-0, but I'm sort of  
> reluctant;  I think
> there's the possibility that having two filesystems that can be  
> accessed truly
> simultaneously can be more beneficial.  The question is:  does  
> PostgreSQL
> have separate, independent areas that require storage such that  
> performance
> would be noticeably boosted if the multiple storage operations  
> could be done
> simultaneously?

Putting the WAL (aka pg_xlog) on a separate disk will take some load  
off your main database disk. See http://www.varlena.com/GeneralBits/ 
Tidbits/perf.html for this.

It is also possible to put individual tables and/or indexes on  
separate disks by using tablespaces: "For example, an index which is  
very heavily used can be placed on a very fast, highly available  
disk, such as an expensive solid state device. At the same time a  
table storing archived data which is rarely used or not performance  
critical could be stored on a less expensive, slower disk  
system." (http://www.postgresql.org/docs/8.2/interactive/manage-ag- 
tablespaces.html)

In both cases, the performance benefits tend to be relative to the  
amount of write activity you experience, and the latter solution  
assumes you know where the hotspots are. If you have two tables that  
see continuous, intense write activity, for example, putting each on  
a separate disk

Alexander.

  18. Re: Two hard drives --- what to do with them?

    Peter Kovacs <maxottovonstirlitz@gmail.com> — 2007-02-25T22:11:01Z

    A related question:
Is it sufficient to disable write cache only on the disk where pg_xlog
is located? Or should write cache be disabled on both disks?

Thanks
Peter

On 2/25/07, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Carlos Moreno <moreno_pg@mochima.com> writes:
> > The question is: does PostgreSQL have separate, independent areas that
> > require storage such that performance would be noticeably boosted if
> > the multiple storage operations could be done simultaneously?
>
> The standard advice in this area is to put pg_xlog on a separate
> spindle; although that probably is only important for update-intensive
> applications.  You did not tell us anything about your application...
>
>                         regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 7: You can help support the PostgreSQL project by donating at
>
>                 http://www.postgresql.org/about/donate
>

  19. Re: Two hard drives --- what to do with them?

    Jeff Davis <pgsql@j-davis.com> — 2007-02-26T21:51:06Z

    On Sun, 2007-02-25 at 23:11 +0100, Peter Kovacs wrote:
> A related question:
> Is it sufficient to disable write cache only on the disk where pg_xlog
> is located? Or should write cache be disabled on both disks?
> 

When PostgreSQL does a checkpoint, it thinks the data pages before the
checkpoint have successfully made it to disk. 

If the write cache holds those data pages, and then loses them, there's
no way for PostgreSQL to recover. So use a battery backed cache or turn
off the write cache.

Regards,
	Jeff Davis

  20. Re: Two hard drives --- what to do with them?

    Peter Kovacs <maxottovonstirlitz@gmail.com> — 2007-02-27T00:11:24Z

    On 2/26/07, Jeff Davis <pgsql@j-davis.com> wrote:
> On Sun, 2007-02-25 at 23:11 +0100, Peter Kovacs wrote:
> > A related question:
> > Is it sufficient to disable write cache only on the disk where pg_xlog
> > is located? Or should write cache be disabled on both disks?
> >
>
> When PostgreSQL does a checkpoint, it thinks the data pages before the
> checkpoint have successfully made it to disk.
>
> If the write cache holds those data pages, and then loses them, there's
> no way for PostgreSQL to recover. So use a battery backed cache or turn
> off the write cache.

Sorry for for not being familar with storage techonologies... Does
"battery" here mean battery in the common sense of the word - some
kind of independent power supply? Shouldn't the disk itself be backed
by a battery? As should the entire storage subsystem?

Thanks
Peter

>
> Regards,
>         Jeff Davis
>
>

  21. Re: Two hard drives --- what to do with them?

    Jeff Davis <pgsql@j-davis.com> — 2007-02-27T00:25:14Z

    On Tue, 2007-02-27 at 01:11 +0100, Peter Kovacs wrote:
> On 2/26/07, Jeff Davis <pgsql@j-davis.com> wrote:
> > On Sun, 2007-02-25 at 23:11 +0100, Peter Kovacs wrote:
> > > A related question:
> > > Is it sufficient to disable write cache only on the disk where pg_xlog
> > > is located? Or should write cache be disabled on both disks?
> > >
> >
> > When PostgreSQL does a checkpoint, it thinks the data pages before the
> > checkpoint have successfully made it to disk.
> >
> > If the write cache holds those data pages, and then loses them, there's
> > no way for PostgreSQL to recover. So use a battery backed cache or turn
> > off the write cache.
> 
> Sorry for for not being familar with storage techonologies... Does
> "battery" here mean battery in the common sense of the word - some
> kind of independent power supply? Shouldn't the disk itself be backed
> by a battery? As should the entire storage subsystem?
> 

Yes, a battery that can hold power to keep data alive in the write cache
in case of power failure, etc., for a long enough time to recover and
commit the data to disk.

So, a write cache is OK (even for pg_xlog) if it is durable (i.e. on
permanent storage or backed by enough power to make sure it gets there).
However, if PostgreSQL has no way to know whether a write is durable or
not, it can't guarantee the data is safe.

The reason this becomes an issue is that many consumer-grade disks have
write cache enabled by default and no way to make sure the cached data
actually gets written. So, essentially, these disks "lie" and say they
wrote the data, when in reality, it's in volatile memory. It's
recommended that you disable write cache on such a device.

Regards,
	Jeff Davis

  22. Re: Two hard drives --- what to do with them?

    Shane Ambler <pgsql@sheeky.biz> — 2007-02-27T05:05:13Z

    Jeff Davis wrote:

>> Sorry for for not being familar with storage techonologies... Does
>> "battery" here mean battery in the common sense of the word - some
>> kind of independent power supply? Shouldn't the disk itself be backed
>> by a battery? As should the entire storage subsystem?
>>
> 
> Yes, a battery that can hold power to keep data alive in the write cache
> in case of power failure, etc., for a long enough time to recover and
> commit the data to disk.

Just to expand a bit - the battery backup options are available on some 
raid cards - that is where you would be looking for it. I don't know of 
any hard drives that have it built in.

Of cause another reason to have a UPS for the server - keep it running 
long enough after the clients have gone down so that it can ensure 
everything is on disk and shuts down properly.

> So, a write cache is OK (even for pg_xlog) if it is durable (i.e. on
> permanent storage or backed by enough power to make sure it gets there).
> However, if PostgreSQL has no way to know whether a write is durable or
> not, it can't guarantee the data is safe.
> 
> The reason this becomes an issue is that many consumer-grade disks have
> write cache enabled by default and no way to make sure the cached data
> actually gets written. So, essentially, these disks "lie" and say they
> wrote the data, when in reality, it's in volatile memory. It's
> recommended that you disable write cache on such a device.

 From all that I have heard this is another advantage of SCSI disks - 
they honor these settings as you would expect - many IDE/SATA disks 
often say "sure I'll disable the cache" but continue to use it or don't 
retain the setting after restart.


-- 

Shane Ambler
pgSQL@Sheeky.Biz

Get Sheeky @ http://Sheeky.Biz

  23. Re: Two hard drives --- what to do with them?

    Peter Kovacs <maxottovonstirlitz@gmail.com> — 2007-02-27T08:27:52Z

    On 2/27/07, Shane Ambler <pgsql@sheeky.biz> wrote:
> Jeff Davis wrote:
>
> >> Sorry for for not being familar with storage techonologies... Does
> >> "battery" here mean battery in the common sense of the word - some
> >> kind of independent power supply? Shouldn't the disk itself be backed
> >> by a battery? As should the entire storage subsystem?
> >>
> >
> > Yes, a battery that can hold power to keep data alive in the write cache
> > in case of power failure, etc., for a long enough time to recover and
> > commit the data to disk.
>
> Just to expand a bit - the battery backup options are available on some
> raid cards - that is where you would be looking for it. I don't know of
> any hard drives that have it built in.
>
> Of cause another reason to have a UPS for the server - keep it running
> long enough after the clients have gone down so that it can ensure
> everything is on disk and shuts down properly.
>
> > So, a write cache is OK (even for pg_xlog) if it is durable (i.e. on
> > permanent storage or backed by enough power to make sure it gets there).
> > However, if PostgreSQL has no way to know whether a write is durable or
> > not, it can't guarantee the data is safe.
> >
> > The reason this becomes an issue is that many consumer-grade disks have
> > write cache enabled by default and no way to make sure the cached data
> > actually gets written. So, essentially, these disks "lie" and say they
> > wrote the data, when in reality, it's in volatile memory. It's
> > recommended that you disable write cache on such a device.
>
>  From all that I have heard this is another advantage of SCSI disks -
> they honor these settings as you would expect - many IDE/SATA disks
> often say "sure I'll disable the cache" but continue to use it or don't
> retain the setting after restart.

As far as I know, SCSI drives also have "write cache" which is turned
off by default, but can be turned on (e.g. with the sdparm utility on
Linux). The reason I am so much interested in how write cache is
typically used (on or off) is that I recently ran our benchmarks on a
machine with SCSI disks and those benchmarks with high commit ratio
suffered significantly compared to our previous results
"traditionally" obtained on machines with IDE drives.

I wonder if running a machine on a UPS + 1 hot standby internal PS is
equivalent, in terms of data integrity, to using battery backed write
cache. Instinctively, I'd think that UPS + 1 hot standby internal PS
is better, since this setup also provides for the disk to actually
write out the content of the cache -- as you pointed out.

Thanks
Peter

>
>
> --
>
> Shane Ambler
> pgSQL@Sheeky.Biz
>
> Get Sheeky @ http://Sheeky.Biz
>

  24. Re: Two hard drives --- what to do with them?

    Ben Chobot <bench@silentmedia.com> — 2007-02-27T15:57:15Z

    Just remember that batteries (in both RAID cards and UPSes) wear out  
and will eventually have to be replaced. It depends how critical your  
data is, but if you only have a UPS, you risk badness in the off  
chance that your power fails and you haven't replaced your UPS battery.

On Feb 27, 2007, at 12:27 AM, Peter Kovacs wrote:

> I wonder if running a machine on a UPS + 1 hot standby internal PS is
> equivalent, in terms of data integrity, to using battery backed write
> cache. Instinctively, I'd think that UPS + 1 hot standby internal PS
> is better, since this setup also provides for the disk to actually
> write out the content of the cache -- as you pointed out.

  25. Re: Two hard drives --- what to do with them?

    Shane Ambler <pgsql@sheeky.biz> — 2007-02-27T18:51:41Z

    Peter Kovacs wrote:

>> > The reason this becomes an issue is that many consumer-grade disks have
>> > write cache enabled by default and no way to make sure the cached data
>> > actually gets written. So, essentially, these disks "lie" and say they
>> > wrote the data, when in reality, it's in volatile memory. It's
>> > recommended that you disable write cache on such a device.
>>
>>  From all that I have heard this is another advantage of SCSI disks -
>> they honor these settings as you would expect - many IDE/SATA disks
>> often say "sure I'll disable the cache" but continue to use it or don't
>> retain the setting after restart.
> 
> As far as I know, SCSI drives also have "write cache" which is turned
> off by default, but can be turned on (e.g. with the sdparm utility on
> Linux). The reason I am so much interested in how write cache is
> typically used (on or off) is that I recently ran our benchmarks on a
> machine with SCSI disks and those benchmarks with high commit ratio
> suffered significantly compared to our previous results
> "traditionally" obtained on machines with IDE drives.

Most likely - with write cache, when the drive gets the data it puts it 
into cache and then says "yep all done" and you continue on as it puts 
it on the disk. But if the power goes out as it's doing that you got 
trouble.

The difference between SCSI and IDE/SATA in this case is a lot if not 
all IDE/SATA drives tell you that the cache is disabled when you ask it 
to but they either don't actually disable it or they don't retain the 
setting so you get caught later. SCSI disks can be trusted when you set 
this option.

> I wonder if running a machine on a UPS + 1 hot standby internal PS is
> equivalent, in terms of data integrity, to using battery backed write
> cache. Instinctively, I'd think that UPS + 1 hot standby internal PS
> is better, since this setup also provides for the disk to actually
> write out the content of the cache -- as you pointed out.
> 

This is covering two different scenarios.
The UPS maintains power in the event of a black out.
The hot standby internal PS maintains power when the first PS dies.

It is a good choice to have both as a PS dying will be just as bad as 
losing power without a UPS and the UPS won't save you if the PS goes.

A battery backed raid card sits in between these - as long as the 
drive's write cache is off - the raid card will hold data that was sent 
to disk until it confirms it is written to disk. The battery backup will 
even hold that data until the machine is switched back on when it 
completes the writing to disk. That would cover you even if the PS goes.


-- 

Shane Ambler
pgSQL@Sheeky.Biz

Get Sheeky @ http://Sheeky.Biz

  26. Re: Two hard drives --- what to do with them?

    Jeff Davis <pgsql@j-davis.com> — 2007-02-27T19:23:49Z

    On Tue, 2007-02-27 at 09:27 +0100, Peter Kovacs wrote:
> I wonder if running a machine on a UPS + 1 hot standby internal PS is
> equivalent, in terms of data integrity, to using battery backed write
> cache. Instinctively, I'd think that UPS + 1 hot standby internal PS
> is better, since this setup also provides for the disk to actually
> write out the content of the cache -- as you pointed out.

It's all about the degree of safety. A battery-backed cache on a RAID
controller sits below all of these points of failure:

* External power
* Power supply
* Operating system

and with proper system administration, can recover from any transient
errors in the above. Keep in mind that it can only recover from
transient failures: if you have a long blackout that outlasts your UPS
and cache battery, you can still have data loss. Also, you need a very
responsive system administrator that can make sure that data gets to
disk in case of failure.

Let's say you have a RAID system but you rely on the UPS to make sure
the data hits disk. Well, now if you have an OS crash (caused by another
piece of hardware failing, perhaps), you've lost your data.

If you can afford it (in terms of dollars or performance hit) go with
the safe solution.

Also, put things in context. The chances of failure due to these kinds
of things are fairly low. If it's more likely that someone spills coffee
on your server than the UPS fails, it doesn't make sense to spend huge
amounts of money on NVRAM (or something) to store your data. So identify
the highest-risk scenarios and prevent those first.

Also keep in mind what the cost of failure is: a few hundred bucks more
on a better RAID controller is probably a good value if it prevents a
day of chaos and unhappy customers.

Regards,
	Jeff Davis

  27. Re: Two hard drives --- what to do with them?

    Scott Marlowe <smarlowe@g2switchworks.com> — 2007-02-27T19:38:56Z

    On Tue, 2007-02-27 at 13:23, Jeff Davis wrote:
> Also, put things in context. The chances of failure due to these kinds
> of things are fairly low. If it's more likely that someone spills coffee
> on your server than the UPS fails, it doesn't make sense to spend huge
> amounts of money on NVRAM (or something) to store your data. So identify
> the highest-risk scenarios and prevent those first.
> 
> Also keep in mind what the cost of failure is: a few hundred bucks more
> on a better RAID controller is probably a good value if it prevents a
> day of chaos and unhappy customers.

Just FYI, I can testify to the happiness a good battery backed caching
RAID controller can bring.  I had the only server that survived a
complete power grid failure in the data center where I used to work.  A
piece of wire blew out a power conditioner, which killed the other power
conditioner, all three UPSes and the switch to bring the diesel
generator online.

the only problem the pgsql server had coming back up was that it had
remote nfs mounts it used for file storage that weren't able to boot up
fast enough so we just waited a few minutes and rebooted it.

All of our other database servers had to be restored from backup due to
massive data corruption because someone had decided that NFS mounts were
a good idea under databases.

  28. Re: Two hard drives --- what to do with them?

    Bruno Wolff III <bruno@wolff.to> — 2007-03-01T03:28:46Z

    On Sun, Feb 25, 2007 at 23:11:01 +0100,
  Peter Kovacs <maxottovonstirlitz@gmail.com> wrote:
> A related question:
> Is it sufficient to disable write cache only on the disk where pg_xlog
> is located? Or should write cache be disabled on both disks?

With recent linux kernels you may also have the option to use write
barriers instead of disabling caching. You need to make sure all of
your stacked block devices will handle it and most versions of software
raid (other than 1) won't. This won't be a lot faster, since at sync
points the OS needs to order a cache flush, but it does give the disks a chance
to reorder some commands in between flushes.

  29. Re: Two hard drives --- what to do with them?

    Bruno Wolff III <bruno@wolff.to> — 2007-03-01T03:31:12Z

    On Tue, Feb 27, 2007 at 15:35:13 +1030,
  Shane Ambler <pgsql@Sheeky.Biz> wrote:
> 
> From all that I have heard this is another advantage of SCSI disks - 
> they honor these settings as you would expect - many IDE/SATA disks 
> often say "sure I'll disable the cache" but continue to use it or don't 
> retain the setting after restart.

It is easy enough to tests if your disk lie about disabling the cache.
I doubt that it is all that common for modern disks to do that.

  30. Re: Two hard drives --- what to do with them?

    Bruno Wolff III <bruno@wolff.to> — 2007-03-01T03:35:21Z

    On Wed, Feb 28, 2007 at 05:21:41 +1030,
  Shane Ambler <pgsql@Sheeky.Biz> wrote:
> 
> The difference between SCSI and IDE/SATA in this case is a lot if not 
> all IDE/SATA drives tell you that the cache is disabled when you ask it 
> to but they either don't actually disable it or they don't retain the 
> setting so you get caught later. SCSI disks can be trusted when you set 
> this option.

I have some Western Digital Caviars and they don't lie about disabling
write caching.

  31. Re: which Xeon processors don't have the context switching problem

    Geoffrey <esoteric@3times25.net> — 2007-03-05T13:23:41Z

    Joshua D. Drake wrote:
> Geoffrey wrote:
>> Guillaume Smet wrote:
>>> On 2/23/07, Geoffrey <esoteric@3times25.net> wrote:
>>>> As I've heard.  We're headed for 8 as soon as possible, but until we get
>>>> our code ready, we're on 7.4.16.
>>> You should move to at least 8.1 and possibly 8.2. It's not a good idea
>>> to upgrade only to 8 IMHO.
>> When I said 8, I meant whatever the latest greatest 8 is.  Right now,
>> that looks like 8.2.3.
> 
> No. The latest version of 8.2 is 8.2.3, there is also 8.1 which is at
> 8.1.8 and 8.0 which is at 8.0.12.
> 
> They are all different *major* releases.

Yes I am aware of the various releases.  My bad in that my reference to 
'8' was lazy and did not indicate the full release.  Our intention is to 
move to the latest 8.2.* when we are able.

> IMO, nobody should be running anything less than 8.1.8.

Same old thing, time and money.  Too busy bailing the boat to patch it 
right now...

-- 
Until later, Geoffrey

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety.
  - Benjamin Franklin