Рекомендации по увеличению производительности
1. Если top операционной системы Unix или Task Manager Windows показывают процент рабочей нагрузки процессора меньше 70%, это значит, что объем рабочей нагрузки в основном сводится к обращениям к диску. Возможно, слишком часто производится фиксация транзакций, или буферный пул слишком мал. Здесь может помочь увеличение размера буферного пула, но не следует устанавливать его значение большим, чем 80% физической памяти.
2. Несколько изменений следует вносить за одну транзакцию. InnoDB должен сбрасывать журнал на диск после каждой фиксации транзакции, если эта транзакция вносит изменения в базу данных. Поскольку скорость вращения диска обычно не превышает 167 оборотов в секунду, то количество фиксаций ограничено 167 фиксациями в секунду, если, конечно, диск не обманывает операционную систему.
3. Если вы можете позволить себе потерять последние зафиксированные транзакции, установите параметр innodb_flush_log_at_trx_commit в файле 'my.cnf' в нулевое значение. Так или иначе InnoDB пытается сохранить журнал
ежесекундно, и в этом случае сохранение не гарантируется.
4. Увеличьте размеры файлов журналов, доведите их даже до размера буферного пула. Когда InnoDB заполняет файлы журналов, он должен сохранить измененное содержимое буферного пула на диск в виде моментального снимка базы. Маленькие журналы будут вызывать множество ненужных записей на диск. Есть и оборотная сторона медали - если файлы журналов большие, то время восстановления транзакций (в случае сбоя) будет больше.
5. Кроме того, буфер журнала должен быть достаточно большим, например 8 Мб.
6. (Актуально для версии 3.23.39 и выше.) В некоторых версиях операционных систем Linux и Unix запись файлов на диск при помощи команды Unix fdatasync и других подобных методов производится на удивление медленно. Принятый по умолчанию метод InnoDB использует функцию fdatasync. Если скорость записи базы данных вас не устраивает, можно попробовать для параметра innodb_flush_method в файле 'my.cnf' задать значение O_DSYNC, хотя на многих системах O_DSYNC обычно работает медленнее.
7. При импортировании данных в InnoDB убедитесь что в MySQL не установлено значение autocommit=1. Если оно установлено, то каждая вставка требует сохранения журналов на диске. Поместите прямо в начале вашего файла с данными:
SET AUTOCOMMIT=0;
и в конце
COMMIT;
Если используется параметр mysqldump --opt, то вы получите файлы, которые достаточно быстро импортируются в InnoDB, даже если их не окружить
вышеуказанными командами SET AUTOCOMMIT=0; ... COMMIT;.
8. Осторожно относитесь к значительным откатам больших вставок InnoDB использует буфер вставок для того, чтобы меньше "дергать" диск на вставках, однако для соответствующего отката транзакции такой механизм не предусмотрен.. Ограниченный производительностью диска откат может занять в 30 раз больше времени, чем вставка. Удаление процесса базы данных не поможет, так как откат начнется снова после запуска базы данных. Единственный способ избежать такого отката - это увеличить буферный пул настолько, что откат станет зависеть только от производительности
процессора, перестанет ''равняться'' по диску и отработается быстро. Есть еще один способ - это удаление базы данных InnoDB целиком.
9. Следует также осторожно относиться к операциям со значительными объемами данных, зависящим от производительности диска. Чтобы очистить таблицу, используйте команды DROP TABLE или TRUNCATE (начиная с версии MySQL-4.0 и выше), а не DELETE FROM yourtable.
10. Используйте множественные вставки для уменьшения нагрузки на коммуникации между клиентом и сервером, если вам нужно вставить множество записей:
INSERT INTO yourtable VALUES (1, 2), (5, 5);
Эта рекомендация подходит для вставок в таблицы любого типа, а не только InnoDB.
InnoDB Monitor
Начиная с версии 3.23.41 в состав InnoDB входит InnoDB Monitor, который выводит информацию по внутреннему состоянию InnoDB. Когда InnoDB Monitor включен, сервер MySQL mysqld выводит стандартный набор данных (обратите внимание: клиент MySQL ничего не выводит) примерно каждые 15 секунд. Эти данные могут пригодиться при настройке производительности. В операционной системе Windows необходимо запустить mysqld-max из командной строки MS-DOS с параметрами --standalone --console, чтобы направить выводимые данные в окно MS-DOS.
Существует отдельная функция innodb_lock_monitor, которая выводит такую же информацию как innodb_monitor, а также данные по блокировкам, установленным каждой транзакцией.
Выводящаяся информация включает следующие данные:
по блокировкам, ожидающим транзакций;
по семафорам, ожидающим потоков;
по файлам, ожидающим ответа на запрос ввода/вывода;
статистику буферного пула;
по активности буферов удаления и вставок в основном потоке InnoDB.
InnoDB Monitor можно запустить при помощи следующей команды SQL:
CREATE TABLE innodb_monitor(a int) type = innodb;
а остановить его при помощи:
DROP TABLE innodb_monitor;
Вызов команды CREATE TABLE является только способом передачи команды в InnoDB через программу синтаксического анализа SQL. Факт создания таблицы не играет никакой роли для InnoDB Monitor. Если вы останавливаете сервер, когда монитор работает, и хотите запустить монитор заново, следует уничтожить таблицу прежде, чем снова вызвать CREATE TABLE для запуска монитора. Синтаксис может измениться в будущих версиях.
Пример информации, выводимой InnoDB Monitor:
================================
010809 18:45:06 INNODB MONITOR OUTPUT
================================
--------------------------
LOCKS HELD BY TRANSACTIONS
--------------------------
LOCK INFO:
Number of locks in the record hash table 1294
LOCKS FOR TRANSACTION ID 0 579342744
TABLE LOCK table test/mytable trx id 0 582333343 lock_mode IX
RECORD LOCKS space id 0 page no 12758 n bits 104 table test/mytable index
PRIMARY trx id 0 582333343 lock_mode X
Record lock, heap no 2 PHYSICAL RECORD: n_fields 74; 1-byte offs FALSE;
info bits 0
0: len 4; hex 0001a801; asc ;; 1: len 6; hex 000022b5b39f; asc ";;
2: len 7; hex 000002001e03ec; asc ;; 3: len 4; hex 00000001;
...
-----------------------------------------------
CURRENT SEMAPHORES RESERVED AND SEMAPHORE WAITS
-----------------------------------------------
SYNC INFO:
Sorry, cannot give mutex list info in non-debug version!
Sorry, cannot give rw-lock list info in non-debug version!
-----------------------------------------------------
SYNC ARRAY INFO: reservation count 6041054, signal count 2913432
4a239430 waited for by thread 49627477 op. S-LOCK file NOT KNOWN line 0
Mut ex 0 sp 5530989 r 62038708 sys 2155035;
rws 0 8257574 8025336; rwx 0 1121090 1848344
-----------------------------------------------------
CURRENT PENDING FILE I/O'S
--------------------------
Pending normal aio reads:
Reserved slot, messages 40157658 4a4a40b8
Reserved slot, messages 40157658 4a477e28
...
Reserved slot, messages 40157658 4a4424a8
Reserved slot, messages 40157658 4a39ea38
Total of 36 reserved aio slots
Pending aio writes:
Total of 0 reserved aio slots
Pending insert buffer aio reads:
Total of 0 reserved aio slots
Pending log writes or reads:
Reserved slot, messages 40158c98 40157f98
Total of 1 reserved aio slots
Pending synchronous reads or writes:
Total of 0 reserved aio slots
-----------
BUFFER POOL
-----------
LRU list length 8034
Free list length 0
Flush list length 999
Buffer pool size in pages 8192
Pending reads 39
Pending writes: LRU 0, flush list 0, single page 0
Pages read 31383918, created 51310, written 2985115
----------------------------
END OF INNODB MONITOR OUTPUT
============================
010809 18:45:22 InnoDB starts purge
010809 18:45:22 InnoDB purged 0 pages
Некоторые примечания по выводу:
Если раздел LOCKS HELD BY TRANSACTIONS содержит информацию по ожидаемым блокировкам, то у вашей программы может быть конфликт
блокировок. Выводимая информация также может оказать помощь в отслеживании причин возникновения взаимных блокировок.
Если InnoDB скомпилировать при помощи UNIV_SYNC_DEBUG в 'univ.i', то раздел SYNC INFO будет содержать информацию по зарезервированным семафорам.
Раздел SYNC ARRAY INFO содержит информацию по потокам, ожидающим семафора, а также статистические данные по количеству повторных циклов или ожиданий, выполненных потоками для семафоров или блокировок чтения/записи. Большое количество потоков, ожидающих семафоров, может возникнуть в результате частого выполнения операций ввода/вывода диска, оно может быть также обусловлено конфликтами внутри самого InnoDB. Конфликты могут возникать при большом количестве параллельных запросов или в случае проблем операционной системы с планированием потоков.
В разделе CURRENT PENDING FILE I/O'S выводится список файлов, ожидающих ответа на запрос ввода/вывода. Большое количество таких
файлов говорит о том, что рабочая нагрузка ограничена операциями ввода/вывода диска.
Раздел BUFFER POOL содержит статистическую информацию по записываемым и считываемым страницам. По этим данным можно вычислить, сколько запросов ввода/вывода по файлам данных выполняется на данный момент.
1 2 3 4 5 6 7 8 9 10 11
8 8 8
| |
*
Обратная связь