Screens, тормоза

[Gray]

Всем тёплых мягких оладушек с земляничным вареньем на завтрак со свежезаваренным кофеём, например.

Имеется пробема по долгой отрисовке графиков в скринс. Прошу помочь лыжи ли не едут либо я альтернативно одарён?

Вот слоу куиес мускуля, два графика выборка за день, итемы собираются раз в 30 сек

# Time: 120120 13:40:44
# User@Host: zabbix[zabbix] @ localhost []
# Query_time: 48.093995 Lock_time: 0.000213 Rows_sent: 501 Rows_examined: 3873
SET timestamp=1327052444;
SELECT itemid,round(500*(mod( CAST(clock AS UNSIGNED) +51627,86400))/(86400),0) as i, count(*) as count,avg(value) as avg,min(value) as min, max(value) as max,max(clock) as clock FROM history_uint WHERE itemid=29256 AND clock>=1326965973 AND clock<=1327052373 GROUP BY itemid,round(500*(mod( CAST(clock AS UNSIGNED) +51627,86400))/(86400),0);

mysql> explain SELECT.....
| 1 | SIMPLE | history_uint | range | history_uint_1 | history_uint_1 | 12 | NULL | 2849 | Using where; Using temporary; Using filesort |

Заббикс 1.8.8, Мускуль 5.5.15 ИнноДБ, работает по фряхой 8.2. Активных итемов 7362. Сервак, не сервак, а так - тестовая машинка, 512мб памяти. Когда увидел размер иннодб 14 гигов, почистил руками все хистори и трендс, трабла осталась если делать выборку не на 1-3 часа, а побольше, например на день.
Чо к чему? Чо так долго-то? В БД, СКЛ и улутшайзингу запросов не специалист...

[dima_dm]

У вас, скорее всего, проблема с MySQL
Почитайте:

http://www.zabbix.com/forum/showthread.php?t=19215

512MB памяти на сервер это очень мало.
Настройте мониторинг MySQL
Шаблон мониторинга MySQL сервера
В конфигурационный файл zabbix_agentd.conf добавляется строки ниже,
Заменив поля на
<user> - username mysql пользователя
<password> - пароль этого mysql пользователя
<database> - имя базы данных
В /etc/zabbix/zabbix_agentd.conf

UserParameter=mysql.ping,mysqladmin –u<user> -p<password> ping|grep alive|wc -l
UserParameter=mysql.uptime,mysqladmin -u<user> -p<password> status|cut -f2 -d":"|cut -f1 -d"T"
UserParameter=mysql.threads,mysqladmin -u<user> -p<password> status|cut -f3 -d":"|cut -f1 -d"Q"
UserParameter=mysql.questions,mysqladmin -u<user> -p<password> status|cut -f4 -d":"|cut -f1 -d"S"
UserParameter=mysql.slowqueries,mysqladmin -u<user> -p<password> status|cut -f5 -d":"|cut -f1 -d"O"
UserParameter=mysql.qps,mysqladmin -u<user> -p<password> status|cut -f9 -d":"
UserParameter=mysql.version,mysql –V
#database size
UserParameter=mysql.database.size.zabbix,mysqlshow -u<user>  -p<password>  --status <database>| cut -d\| -f 8,10 -s --output-delimiter="|" |awk -F"|" '{ total = total+$1+$2 } END {print total}'

[SergeniuS]

Всем тёплых мягких оладушек с земляничным вареньем на завтрак со свежезаваренным кофеём, например.
...
Когда увидел размер иннодб 14 гигов, почистил руками все хистори и трендс, трабла осталась, если делать выборку не на 1-3 часа, а побольше, например на день.

И тебе вкусных круасанов.
А база какого размера стала после очистки?

[Gray]

И тебе вкусных круасанов.
А база какого размера стала после очистки?

Размер файла базы не изменился. После delete from trends* delete from history* делал ещё аналайз, оптимайз, - как об стенку горох. Возможно я лоханулся, но где-то в поиске мелькнуло что это дескать особенность иннодб - файл базы не будет меняться от очистки данных.
Попробую попозже перейти на майисам чтоли...

[SergeniuS]

Попробуй сделать бэкап и восстановление с помощью mysqldump, должен пересоздать таблицы

[dima_dm]

Размер файла базы не изменился. После delete from trends* delete from history* делал ещё аналайз, оптимайз, - как об стенку горох. Возможно я лоханулся, но где-то в поиске мелькнуло что это дескать особенность иннодб - файл базы не будет меняться от очистки данных.
Попробую попозже перейти на майисам чтоли...

Все правильно, включите опцию, как написано в моей ссылке
innodb_file_per_table
И команда OPTIMIZE TABLE будет уменьшать размеры файлов таблиц BD.

[Gray]

переделал под иннодб файл на таблицу.
получилось 6 сек против 46, вполне приемлемо. спасибо.

тупо получается обычный иннодб юзать в случае когда у вас ротация данных, старые удаляются, новые накатывают

[pilson66]

переделал под иннодб файл на таблицу.
получилось 6 сек против 46, вполне приемлемо. спасибо.

тупо получается обычный иннодб юзать в случае когда у вас ротация данных, старые удаляются, новые накатывают

Добавь оперативки, чтобы в память влазили данные за пару дней.
Тогда первый запрос будет медленным, а остальные - доли секунды.

[Gray]

Хлопцы, имею мнение что и 512мб на такое количество итемов\реквестов в секунду должно быть ок. После того как переделал под ИнноДБ лучше стало буквально на пару суток, как только файл history.idb снова разросся снова всё стало пичяльно. Напомню, InnoDB - плохо работает на delete и не уменьшает размеры файлов при удалении строк. Таблицы history* и trend* в заббиксе же требуют постоянного ротейта. Одно из решений виденных мною в сети отключить нафиг housekeep - тот самый ротейт средствами заббикса, сделать partitioning этих таблиц по clock и самодельные функции по удалению старых партиций.
Напомню машинка у меня под тесты посему хотелось поменьше извращений и я сделал пока проще - таблицы history и history_uint перевёл в MyISAM(дамп, редактирование дампа, дроп, криейт, востановление дампа) - получил сразу же моментальный эффект, пока генерится на лету.
А в будущем для ночью можно аналайз\оптимайз запускать на эти таблицы. Полагаю эти костыли должны помочь, по результату отчитаюсь.