Oracle 5.0 Reference Manual page 1305

InnoDB
• Beware also of other big disk-bound operations. Use
table, not
DELETE FROM
• In some versions of GNU/Linux and Unix, flushing files to disk with the Unix
uses by default) and other similar methods is surprisingly slow. If you are dissatisfied with
InnoDB
database write performance, you might try setting the
to O_DSYNC. The
O_DSYNC
not be one of them.
• When using the
InnoDB
it is important to use direct I/O for InnoDB-related files. Failure to do so may cause degradation
of InnoDB's speed and performance on this platform. To use direct I/O for an entire UFS file
system used for storing InnoDB-related files, mount it with the
mount_ufs(1M). (The default on Solaris 10/x86_64 is not to use this option.) Alternatively, as of
MySQL 5.0.42 you can set
affect the entire file system. This causes
setting
innodb_flush_method
files, not the log files.
When using the
InnoDB
value on any release of Solaris 2.6 and up and any platform (sparc/x86/x64/amd64), a significant
performance gain might be achieved by placing
on a separate direct I/O UFS file system using the
earlier (it is necessary to use the mount option rather than setting
if you want direct I/O for the log files). Users of the Veritas file system VxFS should use the
convosync=direct
or direct I/O file systems to verify whether performance is improved on your system.
Other MySQL data files, such as those for
system. Executables or libraries must not be placed on a direct I/O file system.
• If the Unix tool or the Windows Task Manager shows that the CPU usage percentage with your
top
workload is less than 70%, your workload is probably disk-bound. Maybe you are making too many
transaction commits, or the buffer pool is too small. Making the buffer pool bigger can help, but do
not set it equal to more than 80% of physical memory.
Logging Tips
• Make your log files big, even as big as the buffer pool. When
must write the modified contents of the buffer pool to disk in a checkpoint. Small log files cause many
unnecessary disk writes. The disadvantage of big log files is that the recovery time is longer.
• Make the log buffer quite large as well (on the order of 8MB).
Bulk Data Loading Tips
• When importing data into InnoDB, make sure that MySQL does not have autocommit mode enabled
because that requires a log flush to disk for every insert. To disable autocommit during your import
operation, surround it with
SET autocommit=0;... SQL import statements ...
COMMIT;
If you use the
mysqldump
table, even without wrapping them with the
InnoDB
• If you have constraints on secondary keys, you can speed up table imports by temporarily
UNIQUE
turning off the uniqueness checks during the import session:
SET unique_checks=0;... SQL import statements ...
SET unique_checks=1;
Performance Tuning and Troubleshooting
tbl_name.
flush method seems to perform slower on most systems, but yours might
storage engine on Solaris 10 for x86_64 architecture (AMD Opteron),
innodb_flush_method = O_DIRECT
InnoDB
[1243] to
O_DIRECT
storage engine with a large
mount option. You are advised to perform tests with and without raw partitions
MyISAM
SET autocommit
option [303], you get dump files that are fast to import into an
--opt
1285
and
DROP TABLE
innodb_flush_method
forcedirectio
[1243]
to call
directio()
causes
InnoDB
innodb_buffer_pool_size
data files and log files on raw devices or
InnoDB
mount option as described
forcedirectio
innodb_flush_method
tables, should not be placed on a direct I/O file
InnoDB
and statements:
COMMIT
SET autocommit
to empty a
CREATE TABLE
call (which
fsync()
[1243] parameter
option; see
if you do not want to
instead of fcntl(). However,
to use direct I/O only for data
[1238]
[1243]
has written the log files full, it
and statements.
COMMIT