From: Martin Cordova (martin.cordovagmail.com)
Date: Tue Oct 24 2006 - 22:01:54 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

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 <henrikhempelmann.com> 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/maxdb?unsub=martin.cordovagmail.com
>
>

--
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

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]