Обнаружить источник запроса

[гость]

Добрый день!
Помогите пожалуйста разобраться в следующей ситуации: есть MySQL 4.0 на FreeBSD 6.2. Периодически мускуль начинает отжирать 99% ресурсов и, всё что на нём завязано умирает надолго. Наблюдениями было установлено, что причиной тому есть некий запрос,который при этом появляется в processlist примерно каждые 5 минут. Проблема в том, что никто не знает,что это такое и чем, или кем (каким скриптом, программой) оно инициируется. Перелопатил весь крон и вообще всю периодику на серваке, ничего не нашел, прогрепал всё файло - безрезультатно. Теперь думаю, что возможно это какой-то бинарник (там у меня крутится проприетарный close-source софт), но как его найти?
Можно ли средствами мускуля или ОС по тексту запроса (как он виден в processlist) обнаружить его источник? Или получить статистику, какие процессы, скрипты, программы обращались к мускулю в заданный промежуток времени (например за последние 5 минут)? Какие для этого существуют инструменты?
Заранее спасибо.

[Хостинг HostFood.ru]

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

[zg]

всё довольно просто:
1. на каждую софтину создаёшь отдельного пользователя муси
2. во время активности смотришь чьи запросы грузят систему

Код: Выделить всё

mysql> SHOW PROCESSLIST;
+----+------+-----------+------+---------+------+-------+------------------+
| Id | User | Host      | db   | Command | Time | State | Info             |
+----+------+-----------+------+---------+------+-------+------------------+
| 33 | root | localhost | NULL | Query   |    0 | NULL  | SHOW PROCESSLIST |
+----+------+-----------+------+---------+------+-------+------------------+
1 row in set (0.04 sec)

mysql>

[гость]

Хорошая идея, но в данном случае не подходит. Почему?
Дело в том, что методом исключения уже установленно, что трабла лезет из этой самой close-sorce софтины. Но тут возникают следующие вопросы:
1) Мы не можем самостоятельно изменить мускульного юзера для этого продукта, нужно обращаться к евойным разработчикам. А они отнекиваются, мол не при делах, и категорически отказываются от каких бы то ни было инвестигейшинов, считают, что трабла на нашей стороне.
2) Этот продукт имеет модульную структуру, т.е. состоит из множества маленьких программок ходящих в мускуль под одним и тем же юзером (точнее под рутом). Тобишь, даже поменяв юзера, мы не узнаем ничего нового (ну, разве что убедимся в том, что и так уже знаем наверняка).
Вот поэтому мы и хотим определить точно, какая утилита, демон, либа или что-то ещё вызывает траблу. Что бы можно было в наглядном виде показать это разработчикам и заставить их шевелиться.

[zg]

Вот поэтому мы и хотим определить точно, какая утилита, демон, либа или что-то ещё вызывает траблу.

в явном виде никак, только в косвенном. Для этого нужно включить лог запросов и ждать время Ч. Как только сервер ушёл в даун нужно точно засечь время и по логу определить какие запросы куда шли. Проанализировав запросы (через EXPLAIN) можно точно сказать, какой именно запрос глушит сервер. Ну и по содержанию запроса можно будет сказать чьи данные он обрабатывал, а занчит кто виноват в этой катовасии.

[гость]

Проанализировав запросы (через EXPLAIN) можно точно сказать, какой именно запрос глушит сервер

Какой запрос - мы уже знаем. Достаточно его кильнуть, что бы убедиться что это именно он.
А вот не знаете, можно ли как-то сопоставить id процесса в processlist с пидом процесса в системе? Ну или не с пидом, но хоть к чему-то привязать из того что показывают ls,top,fstat,lsof и иже с ними?
Задачка тогда решалась бы очень просто

[ev]

можно включить лог медленных запросов и потом просто глянуть кто и сколько тупит

[гость]

можно включить лог медленных запросов и потом просто глянуть кто и сколько тупит

Да,согласен,это было бы просто здорово,если б нужно было узнать какой из запросов тупит. Но мы и так уже это знаем!
Вопрос в другом: не кто тупит, а откуда он приходит

[ev]

ну так если сам запрос известен, то в чем проблема?
по его содержимому можно понять откуда он приходит... если конечно у вас не бардак совсем... а если бардак - то надо сначала в нем разобраться

[Гость]

Проблема не в том, что бардак. Как я говорил выше, на этом тазике крутится закрытая проприетарная софтина, которая включает в себя множество мелких программок, которые лазят в мускуль под рутом. Всё читабельно-писабельное уже прогрепали несколько раз, назначили отдельных юзеров для всего. Методом исключения остаются только бинарники из состава этой самой проприетарной софтины. Делал strings всего, что нашел - безрезультатно. Снаружи он тоже не приходит, мы это исключили. Остаётся только предположить, что этот запрос где-то захардкоденный. Но как найти где? Кто-то же обращается в мускуль с этим запросом, как это отследить?

[zg]

