In article <B9A2DDA03044D311BBD40008C75D69680B3719E4@dewdfx24>, [EMAIL PROTECTED] says... > Hi, > since SAPDB does not use any feature of a filesystem for its volumes(alias >devspaces) > any kind of filesystem overhead including a buffer cache is just an overhead. SAPDB >opens > using O_SYNC, but O_DIRECT is not yet used. All Read/Write activity use Systempages > which are aligned to 4KByte. The LINUX > raw devices which are preferred are those 'unbuffered' /dev/raw/rawX. > CU > jrg
just tried using /dev/mdx (Linux SW RAID device) using RAID5, seems to be working. What should I expect in the therms of performance, compared with cooked FS? Any optimisation/configuration tips for RAID- strip sizes and similar? (Yes I know hardware RAID is supposed to be faster, but this is no longer true - in most cases. Try >1 CPU over 2MHz plus LVD 160 controller, if you have more then 4 disks, spread over 2 SCSI busses. Now measure, and compare with HW controllers. Just don't compare it with controllers costing more and with more RAM then the whole server box, please - "let's be reasonable" (TM & famous last words).) Hmmmm, just tried taking one disk down - all fine, CPU at 34% when doing full table select joining on fields without index... Reinserted disk, same select on top of disk rebuilding had CPU at 13%. Rebuild of 9GM partition completed in 22 minutes, with database constantly doing full table selects with hash joins... Looks good! -- Yours, Andrej Falout, http://www.falout.com/disclaimer.html Visit the OpenSource alternative, Aubit 4gl: http://aubit4gl.sourceforge.net PLEASE NOTE: All HTML email sent to me WILL BE DELETED AUTOMATICALLY WITHOUT READING. _______________________________________________ sapdb.general mailing list [EMAIL PROTECTED] http://listserv.sap.com/mailman/listinfo/sapdb.general
