What do you mean by "heavily fragmented fdb files"? Multi-file
databases? Or that the file system was fragmented?

-steve

Paulius Pazera wrote:

> Hey guys,
>
>
> I thought I share my experience. Brief conclusion - avoid ext2/ext3 file
> systems for big databases, for example XFS is significantly better
>
> I was troubleshooting raid array perfomance issues on rhel4, first I was
> blaming kernel, drivers, raid controller, motherboard incompatibility, etc
> and it turned out to be heavily fragmented fdb files on ext3 file system.
> Here are some benchmarks for 13Gb database, classic 1.5.2 on x86_64 rhel4,
> quad opteron system with 16Gb RAM and two channel adaptec raid-5:
>
> - single restore: 58 min on ext3, 40 min on xfs (raw i/o performance of xfs
> is better)
> - four parallel restores: 5 hrs 8 min on ext3, 55 min on xfs (ext3 seems to
> be single-threaded)
> - copying unfragmented file (immediately after single restore): 6-7 min on
> ext3, 3-4 min on xfs (raw i/o)
> - copying heavily fragmented file (after four parallel restores): ~180 min
> (estimated) on ext3 on rhel4u2, 28 min on ext3 fedora4, 8 min 30 sec on xfs
> on rhel4u2 or fedora4 (ext3 doesn't handle fragmented files well)
> - month end processes in real db app (lots of selects, inserts, updates in
> stored procedures): in average xfs 5-10% faster than ext3 (not big deal for
> single user, unfortunately I can not test this in production with real load)
>
>
> HTH,
>
> Paulius
>
>
>
>
>
>
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Visit http://firebird.sourceforge.net and click the Resources item
> on the main (top) menu. Try Knowledgebase and FAQ links !
>
> Also search the knowledgebases at http://www.ibphoenix.com
>
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
>
>