Кто-то же обращается в мускуль с этим запросом, как это отследить?

ну... можно через сокстат, попробовать. Он даёт pid, по которому можно отследить процесс.

[Alex Keda]

разработчикам запрос выкатывали?
чё они говорят?
===========
муся 4 имела такую особенность - впадания в ступор.
может пора версию обновить?

[гость]

разработчикам запрос выкатывали?
чё они говорят?

Они отнекивались до последнего, аж пока мы сами не нашли и не показали им. Как и предполагалось, оказался захаррдкоденный, но strings(8) знает своё дело.
Составлен сам запрос кстати весьма бестолково. Я добавил к нему всего один дополнительный кондишн и стал отрабатывать на порядок быстрее.
Теперь другая проблема... девелы отказываются что-либо переделывать якобы по причине EoL данной версии продукта (но я предполагаю, что настоящая причина кроется в том, что люди которые всё это писали уже там не работают, а кто работает - не расчехляются). И вот задумался теперь, как бы мне его продизасмить да посмотреть внутреннюю логику, может самому удастся переделать.
Сам никогда ничего на фряхе не дизасмил, так что, уважаемые коллеги, буду признателен за помощь.
Предположительно писалось на С, но хотя ХЗ... никаких исходников мы никогда не видели...
Подсобите пжлст, кто силён в данном вопросе.

муся 4 имела такую особенность - впадания в ступор.
может пора версию обновить?

И пора, и с радостью бы.
Поднимал этот вопрос намедни, на что разработчики мне радостно отрапортовали, что 5й мускуль наша версия продукта не поддерживает

[zg]

что 5й мускуль наша версия продукта не поддерживает

пятая муся не держит только клиента от третьей версии, во всём остальном обратная совместимость просто фантастическая благодаря тюнингу настроек

[ev]

И вот задумался теперь, как бы мне его продизасмить да посмотреть внутреннюю логику, может самому удастся переделать.

зачем? ценность подобного софта и идеологии
достаточно взять человека шарящего в теме и будет все понятно

[paix]

что 5й мускуль наша версия продукта не поддерживает

пятая муся не держит только клиента от третьей версии, во всём остальном обратная совместимость просто фантастическая благодаря тюнингу настроек

4ая муся не умела utf8, на сим моменте очень много граблей может всплыть. Ибо в блобе все...

[zg]

4ая муся не умела utf8,

начиная с 4.1.11, держала

на сим моменте очень много граблей может всплыть

при правильно настроенном сервере, обычно проблем не было.

[paix]

у топикстартера 4.0

кроме того в случае шибко умных запросов, которые любят делать в проприетарщине, 5ый тоже может не подойти.

Пример, у меня есть некоторые приложения которые на 4.1 работают, а на 5.0 вылазят бока на специфических запросах.

[zg]

у топикстартера 4.0

всё равно не вижу проблем, 4.0 работала в однобайтовой кодировке ака cp1251, пятая муся её держит на ура.

кроме того в случае шибко умных запросов, которые любят делать в проприетарщине, 5ый тоже может не подойти.

наврядли есть проблемы, которые не решатся режимами совместимости.

Пример, у меня есть некоторые приложения которые на 4.1 работают, а на 5.0 вылазят бока на специфических запросах.

-))) приведи пример

[paix]

cp1251 в 4.0 нет.

Если данные хранятся в блобе (при этом типа ut8) то после переезда на 4.1, 5.0 будут одни крокозябли

пример: приложения онлайнбронирования авиабилетов со сложной бизнес-логикой.

[zg]

cp1251 в 4.0 нет.

это без разницы, cp1251 однобайтовая

Если данные хранятся в блобе (при этом типа ut8) то после переезда на 4.1, 5.0 будут одни крокозябли

гм.. http://dev.mysql.com/doc/refman/5.1/en/blob.html

BLOB columns are treated as binary strings (byte strings). TEXT columns are treated as nonbinary strings (character strings). BLOB columns have no character set, and sorting and comparison are based on the numeric values of the bytes in column values. TEXT columns have a character set, and values are sorted and compared based on the collation of the character set.

кракозябры будут только в том случае, если дамп был либо криво сделан, либо криво импортирован. Что, впрочем, зависит только от рук

пример: приложения онлайнбронирования авиабилетов со сложной бизнес-логикой.

это не пример это пальцем в небо. Запрос нужен, который однозначно будет работать только в 4.0, но никак не в 5. Тогда и говорить можно про бизнесс логику.

[paix]

ладно
запрос я счас не сделаю да и задачи такой нет.

Помню что когда приложения на новый сервер переносил и хотел юзать системный мускиль - на эту траблу нарвался, сидели разбирались с программерами и решили что нефиг рабочую систему ломать.

Уже хватило мне примеров что нельзя рабочие системы просто так на другую версию переводить.
Пример: после апдейта сабвершина с 1.4 на 1.5 поотваливались idea и eclipse.

Правило старо как мир: лучшее - враг хорошего, или работает - не трогай