Re: [PERFORM] Hardware/OS recommendations for large databases (

2005-11-16 Thread mudfoot
Yeah those big disks arrays are real sweet. One day last week I was in a data center in Arizona when the big LSI/Storagetek array in the cage next to mine had a hard drive failure. So the alarm shrieked at like 13225535 decibles continuously for hours. BEEEP BP BP BP. Of course sinc

Re: [PERFORM] Is There Any Way ....

2005-09-29 Thread mudfoot
Quoting Lane Van Ingen <[EMAIL PROTECTED]>: > ... to do the following: > (1) Make a table memory-resident only ? Put it on a RAM filesystem. On Linux, shmfs. On *BSD, mfs. Solaris, tmpfs. > (2) Set up user variables in memory that are persistent across all > sessions, for > as long

Re: [PERFORM] Battery Backed Cache for RAID

2005-09-14 Thread mudfoot
Bear in mind you will lose data if the raid controller itself fails (or the cache memory module). Many solutions have mirrored cache for this reason. But that's more $$, depending on the risks you want to take. Quoting Arjen van der Meijden <[EMAIL PROTECTED]>: > On 14-9-2005 22:03, Alvaro Herr

Re: [PERFORM] High load and iowait but no disk access

2005-08-30 Thread mudfoot
This might be optimal behavior from the hardware. Random reads are hard to optimize for--except if you have enough physical memory to hold the entire dataset. Cached reads (either in array controller or OS buffer cache) should return nearly immediately. But random reads probably aren't cached.

Re: [PERFORM] Performance problem using V3 protocol in jdbc driver

2005-08-17 Thread mudfoot
Quoting Barry Lind <[EMAIL PROTECTED]>: > > > What I see when running the V3 protocol under 'top' is that the postgres > processes are routinely using 15% or more of the CPU each, when running > the V2 protocol they use more like 0.3%. > > > > Does anyone have any suggestions on an approac

Re: [PERFORM] choosing RAID level for xlogs

2005-08-16 Thread mudfoot
Quoting Anjan Dave <[EMAIL PROTECTED]>: > Hi, > > > > One simple question. For 125 or more checkpoint segments > (checkpoint_timeout is 600 seconds, shared_buffers are at 21760 or > 170MB) on a very busy database, what is more suitable, a separate 6 disk > RAID5 volume, or a RAID10 volume? Dat

Re: [PERFORM] JFS fastest filesystem for PostgreSQL?

2005-07-14 Thread mudfoot
Quoting "Jeffrey W. Baker" <[EMAIL PROTECTED]>: > > Here's the result, in transactions per second. > > ext3 jfs xfs > -- --- > 10 Clients 55 81 68 > 100 Clients 61 100 64 > Was fsync true? And have you tri

Re: [PERFORM] Multiple disks: RAID 5 or PG Cluster

2005-06-17 Thread mudfoot
If you truly do not care about data protection -- either from drive loss or from sudden power failure, or anything else -- and just want to get the fastest possible performance, then do RAID 0 (striping). It may be faster to do that with software RAID on the host than with a special RAID controlle

Re: [PERFORM] Adaptec/LSI/?? RAID (what about JBOD?)

2005-06-02 Thread mudfoot
Thanks, Andrew. I expect to choose between HBAs with no RAID functionality or with the option to completely bypass RAID functionality--meaning that I'll hopefully avoid the situation that you've described. I'm mostly curious as to whether the driver problems described for U320 Adaptec RAID contro

Re: [PERFORM] Adaptec/LSI/?? RAID (what about JBOD?)

2005-06-02 Thread mudfoot
I have a similar question about what to choose (either LSI or Adaptec U320), but plan to use them just for JBOD drivers. I expect to be using either net or freebsd. The system CPU will be Opteron. My impression is that both the ahd and mpt drivers (for U320 Adaptec and LSI, respectively) are qui

Re: [PERFORM] PostgreSQL vs. Oracle vs. Microsoft

2005-01-09 Thread mudfoot
Quoting Randolf Richardson <[EMAIL PROTECTED]>: > I'm looking for recent performance statistics on PostgreSQL vs. Oracle > > vs. Microsoft SQL Server. Recently someone has been trying to convince my I don't know anything about your customer's requirements other than that they have a DB c

Re: [PERFORM] Tryint to match Solaris-Oracle performance with directio?

2004-09-17 Thread mudfoot
I fully agree with Gaetano about testing sync methods. From testing I've done on two different Solaris 8 boxes, the O_DSYNC option on Solaris 8 beats fsync and fdatasync easily. Test it yourself though. There's probably some opportuntiy there for better performance for you. > > BTW this is Post

Re: [PERFORM] Article about PostgreSQL and RAID in Brazil

2004-09-16 Thread mudfoot
Quoting Josh Berkus <[EMAIL PROTECTED]>: > The first and most important step for RAID performance with PostgreSQL is to > > get a card with onboard battery back-up and enable the write cache for the > card. You do not want to enable the write cache *without* battery back-up > I'm curious abo

Re: [PERFORM] Determine optimal fdatasync/fsync, O_SYNC/O_DSYNC options

2004-09-13 Thread mudfoot
Quoting Bruce Momjian <[EMAIL PROTECTED]>: > > Have you seen /src/tools/fsync? > I have now. Thanks. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings

[PERFORM] Determine optimal fdatasync/fsync, O_SYNC/O_DSYNC options

2004-09-12 Thread mudfoot
Hi, I'd like to help with the topic in the Subject: line. It seems to be a TODO item. I've reviewed some threads discussing the matter, so I hope I've acquired enough history concerning it. I've taken an initial swipe at figuring out how to optimize sync'ing methods. It's based larg