- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
VK приобрела 70% в структуре компании-разработчика red_mad_robot
Которая участвовала в создании RuStore
Оксана Мамчуева
Все что нужно знать о DDоS-атаках грамотному менеджеру
И как реагировать на "пожар", когда неизвестно, где хранятся "огнетушители
Антон Никонов
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Здравствуйте.
Борюсь с некоторой проблемой уже несколько недель и все никак не пойму в чём проблема. Прошу помощи у Вас, уважаемые участники сообщества!
Что имеется: три сервера CentOS 6.6 и базами данных MySQL 5.5 (без патчей). Работает это все с Nginx / Apache и PHP-FPM.
Проблема в следующем: на одном сервере MySQL работает неадекватно, конкретно InnoDB. Запросы просто зависают без видимых причин в статусе "query end" примерно раз 1-3 дня, так как сервер настроен корректно по использованию памяти, то MySQL просто использует все доступные соединения (300) и рвет новые подключения. Так все держится до перезагрузки MySQL, либо очистки выделенного InoDB Buffer Pool.
Исходя из SHOW ENGINE INNODB STATUS видно, что MySQL ловит DEADLOCK'и. Запросы произвольные, не всегда одни и те же.
Я изучил этот вопрос, на сколько понял - они должны быть безобидны и не приводить к подобному поведению MySQL.
Далее, если посмотреть лог MySQL, там можно найти следующее в момент проблем (смотрите вложение).
Нашел рекомендации добавить параметр innodb_adaptive_hash_index = 0, но это не помогло.
Есть еще один и достаточно интересный момент, добавив параметр table_open_cache в любом нестандартном размере (более 400), в MySQL начинает утекать память. То есть, если при обычном использовании MySQL кушает 10 гб памяти (допустим), то при установке table_open_cache в 800, MySQL откусывает всю доступную память сервера, может уйти в SWAP и его убьет OOM Killer, подчеркну, что такое поведение только на проблемном сервере, на двух других проблем нет.
Ниже файл конфигурации /etc/my.cnf
В /var/log/messages ничего нет, только если OOM killer убивает MySQL :) Но это не происходит...
Для наглядности график соединений и памяти.
Евгений Русаченко, вам поручили решить эту проблему или работали с проектом изначально? Если имеются предпосылки (изменение конфига, обновление ПО, скриптов, рост нагрузки и т.д.), это сильно облегчило бы задачу. Я больше всего склоняюсь к конфигу.
запросы на вставку коммитятся ? commit используете часто?
ри сервера CentOS 6.6 и базами данных MySQL 5.5 (без патчей)
Начнем с того, что в centos 6.6 должен быть mysql-server-5.1.73
Вы откуда ставили mysql и как давно обновляли ?
Обычно подвисание на этапе query_end связано с очисткой кеша запросов или фиксацией транзакций.
Так что можно попробовать снизить query_cache_size = 128M .
И настройка skip-innodb-doublewrite - крайне странная. Ее никто не использует, потому что она фактически отключает нормальную фиксацию транзакций. Не исключено, что с этим и связан какой-то редкий баг.
Если хотите фиксацию хоть как-то ускорить, лучше включите innodb-doublewrite, а innodb_flush_log_at_trx_commit = 0. По крайней мере, так будет более традиционно.
Евгений Русаченко, вам поручили решить эту проблему или работали с проектом изначально? Если имеются предпосылки (изменение конфига, обновление ПО, скриптов, рост нагрузки и т.д.), это сильно облегчило бы задачу. Я больше всего склоняюсь к конфигу.
По сути это сервер с огромным числом сайтов на Joomla, Drupal, WordPress и возможно чем-то самописным. MySQL строго настроен на использование 1/3 памяти сервера за пределы которого и не вылезает даже при 300 активных соединениях. По практике, если бы проблема была в запросах, то они просто бы тупили, но 1 запрос никак не мог бы вызывать очередь из 300 соединений и в какой-то степени положить MySQL.
---------- Добавлено 04.03.2015 в 16:09 ----------
запросы на вставку коммитятся ? commit используете часто?
Понятия не имею, за скрипты которые используются на сервере ответственности не несу и лезть мне в них нельзя. Моя задача только в том, чтобы сервер хорошо работал и эти скрипты хорошо работали.
Если где-то в статистике можно посмотреть число commit's, то ткните пальцем, посмотрю :)
---------- Добавлено 04.03.2015 в 16:20 ----------
Начнем с того, что в centos 6.6 должен быть mysql-server-5.1.73
Вы откуда ставили mysql и как давно обновляли ?
Обычно подвисание на этапе query_end связано с очисткой кеша запросов или фиксацией транзакций.
Так что можно попробовать снизить query_cache_size = 128M .
И настройка skip-innodb-doublewrite - крайне странная. Ее никто не использует, потому что она фактически отключает нормальную фиксацию транзакций. Не исключено, что с этим и связан какой-то редкий баг.
Если хотите фиксацию хоть как-то ускорить, лучше включите innodb-doublewrite, а innodb_flush_log_at_trx_commit = 0. По крайней мере, так будет более традиционно.
MySQL собрался из исходников с официального сайта. MySQL 5.1 уже как-то слишком устарел на мой взгляд и 5.5 отлично работал и работает на CentOS 6.6, только не на этом сервере...
Подвисают именно InnoDB запросы, query_cache_size для них тоже используется? Всегда считал, что он только для MyISAM таблиц. Если да, то тогда попробую вовсе отключить, а не снижать. Если поможет - с меня какой-нибудь презент.
По skip-innodb-doublewrite ситуация такова. tmp папка вынесена в оперативную память и там O_DIRECT не работает корректно, лог заваливается ошибками:
141225 2:12:31 InnoDB: Failed to set O_DIRECT on file /dev/shm/#sqlad50b_9d07_d.ibd: CREATE: Invalid argument, continuing anyway
В качестве аналога для O_DIRECT и включили skip-innodb-doublewrite.
Пробовали и без него тоже, это было добавлено недавно. Изначально, когда проблем еще не было, конфигурационный файл был еще куда проще:
Данный типовой конфиг стоит на десятках серверов и проблем нет. А на этом вот закрылась проблема. С этим конфигурационным файлом и опцией table_open_cache тоже происходит утечка памяти, с этого так скажем всё и начиналось. Опцию убрали, стали запросы вешаться в query end.
Лимит открытых файлов достаточно высок, в этом не может быть проблемы:
fs.file-max = 3275006
MySQL 5.1 уже как-то слишком устарел на мой взгляд
Ну так в Centos вообще почти все устарело в момент выхода. Это такая идеология дистрибутива. Зачем тогда ставить, если все равно прыгаете вперед ?
Подвисают именно InnoDB запросы, query_cache_size для них тоже используется? Всегда считал, что он только для MyISAM таблиц. Если да, то тогда попробую вовсе отключить, а не снижать. Если поможет - с меня какой-нибудь презент.
Кеш запросов используется независимо от движка хранения. Шансов, на мой взгляд, немного. 128 мб это не такой уж большой размер кеша.
И все же, может убрать ?
вы и так от innodb_flush_log_at_trx_commit = 0 выиграете сравнительно неплохо. Некоторый перерасход памяти не так важен.
Ну так в Centos вообще почти все устарело в момент выхода. Это такая идеология дистрибутива. Зачем тогда ставить, если все равно прыгаете вперед ?
Кеш запросов используется независимо от движка хранения. Шансов, на мой взгляд, немного. 128 мб это не такой уж большой размер кеша.
И все же, может убрать ?
вы и так от innodb_flush_log_at_trx_commit = 0 выиграете сравнительно неплохо. Некоторый перерасход памяти не так важен.
Кроме PHP и MySQL ничем не прыгали, всё остальное стоит из коробки.
Убрать попробовать можно, попытка не пытка. Так как всё что можно было перепробовано уже.
innodb_flush_log_at_trx_commit на мой взгляд не безопасно. Хоть сервер стоит и в ДЦ, но никаких ИБП и RAID контроллера с батарейкой нет, чтобы такое ставить.
Хоть сервер стоит и в ДЦ, но никаких ИБП и RAID контроллера с батарейкой нет, чтобы такое ставить.
для этого должен бакап стоять, а не рейд-контроллер :)
для этого должен бакап стоять, а не рейд-контроллер :)
Сам факт повышенного шанса повреждения базы данных не радует. Поэтому такое точно использовать не буду.
innodb_flush_log_at_trx_commit на мой взгляд не безопасно.
Так вы уже поставили 2 . Уже все. Реальные пацаны в вас пальцем будут тыкать и смеяться.
Innodb не повредится от 0, просто некоторые свежие данные могут потеряться и только лишь в случае внезапной перезагрузки.