Heikki, thank you for the answer. So on the systems other than Linux or Solaris the best flush method should be fdatasync, is it correct? In this case, if I don't specify innodb_flush_method option, fdatasync will not be used - it'll be fsync be default instead? My system is FreeBSD, so which value for innodb_flush_method can be optimal?
Thanks ---- Alexander Varshavchick, Metrocom Joint Stock Company Phone: (812)118-3322, 118-3115(fax) On Fri, 6 Sep 2002, Heikki Tuuri wrote: > Date: Fri, 6 Sep 2002 10:27:03 +0300 > From: Heikki Tuuri <[EMAIL PROTECTED]> > To: Varshavchick Alexander <[EMAIL PROTECTED]> > Cc: [EMAIL PROTECTED] > Subject: Re: Performance Problems with InnoDB Row Level Locking... > > Alexander, > > ----- Original Message ----- > From: "Varshavchick Alexander" <[EMAIL PROTECTED]> > To: "'Heikki Tuuri'" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Friday, September 06, 2002 10:08 AM > Subject: RE: Performance Problems with InnoDB Row Level Locking... > > > > Hi Heikki, > > > > one more question please about innodb_flush_log_at_trx_commit: if there > > was some way of increasing the delay between log flushes more than 1 sec, > > can you estimate will it bring any real effect in performance? I know > > it'll raise the risk of losing some last transactions if something > > crashes, but we can go for it gaining the speed. How can it be done if > > it's worth doing? > > it should not be worth doing. > > A disk can do some 70 random writes per second, and the log flush (calling > fsync on the log file) typically uses 2 disk writes: > > (1) writing the end of the log to the log file on disk, and > (2) updating the file access timestamps in the 'inode' of the file, if we > are using a Unix file system. > > Thus the performance benefit of less than 1 log flush per second is small. > On the other hand, we might add an option which allows flushing the log 1 - > 50 times per second. > > Note that the file flush method fdatasync is supposed to eliminate the write > (2) above. Unfortunately there was evidence fadatasync caused file > corruption in Linux and Solaris, and it is currently mapped to the ordinary > fsync. > > > Thanks > > > > sql, query > > ---- > > Alexander Varshavchick, Metrocom Joint Stock Company > > Phone: (812)118-3322, 118-3115(fax) > > Best regards, > > Heikki Tuuri > Innobase Oy > --- > InnoDB - transactions, hot backup, and foreign key support for MySQL > See http://www.innodb.com, download MySQL-Max from http://www.mysql.com > > > > > --------------------------------------------------------------------- > Before posting, please check: > http://www.mysql.com/manual.php (the manual) > http://lists.mysql.com/ (the list archive) > > To request this thread, e-mail <[EMAIL PROTECTED]> > To unsubscribe, e-mail <[EMAIL PROTECTED]> > Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php > --------------------------------------------------------------------- Before posting, please check: http://www.mysql.com/manual.php (the manual) http://lists.mysql.com/ (the list archive) To request this thread, e-mail <[EMAIL PROTECTED]> To unsubscribe, e-mail <[EMAIL PROTECTED]> Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
