Re: [PERFORM] XFS filessystem for Datawarehousing -2
I agree that OCFS 2.0 is NOT a general purpose PG (or any other) solution. My recollection is that OCFS gave about 15% performance improvements (same as setting some aggressive switches on ext3). I assume OCFS has excellent crash safety with its default settings but we did not test this as of yet. OCFS now ships as one of the optional FS's that ship with Suse. That takes care of some of the FUD created by Oracle's disclaimer below. OCFS 2 is much more POSIX compliant than OCFS 1. The BenchmarkSQL, DBT2, Regression tests we ran on OCFS 2 all worked well. The lack of full Posix compliance did cause some problems for configuring PITR. --Denis http://www.enterprisedb.comOn 8/3/06, Chris Browne [EMAIL PROTECTED] wrote:Of course, with a big warning sticker of what is required for Oracle to work properly is implemented, anything more is not a guarantee onit, who's going to trust it?--
Re: [PERFORM] XFS filessystem for Datawarehousing -2
Title: Nachricht Hi Dennis, I am just cusrios to try PGwith different block sizes ;) I don't knowhow much performancethe bigger block size will bring (I mean 32k or 64k , for example, for DWH applikations). I am surprised tohear that OCFS2.0 (or any her FS usind direct I/O) performs well with PG.A month ago I haveperformed asimple test with VeritasFS, with and than without cache (e.g. direct I/O).I have started1 , then 2,, then3, then 4 parallel INSERT processes. Veritas FS WITH FS cacheoutperformed the direct I/O version by factor 2-2.5! I haven't tested woth OCFS2.0 though. I am not sure that OCFS2.0 is the good choicefor PG data and index filesystems. For WAL - perhaps. Best Regards. Milen -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Denis LussierSent: Thursday, August 03, 2006 7:36 AMTo: Luke LonerganCc: Milen Kulev; pgsql-performance@postgresql.orgSubject: Re: [PERFORM] XFS filessystem for Datawarehousing -2I was kinda thinking that making the Block Size configurable at InitDB time would be a nice simple enhancement for PG 8.3. My own personal rule of thumb for sizing is 8k for OLTP, 16k for mixed use, 32k for DWH. I have no personal experience with XFS, but, I've seen numerous internal edb-postgres test results that show that of all file systems... OCFS 2.0 seems to be quite good for PG update intensive apps (especially on 64 bit machines). On 8/1/06, Luke Lonergan [EMAIL PROTECTED] wrote: Milen,On 8/1/06 3:19 PM, "Milen Kulev" [EMAIL PROTECTED] wrote: Sorry, forgot to ask: What is the recommended/bestPG block size for DWHdatabase?16k, 32k, 64k ? What hsould be the relationbetween XFS/RAID stripe size and PG block size ?We have found that the page size in PG starts to matter only at very highdisk performance levels around 1000MB/s.Other posters have talked about maintenance tasks improving in performance, but I haven't seen it.- Luke---(end of broadcast)---TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PERFORM] XFS filessystem for Datawarehousing -2
[EMAIL PROTECTED] (Denis Lussier) writes: I have no personal experience with XFS, but, I've seen numerous internal edb-postgres test results that show that of all file systems... OCFS 2.0 seems to be quite good for PG update intensive apps (especially on 64 bit machines). I have been curious about OCFS for some time; it sounded like a case where there could possibly be some useful semantic changes to filesystem functionality, notably that: - atime is pretty irrelevant; - it might try to work with pretty fixed block sizes (8K, perhaps?) rather than try to be efficient at handling tiny files It sounds like it ought to be able to be a good fit. Of course, with a big warning sticker of what is required for Oracle to work properly is implemented, anything more is not a guarantee on it, who's going to trust it? -- select 'cbbrowne' || '@' || 'cbbrowne.com'; http://www.ntlug.org/~cbbrowne/oses.html There isn't any reason why Linux can't be implemented as an enterprise computing solution. Find out what you've been missing while you've been rebooting Windows NT. - Infoworld ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PERFORM] XFS filessystem for Datawarehousing -2
I was kinda thinking that making the Block Size configurable at InitDB time would be a nice simple enhancement for PG 8.3. My own personal rule of thumb for sizing is 8k for OLTP, 16k for mixed use, 32k for DWH. I have no personal experience with XFS, but, I've seen numerous internal edb-postgres test results that show that of all file systems... OCFS 2.0 seems to be quite good for PG update intensive apps (especially on 64 bit machines). On 8/1/06, Luke Lonergan [EMAIL PROTECTED] wrote: Milen,On 8/1/06 3:19 PM, Milen Kulev [EMAIL PROTECTED] wrote: Sorry, forgot to ask: What is the recommended/bestPG block size for DWHdatabase?16k, 32k, 64k ? What hsould be the relationbetween XFS/RAID stripe size and PG block size ?We have found that the page size in PG starts to matter only at very highdisk performance levels around 1000MB/s.Other posters have talked about maintenance tasks improving in performance, but I haven't seen it.- Luke---(end of broadcast)---TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PERFORM] XFS filessystem for Datawarehousing -2
Milen, On 8/1/06 3:19 PM, Milen Kulev [EMAIL PROTECTED] wrote: Sorry, forgot to ask: What is the recommended/best PG block size for DWH database? 16k, 32k, 64k ? What hsould be the relation between XFS/RAID stripe size and PG block size ? We have found that the page size in PG starts to matter only at very high disk performance levels around 1000MB/s. Other posters have talked about maintenance tasks improving in performance, but I haven't seen it. - Luke ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
