Optimizing InnoDB Disk I/O innodb_buffer_pool_size  is configured to 50 to 75 percent of system memory. For more information see, Section 8.12.3.1, “How MySQL Uses Memory” . In some versions of GNU/Linux and Unix, flushing files to disk with the Unix  fsync()  call (which InnoDB  uses by default) and similar methods is surprisingly slow. If database write performance is an issue, conduct benchmarks with the  innodb_flush_method  parameter set to  O_DSYNC . By default, when  InnoDB  creates a new data file, such as a new log file or tablespace file, the file is fully written to the operating system cache before it is flushed to disk, which can cause a large amount of disk write activity to occur at once. To force smaller, periodic flushes of data from the operating system cache, you can use the  innodb_fsync_threshold  variable to define a threshold value, in bytes. When the byte threshold is reached, the contents of the operating system cache are flushed to disk. The default value of 0 forces the default behavior, which is to flush data to disk only after a file is fully written to the cache. Specifying a threshold to force smaller, periodic flushes may be beneficial in cases where multiple MySQL instances use the same storage devices. For example, creating a new MySQL instance and its associated data files could cause large surges of disk write activity, impeding the performance of other MySQL instances that use the same storage devices. Configuring a threshold helps avoid such surges in write activity. When using the  InnoDB  storage engine on Solaris 10 for x86_64 architecture (AMD Opteron), use direct I/O for  InnoDB -related files to avoid degradation of  InnoDB  performance. To use direct I/O for an entire UFS file system used for storing  InnoDB -related files, mount it with the  forcedirectio  option; see mount_ufs(1M) . (The default on Solaris 10/x86_64 is  not  to use this option.) To apply direct I/O only to InnoDB  file operations rather than the whole file system, set  innodb_flush_method = O_DIRECT . With this setting,  InnoDB  calls  directio()  instead of  fcntl()  for I/O to data files (not for I/O to log files). When using the  InnoDB  storage engine with a large  innodb_buffer_pool_size  value on any release of Solaris 2.6 and up and any platform (sparc/x86/x64/amd64), conduct benchmarks with InnoDB  data files and log files on raw devices or on a separate direct I/O UFS file system, using the forcedirectio  mount option as described previously. (It is necessary to use the mount option rather than setting  innodb_flush_method  if you want direct I/O for the log files.) Users of the Veritas file system VxFS should use the  convosync=direct  mount option. Do not place other MySQL data files, such as those for  MyISAM  tables, on a direct I/O file system. Executables or libraries  must not  be placed on a direct I/O file system. 1752 •Use additional storage devices •Use raw storage for data and log files with Solaris 2.6 or later •Use direct I/O on Solaris 10 for x86_64 architecture •Use a noop or deadline I/O scheduler with native AIO on Linux InnoDB  uses the asynchronous I/O subsystem (native AIO) on Linux to perform read-ahead and write requests for data file pages. This behavior is controlled by the  innodb_use_native_aio  configuration option, which is enabled by default. With native AIO, the type of I/O scheduler has greater influence on I/ O performance. Generally, noop and deadline I/O schedulers are recommended. Conduct benchmarks to determine which I/O scheduler provides the best results for your workload and environment. For more information, see Section 15.8.6, “Using Asynchronous I/O on Linux” . •Configure an fsync threshold •Adjust the flush method