Все странички zabbix грузятся медленно

[father]

Я новичек в ZABBIX, установил последнюю версию 1.8.3 из исходников, БД - PosgreSQL, система Arch Linux 64бит. Все как бы хорошо, начал разбираться с ZABBIX, но очень напрягает то, что все страницы грузятся секунд по 15-20, а то и 30... Заметил так же, что дольше всего грузится файл jsLoader.php (отследил с помощью Firebug).
У кого есть/были такие проблемы, подскажите плиз как пофиксить???
Спасибо.

[dima_dm]

На моей практике, все подобные проблемы решались оптимизацией базы данных, что крутить на PosgreSQL не подскажу, т.к. всегда использовал базу MySQL.
Ни и смотрите error log Web сервера.

[father]

Да логи конечно смотрел и включил также display_errors в php.ini, но никаких ошибок нет.
Кстати, на другом сервере, после обновления ZABBIX до 1.8.3 тоже появилась такая же проблема. Там используется MySQL. Проблема в точности такая же, долго грузится файл jsLoader.php, ссылка такая:

http://mon.mydomen.com/jsLoader.php?ver=1.8.3&lang=ru_ru

[dima_dm]

Ссылка ваша у меня не работает.
А с MySQL я делал следующие
Опция /etc/my.cnf
innodb_file_per_table

Если у вас не было этой опции, то нужно:
Сделать полный Dump
mysqldump -u root -ppassword zabbix >dump.sql
mysql> drop database zabbix;
mysql> create database zabbix;
cat dump.sql | mysql -u root -ppassword zabbix

Далее используете скрипты для оптимизации параметров MySQL

http://www.day32.com/MySQL/tuning-primer.sh

http://wiki.mysqltuner.com/MySQLTuner

mysqltuner.pl

http://hackmysql.com/mysqlreport

постарайтесь сделать tmpdir для MYSQL в разделе смонтированном в оперативной памяти
Примерно так
/etc/my.cnf
tmpdir = /tmp
/etc/fstab
none /tmp tmpfs mode=777,size=1024M,uid=root,gid=root 0 0

[dima_dm]

Кстати, это могут быть проблемы на сетевом оборудовании
Вы проверяли со своего ПК
telnet IP_Zabbix_WEB 80
telnet NAME_ Zabbix_WEB 80
Где
IP_Zabbix_WEB и NAME_ Zabbix_WEB нужно заменить на IP и DNS имя вашего сервера с Web интерфейсом Zabbix.
Задержки при подключении есть?

[O-2]

Спасибо за совет по настройке mysql - очень помогло.

[alp]

И всё же хотелось бы увидеть адекватные методы тюнинга PostgreSQL под работу нагруженного Zabbix с количеством элементов данных под 50 000 и собираемым данным в секунду до 300 хотябы. А то уже после 150-ти начинаются проблемы, особенно если работае housekeeper

[dotneft]

хаускипинг отключить, юзать партиционирование. самый важный совет
наблюдать за vacuum и тюнить таблицы items, triggers. Практически уверен, что у вас в топе висят запросы вида update triggers...

[alp]

1 хаускипер. Насколько я понимаю он достаточно важный кусок системы, ибо чистит мусор и сокращает объём БД. Его отключение привело к почти полному падению нагрузки. Но вероятно база будет расти быстрее.

2 патишонинг. Это для меня вообще какая-то страшная диковина. Поскольку чтобы её реализовать нужно понимать внутреннюю логику работы заббикса. А чтение этого мануала http://www.zabbix.com/wiki/non-engli..._in_postgresql вообще повергает меня в тихий ужас, посольку, как я понял приведённый там код является только примером и не будет работать в варианте "как есть" =(

3 Автовакуум. Был отключён почти сразу. Насколько я понимаю его роль похожа на роль хаускипера только не для заббикса, а для самого постгреса. Как результат это должно привести к забиванию кэшей и всего такого.

4 когда работал хаускипер в топе были только запросы по таблице history_uint, которая весила на тот момент около 70 гигов.

[dotneft]

3 Автовакуум. Был отключён почти сразу. Насколько я понимаю его роль похожа на роль хаускипера только не для заббикса, а для самого постгреса. Как результат это должно привести к забиванию кэшей и всего такого.
а вот это зря сделали. PostgreSQL версионник, и за ним обязательно нужно убирать мусор

[alp]

Не плохо было бы цитату помещать в специальный тэг, а то нифига не понятно где начинается Ваш ответ и заканчивается цитата!

Планируется запускать этот вакуум вручную. А то он постоянно работает и до 20% процессора отжирает при нагрузке.

[saa]

хаускипинг отключить, юзать партиционирование. самый важный совет
наблюдать за vacuum и тюнить таблицы items, triggers. Практически уверен, что у вас в топе висят запросы вида update triggers...

Извиняюсь, что поднял старый пост.

>тюнить таблицы items, triggers

Не могли бы, сказать более подробно, как их тюнить? Сегодня получил deadlock на items при updte. Спасибо.

[saa]

2 патишонинг. Это для меня вообще какая-то страшная диковина. Поскольку чтобы её реализовать нужно понимать внутреннюю логику работы заббикса. А чтение этого мануала http://www.zabbix.com/wiki/non-engli..._in_postgresql вообще повергает меня в тихий ужас, посольку, как я понял приведённый там код является только примером и не будет работать в варианте "как есть" =(

Это вы зря.

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

[dotneft]

Извиняюсь, что поднял старый пост.

>тюнить таблицы items, triggers

Не могли бы, сказать более подробно, как их тюнить? Сегодня получил deadlock на items при updte. Спасибо.

Посмотрите в сторону параметров этих параметров http://www.postgresql.org/docs/9.1/s...AGE-PARAMETERS Сделайте более агрессивное поведение vacuum для этих таблиц.

Вот нашел достаточно интересную документацию по этому поводу http://books.google.ru/books?id=pIYJ...0level&f=false

[srusv]

А вообще тюнинг Постгре весьма и весьма похож на тюниг мускл. 1) - разделить индексы и таблицы на разные физ. носители, 2) прогнать по медленным запросам и , возможно добавить индексы. 3) вынести хранилище временных кэшей в ФС в памяти , 4) желательно вынести онлайн логи на отдельную ФС . Очень сильно прибавляет в производительности. Вот, находил в свое время, помогло.