Не все кодировки одинаково полезны
May. 5th, 2015 03:44 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
crowerНаступил на грабли.
Началось с того что заглянув в кактус обнаружил, что на одном серваке поселились лангольеры. Точнее, не поселились, а появляются набегами, регулярно. Да, да, такие круглые летающие штучки с тремя зубастыми челюстями, которые пожирают время. :)
Вот и тут раз в час потребление процессорного времени подскакивает до 50%.
Было бы больше, но похоже на нераспараллеливающийся процесс, который пожирает время только одного из двух ядер.
И растягивается сей процесс минуты на две с четвертью.
После чего лангольеры исчезают бесследно.
Была мысль что это загрузка веб-клиентом прожорливой задачи, но скоро отпала потому как авторефреша в ней нет (хотя браузеру-то никто не указ) и логи ничего не кажут.
Остался вариант, что это связано с загрузкой нового типа файлов, которые поставил на автомат как раз тогда, когда поселились эти гады. Но файл появляется раз в сутки ночью, а тахионный кризис наступает каждый час. То есть понятно что как-то это связано (время совпадает), но как - совсем непонятно.
К их ближайшему появлению приготовился: top для отслеживания (началось!).
Наступает время и что я вижу? mysql!
Блин! Но как узнать кто и что именно делает в это время? ps? netstat?
За время набега выяснить не успел, но приготовился к следующему: запустил mysql с приготовленным show processlist.
По крайней мере это-то должно более точно показать что именно происходит.
Оказывается лангольеров породила нестыков с кодировками. Запускается процесс, который загружает кучу записей. В каждой ссылка на файл (его имя). Но имя длинное и с целью нормализации оно выводится в отдельную таблицу, а процедура, которая эту запись сохраняет, вместо имени файла сохраняет в записи айдишиник, указывающий на файл. И таблица не большая - несколько десятков тысяч записей. Но фишка в чём?
Вот так: "select id from table where field=input_param.." это выглядит в коде, а вот так "select id from table where field=NAME_CONST('input_param', _utf8'значение'.." отображается в show processlist.
Откуда подчёркнутая хрень взялась?
В общем, пытался я оптимизить таблицы. Имена файлов там латиницей. Хотел на латиницу заменить юникод (utf8). Чтобы меньше места и быстрее. Ага. А получил на пару порядков дольше. То ли из процедуры с переключением кодировок кэш не работает, то ли с клиентом кодировка не сошлась, то ли ещё что-то - разбираться было некогда. Вернул utf8 и колючки не кактусе даже не заметно.
Так что не всё так просто.
Началось с того что заглянув в кактус обнаружил, что на одном серваке поселились лангольеры. Точнее, не поселились, а появляются набегами, регулярно. Да, да, такие круглые летающие штучки с тремя зубастыми челюстями, которые пожирают время. :)
Вот и тут раз в час потребление процессорного времени подскакивает до 50%.
Было бы больше, но похоже на нераспараллеливающийся процесс, который пожирает время только одного из двух ядер.
И растягивается сей процесс минуты на две с четвертью.
После чего лангольеры исчезают бесследно.
Была мысль что это загрузка веб-клиентом прожорливой задачи, но скоро отпала потому как авторефреша в ней нет (хотя браузеру-то никто не указ) и логи ничего не кажут.
Остался вариант, что это связано с загрузкой нового типа файлов, которые поставил на автомат как раз тогда, когда поселились эти гады. Но файл появляется раз в сутки ночью, а тахионный кризис наступает каждый час. То есть понятно что как-то это связано (время совпадает), но как - совсем непонятно.
К их ближайшему появлению приготовился: top для отслеживания (началось!).
Наступает время и что я вижу? mysql!
Блин! Но как узнать кто и что именно делает в это время? ps? netstat?
За время набега выяснить не успел, но приготовился к следующему: запустил mysql с приготовленным show processlist.
По крайней мере это-то должно более точно показать что именно происходит.
Оказывается лангольеров породила нестыков с кодировками. Запускается процесс, который загружает кучу записей. В каждой ссылка на файл (его имя). Но имя длинное и с целью нормализации оно выводится в отдельную таблицу, а процедура, которая эту запись сохраняет, вместо имени файла сохраняет в записи айдишиник, указывающий на файл. И таблица не большая - несколько десятков тысяч записей. Но фишка в чём?
Вот так: "select id from table where field=input_param.." это выглядит в коде, а вот так "select id from table where field=NAME_CONST('input_param', _utf8'значение'.." отображается в show processlist.
Откуда подчёркнутая хрень взялась?
В общем, пытался я оптимизить таблицы. Имена файлов там латиницей. Хотел на латиницу заменить юникод (utf8). Чтобы меньше места и быстрее. Ага. А получил на пару порядков дольше. То ли из процедуры с переключением кодировок кэш не работает, то ли с клиентом кодировка не сошлась, то ли ещё что-то - разбираться было некогда. Вернул utf8 и колючки не кактусе даже не заметно.
Так что не всё так просто.