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

•Adjust the flush method 

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 . 

•Configure an fsync threshold 

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. 

•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” . 

•Use direct I/O on Solaris 10 for x86_64 architecture 

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

•Use raw storage for data and log files with Solaris 2.6 or later 

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. 

•Use additional storage devices 

