|
Задавайте вопросы, мы ответим
Вы не зашли.
Активно работаем простыми запросами:
UPDATE `some_table` SET `cost`='1.00', `status`='ENROUTE', `sended`='2015-03-30 10:52:47' WHERE `msg_id`='6c06c407-5519-0e2a-5550-4d810c2683f1';
SHOW TABLES FROM `users` LIKE 'some_table2';
Самый злостный нарушитель:
SELECT `id`,`table`,`msg_id` FROM `some_table3` WHERE `action`='delete';
Первые два запроса попадают на "server has gone away" реже, а вот последний - очень часто, возможно даже каждую секунду. Рассмотрим его ситуацию.
Табличка MEMORY, активно заполняется и так же активно чистится. Суть таблички - очередь задач, которые в неё сбрасывают триггеры. Не раз было замечено, что в ней отсутствовали данные очереди, хотя было событие, по которому триггер должен был их туда сбросить.
Структура таблички:
CREATE TABLE IF NOT EXISTS `users` (
`id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
`table` varchar(16) NOT NULL COMMENT 'Таблица пользователя',
`timestamp` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 'Дата и время вставки последней записи',
`action` enum('insert','delete') NOT NULL DEFAULT 'insert',
`msg_id` char(36) NOT NULL DEFAULT ''
) ENGINE=MEMORY DEFAULT CHARSET=utf8 COMMENT='Пользователи шлюза, таблицы которых надо обработать';
ALTER TABLE `users`
ADD PRIMARY KEY (`id`), ADD UNIQUE KEY `row` (`table`,`action`,`msg_id`);
Статистика подключений за почти 5 суток (общее количество, примерно в час, % от общего):
Максимально одновременных 183
Неудачных попыток 11.1 k 95.45 0.84%
Прерваны 22.2 k 191.18 1.68%
Всего 1,320 k 11.36 k 100.00%
С чего начинать? Табличку на диск переносить не хочется из-за большой активности.
ЗЫ MySQL работает в VZ контейнере, общий LA сервера составляет порядка 2.
Неактивен
Что написано в логе (системный и mysqld) относительно причины "gone away"? Может ли быть так, что не хватает памяти и процесс mysqld убивается.
Неактивен
В логах ни слова об этом. В сислоге от мускля совсем никогда ничего, в мускльном логе только мусор от запуска демона. Или речь о логе запросов? Аптайм сервера почти 5 дней, при убивании процесса, на сколько я понимаю, этот счётчик времени тоже сбросился бы.
Выхлоп лога запуска сервера:
2015-Mar-25 14:52:35 :: startup
150325 14:52:35 [Note] Server hostname (bind-address): '0.0.0.0'; port: 3306
150325 14:52:35 [Note] - '0.0.0.0' resolves to '0.0.0.0';
150325 14:52:35 [Note] Server socket created on IP: '0.0.0.0'.
150325 14:52:35 [Note] Plugin 'FEDERATED' is disabled.
150325 14:52:35 InnoDB: The InnoDB memory heap is disabled
150325 14:52:35 InnoDB: Mutexes and rw_locks use GCC atomic builtins
150325 14:52:35 InnoDB: Compressed tables use zlib 1.2.7
150325 14:52:35 InnoDB: Initializing buffer pool, size = 128.0M
150325 14:52:35 InnoDB: Completed initialization of buffer pool
150325 14:52:35 InnoDB: highest supported file format is Barracuda.
150325 14:52:47 InnoDB: Waiting for the background threads to start
150325 14:52:52 InnoDB: 5.5.30 started; log sequence number 80674041251
150325 14:52:53 [Warning] 'user' entry 'root@some.service.ua' ignored in --skip-name-resolve mode.
150325 14:52:53 [Warning] 'user' entry '@some.service.ua' ignored in --skip-name-resolve mode.
150325 14:52:53 [Warning] 'proxies_priv' entry '@ root@some.service.ua' ignored in --skip-name-resolve mode.
150325 14:52:53 [Note] Event Scheduler: Loaded 0 events
150325 14:52:53 [Note] /usr/sbin/mysqld: ready for connections.
Version: '5.5.30-alt3' socket: '/mysql.sock' port: 3306 (ALT Linux)
Неактивен
Это похоже на багу движка MEMORY.
Неактивен
Тоже нет, сделал табличку типом InnoDB, ничего не изменилось. Примечательно то, что выборки из этой таблицы всегда либо с `action`='delete', либо с `action`='insert', при этом я не помню, бывала ли когда-нибудь ошибка при `action`='insert'. Сейчас думаю сменить тип столбца `action` на varchar, может будет какой-то результат.
ЗЫ Запрос SELECT `column_name`, `table_name`,`table_schema` FROM `information_schema`.`key_column_usage`для этой таблицы длился где-то 3-4 минуты со статусом "Opening tables", это вроде не нормально. Текущее состояние "Opened tables" равно 321к, table_open_cache = 400. Увеличивать? На сколько? Могло ли это повлиять на поведение с ошибкой?
Отредактированно Neval (30.03.2015 13:46:18)
Неактивен
Какое значение wait_timeout? Opening tables - это ненормально, увеличьте table_open_cache до такого значения, чтобы Opened tables не росло.
Неактивен
wait_timeout = 60
Увеличил table_open_cache до 10к. А текущие счётчики как-то можно сбросить, чтобы не передёргивать демон?
Неактивен
Я бы еще посмотрел на net_read_timeout / net_write_timeout. По косвенным признакам, база
сильно нагружена (это стоит проверить), скорее всего, по диску. Gone away может быть следст-
вием того, что срабатывают таймауты на получение запроса-ответа.
Неактивен
wait_timeout = 60 значит, что через минуту выполнения запрос будет таким образом отключен
Неактивен
paulus написал:
Я бы еще посмотрел на net_read_timeout / net_write_timeout.
30 / 60
paulus написал:
По косвенным признакам, база
сильно нагружена (это стоит проверить), скорее всего, по диску. Gone away может быть следст-
вием того, что срабатывают таймауты на получение запроса-ответа.
Да, база нагружена, диск работает активно, потому эту табличку вынесли в память. Понаблюдать за работой диска? Недавно кстати меняли материнскую плату, вышел из строя встроенный SATA контроллер дисков, до этого поведение с ошибкой было такое же. Но диск SAS, подключен к отдельному контролллеру, потому проблемы не связываю.
rgbeast написал:
wait_timeout = 60 значит, что через минуту выполнения запрос будет таким образом отключен
Да, но учитывая количество ошибок, этот параметр не актуален. Понаблюдал, на глаз получилось где-то 50-80 отказов в секунду. Наверное надо какой-то слип добавить))
Неактивен
Добавил секундный слип, ошибки уменьшились до, естественно, одной в секунду. Чё-то совсем не понимаю, что происходит 
Ещё и админ обрадовал... оказывается, сей мускль живёт на обычном сата винте :\
Отредактированно Neval (30.03.2015 15:05:36)
Неактивен
Пожалуй, вернусь к теме. На данный момент пытаюсь связать данную ошибку с настройкой таймаутов, но тут обнаружилась другая для меня непонятка. Вот текущие значения переменных таймаутов:
Неактивен
Они должны были бы остановиться по wait_timeout, если были бы неактивны в течение 28800 секунд. Можно предположить, что они так долго не простаивают и регулярно выполняют запросы. wait_timeout применяется к периоду ожидания, а не к полному времени исполнения
Неактивен
А таймаут учитывается ведь на сессию, а не на пользователя? Это подключения одного и того же пользователя, есть и свежие, с небольшим временем слипа.
Если на сессию, то не может ведь быть ситуаций, когда запросы периодически выполняются, а время слипа при этом не сбрасывается 
У самой первой сессии слип, получается, висит уже 21 день, тут уже наверное с любыми настройками должно соединение закрываться)))
Неактивен
Да, точно, должны были закрыться. Непонятно почему не закрылись.
Неактивен
А клиент после подключения не может себе выставить таймаут побольше?
И еще — соединения реально живые? Может, по ним, например, ping бегает?
Неактивен
paulus написал:
А клиент после подключения не может себе выставить таймаут побольше?
Не должен, там права только на чтение одной таблицы и запись в некоторые её поля, и усё. Возможно, конечно же, мы чего-то не знаем)))
Пользователей много, подобная ситуация замечена только с одним. Он периодически подключается заново, может как-то с этим связано?
paulus написал:
И еще — соединения реально живые? Может, по ним, например, ping бегает?
Мммм, впервые слышу про такого зверя в контексте СУБД. Пинг обычный, сетевой?
Неактивен
Можно посмотреть на netstat его соединений? Очень хочется понять, что думает сетевой стек про эти соединения, и бегают ли по ним пакеты в принципе.
https://dev.mysql.com/doc/refman/5.6/en/mysql-ping.html — вот этот. Тот, который внутри протокола.
Просто эта штука выглядит сильно как бага, но, чтобы признать багой, надо исключить «плохого клиента», который написал собственный коннектор, который говорит "SET wait_timeout=1000000" после старта ;-)
Неактивен
Neval написал:
У самой первой сессии слип, получается, висит уже 21 день
А на клиенте случайно не используется ли persistent connection?
Неактивен
LazY написал:
А на клиенте случайно не используется ли persistent connection?
Хм, хорошее предположение. Не могу знать, можно попробовать уточнить, для "наверняка". Если да, то с этим уже ничего не поделать? Может, где-то в правах оно настраивается?
ЗЫ А вообще, все клиенты стучатся из внешнего мира. Для них возможно постоянное соединение?
Неактивен
paulus написал:
https://dev.mysql.com/doc/refman/5.6/en/mysql-ping.html — вот этот. Тот, который внутри протокола.
Почитал, почти ничего не понял))) Понял только одно - это надо дёргать на клиенте, который висит в слипе. Но у меня же нет доступа к тому подключению, у меня рут 
Неактивен
paulus написал:
Можно посмотреть на netstat его соединений?
Не подскажете пример аргументов для нашего случая? Не могу понять что нужно увидеть))
Неактивен
Про нетстат. Допустим, у нас есть вот такая строка
Неактивен
