На VMBITRIX 4.3.4, где много сайтов и обычные жесткие диски (не SSD), часто притормаживают страницы.
Причем 95-99% дает первый запрос UPDATE в коде страницы.
Это может быть запрос UPDATE к веб-аналитике, или обновление текущей даты посещения автора в своем блоге, или еще какой-нибудь запрос на запись.
Техподдержка не знает что с этим делать. И повторить медленный UPDATE мне крайне трудно. Техподдержка не видит проблемы.
Сервер нормальный:
Из замечаний на странице проверки настроек БД есть только:
Цитата
Кеш открытых таблиц13.43% Эффективность кеша открытых таблиц (Open_tables / Opened_tables). Если значение эффективности менее 20%, то требуется увеличить значение параметра table_open_cache (текущее значение: 14240). Увеличивайте параметр постепенно чтобы избежать превышения лимитов на количество одновременно открытых файлов в операционной системе.
Выглядит проблема так:
Запрос Update в прологе:
Я мог подумать, что проблемы с соединением. Но первые запросы SELECT нормально отрабатывают.
Сам код запроса элементарный. Даже если поле одно и таблица почти пустая, то UPDATE может отрабатывать несколько секунд. (12 секунд и более, я видел).
При каких условиях бывает такой медленный UPDATE? Какие параметры MySQL влияют на UPDATE? Куда смотреть?
К сожалению, в данном случае я вряд ли смогу помочь, так как тут используется MySQL 5.1 и плагин InnoDB 1.0 — старые версии со своим зоопарком проблем, которые я почти не застал, и которые не актуальны для современных версий MySQL.
Короткий поиск в Интернете предлагает попробовать следующие решения:
1) Отключить Adaptive Hash Indexing, путем добавления следующей строки в my.cnf:
Код
innodb_adaptive_hash_index = 0
2) Отключить кеширование запросов (только если проект не слишком посещаемый):
Код
query_cache_type = 0
3) Увеличить число потоков внутри движка InnoDB:
Код
innodb_thread_concurrency = 16
Гарантий что одно из решений окажется рабочим нет, но попробовать их последовательно все-таки стоит.
Лучшим же выходом, на мой взгляд, будет обновление MySQL с 5.1 до 5.5. Благо, с появления версии 5.5 прошло уже более пяти лет. Практически наверняка это позволит избавиться от проблемы. Кроме того, разумно будет задуматься о переходе на MariaDB или PerconaDB. Последнюю уже давно используем на проектах с миллионной суточной посещаемостью и еще ни разу она не подводила.
Про PerconaDB и MariaDB давно спрашивал, а почему собственно в BitrixEnv используют ванильный MySQL а не более продвинутые форки, так толком никто и не ответил
Сорри за некропостинг, но 4 дня потратил на эту проблему и нашел солюшн, который возможно сэкономит вам время. Значит, один в один как у ТС ситуация - нерегулярные долгие апдейты, до 21 секунды на очень мощной машине. Под нагрузкой тормозит чаще, без нагрузки - реже, но все те же значения от 2 до 16 секунд.
Копался в my.cnf - не помогло. Обновлял все что можно - не помогло Создал индексы для всех полей всех таблиц - не помогло.
Пошёл разбираться глубже. Короче, дело было в файловой системе, на которой лежала машина.
В файловых системах BTRFS и ZFS с контролем четности и компрессией не рекомендуется держать виртуалки, базы данных и прочий подобный контент. У меня была BTRFS со всеми этими атрибутами. Только переместил в папку с отключенной компрессией и контролем четности - всё стало работать, скорость выросла примерно в 10 раз, этот синдром исчез.
В файловых системах BTRFS и ZFS с контролем четности и компрессией не рекомендуется держать виртуалки, базы данных и прочий подобный контент. У меня была BTRFS со всеми этими атрибутами. Только переместил в папку с отключенной компрессией и контролем четности - всё стало работать, скорость выросла примерно в 10 раз, этот синдром исчез.
Большое спасибо. Мы уже давно поменяли сервер, и не могу сказать какая файловая система у нас была. Но кому-нибудь поможет ваш совет.