Hello Henrik: Thank you very much for the feedback. Considering my ignorance on the subject, and after reading a little more about the subject of kernel 2.6, Async I/O, O_DIRECT and raw devices, I understand:
* RAW seems to be a little outdated in kernel 2.6 * With a linux kernel 2.6, a combination of Direct I/O (no double buffering) and Async I/O, which seems to be supported by the popular Filesystems in 2.6, it may render comparable performance like when using raw devices, without losing all the facilities provided by filesystems, like easy file copy, backups, etc. Some references about this: https://www.redhat.com/magazine/013nov05/features/oracle/ http://www-128.ibm.com/developerworks/linux/linux390/perf/tuning_rec_database_ioOptions.html http://lse.sourceforge.net/io/aio.html http://www.osdl.org/docs/linux_2_6_datacenter_performance.pdf (pages 13 & 14) * One article in particular said that in their benchmarks there were no substantial differences between ext2 and ext3 when used in Async + O_DIRECT mode for database tasks (DB2), so they preferred Ext3 for its better recovery time in case of failure: http://www-128.ibm.com/developerworks/linux/linux390/perf/tuning_rec_database_filesystem.html As you said, there is no single solution for everyone's needs, but I feel a little bit more informed regarding these topics as to configure my MaxDB instance. As we use to say in my country, I just discovered America in a glass of water... Regards, Martin On 10/24/06, Henrik Hempelmann <[EMAIL PROTECTED]> wrote:
On 24.10.2006, at 20:09, Martin Cordova wrote: > Hello: > > I am reading latest MaxDB online docs, and found this: > > 1) USE_OPEN_DIRECT > > Q: do you recommend this on a Linux w/kernel 2.6? which Filesystems > make sense for this parameter? I/O performance depends on a lot of parameters: controller, caches, workload, filesystem, number and type of disks .... There are configuration which will benefit from a bypassed filesystem buffer cache - others won't :-( Our advice is to run your own application benchmark to tune your local configuration to an optimum. > > 2) "Only for UNIX/Linux: do not use hard disks with a journal file > system for the volumes. Journal file systems perform their own logging > of data changes, which is unnecessary for the database system and > leads to performance reduction." > > Q: I am not familair with raw devices, so I was using XFS, because I > did read it was suitable for large files, like the ones I use with > MaxDB. The paragraph above put me think again... If I am not using Raw > devices, does this mean that I should use Ext2?? what about server > restarts? who will protect the integrity of my log and data files? > journaled filesystems (try to) prevent a loss of files, mixed up permissions and counters after a system crash. As we don't create or resize files after the database setup, the database has no benefit from using a journaled filesystem. > I would appreciate very much your comments on these topics. - keep log and data on seperate disks - use multiple (at least 3) data volumes of the same size. - Increase the CACHE_SIZE within the physical memory size to reduce I/O Henrik -- MaxDB Discussion Mailing List For list archives: http://lists.mysql.com/maxdb To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
-- Dinamica - RADical J2EE framework open source, easy and powerful http://www.martincordova.com -- MaxDB Discussion Mailing List For list archives: http://lists.mysql.com/maxdb To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
