|
Задавайте вопросы, мы ответим
Вы не зашли.
Добрый день.
Суть проблемы кратко:
провели тест - вставка 100 строк в пустую таблицу. Время выполнения - 3,5 секунд. Это же много !?!
Условия теста:
- InnoDB
- пустая таблица с двумя полями: id int, text varchar(45)
- дефолтовые настройки MySQL
- сервер полностью без нагрузки, база пустая
- каждая вставка в новой транзакции
- запись транзакций на диск сразу после коммита (innodb_flush_log_at_trx_commit=1)
Проверяли на трех машинах (Debian, Ubuntu / MySQL 5.1.67 - 5.5.31) - резултаты плохие: от 1,7 до 3,5 сек.
Проверил на другом сервере (FreeBSD, MySQL 5.5.29) - результат: 0,06 сек.
Разница доходит до 50 раз.
Железо на серверах разное, но не отличается так принципиально.
Сравнивал конфиги, пытался играть с некоторыми значениями - результат не изменился.
Понимаю, что экстрасенсов тут нет - но всё таки, есть какие-то предположения?
Кто может проверить этот небольшой тест у себя на сервере?
Я не могу понять: или 3 системы - тормозы, или 1 система - врёт.
Неактивен
Это из-за настройки innodb_flush_log_at_trx_commit=1. Он при каждом коммите ждет, пока диск физически выполнит запись, а это занимает время (каждый seek по диску - десятки миллисекунд). В случае FreeBSD, вероятно, система все же обманывает и на диск физически не записывает транзакцию.
Неактивен
Это из-за настройки innodb_flush_log_at_trx_commit=1. Он при каждом коммите ждет, пока диск физически выполнит запись, а это занимает время (каждый seek по диску - десятки миллисекунд).
Это я знаю. И намеренно проводил тест с innodb_flush_log_at_trx_commit=1.
В случае FreeBSD, вероятно, система все же обманывает и на диск физически не записывает транзакцию.
Возможно. Я тоже склоняюсь к такой версии. Как это можно проверить? У нас нашлась ещё 1 система (Debian, настройки MySQL стандартные), которая выполняет тест за 0,04 сек.
Неактивен
Есть ли различия в используемой файловой системе? Если ext4, то что будет если ее замаунтить как ext2. Сравните настройки sysctl -a
Неактивен
