Всем привет. Собственно, проблема описана в заголовке. График очередей выглядит так:
Предыстроия:
Сразу оговорюсь, что все эти вещи только начал осваивать, так что сильно не ругайте за безграмотность.
zabbix 4.0. + postgres. 170 узлов, из которых примерно половина только пингуются, 5800 элементов данных, Требуемое быстродействие сервера 90 новых значения в секунду.
Мониторится сетевое железо: свичи, маршрутизаторы.
По мере накопления данных в какой-то момент Housekeeper стал работать непозволительно долго, в моменты его работы тупила веб-морда, что меня бесило.
Postgres работала с дефолтными настройками. Было принято решение оптимизировать работу БД и прикрутить partitioning.
После попытки оптимизации параметров Postgres в общем-то и стали возникать очереди. До partitioning не дошло пока.
Увидев это безобразие, откатил конфиг postgres, но эффекта не последовало, очереди не уходили.
Решил обновить Zabbix и, возможно, мигрировать на TimescaleBD.
Пока только обновил Zabbix до 4.4. Также прошелся VACUUM'ом по БД, размер её снизился процентов на 25-30, проблема с хаускипером ушла.
В какой-то момент без каких-либо моих действий очередь снизилась до в среднем 2 элементов, изредка вырастала до полутора десятков простых проверок с задержкой 5 сек, как в общем-то и было ВСЕГДА, до того, как я полез в конфиг postgres.
Я уже было успокоился, но через несколько часов очереди вернулись, потом снова пропали, в общем всё видно на графике.
в логе заббикс сервера - множество slow query:
14140:20200123:123622.231 slow query: 55.545371 sec, "select i.itemid,i.hostid,i.status,i.type,i.value_type,i.k ey_,i.snmp_community,i.snmp_oid,i.port,i.snmpv3_se curityname,i.snmpv3_securitylevel,i.snmpv3_authpas sphrase,i.snmpv3_privpassphrase,i.ipmi_sensor,i.de lay,i.trapper_hosts,i.logtimefmt,i.params,ir.state ,i.authtype,i.username,i.password,i.publickey,i.pr ivatekey,i.flags,i.interfaceid,i.snmpv3_authprotoc ol,i.snmpv3_privprotocol,i.snmpv3_contextname,ir.l astlogsize,ir.mtime,i.history,i.trends,i.inventory _link,i.valuemapid,i.units,ir.error,i.jmx_endpoint ,i.master_itemid,i.timeout,i.url,i.query_fields,i. posts,i.status_codes,i.follow_redirects,i.post_typ e,i.http_proxy,i.headers,i.retrieve_mode,i.request _method,i.output_format,i.ssl_cert_file,i.ssl_key_ file,i.ssl_key_password,i.verify_peer,i.verify_hos t,i.allow_traps,i.templateid,id.parent_itemid from items i inner join hosts h on i.hostid=h.hostid left join item_discovery id on i.itemid=id.itemid join item_rtdata ir on i.itemid=ir.itemid where h.status in (0,1) and i.flags<>2"
14147:20200123:123652.249 slow query: 55.516263 sec, "commit;"
14148:20200123:123752.311 slow query: 55.498083 sec, "commit;"
14148:20200123:123827.369 slow query: 55.519832 sec, "commit;"
14147:20200123:123837.396 slow query: 55.546305 sec, "commit;"
14151:20200123:123847.375 slow query: 55.529957 sec, "commit;"
14148:20200123:123847.392 slow query: 55.533754 sec, "commit;"
и все как на подбор примерно 55 сек.
в логе postgres изредка возникают:
2020-01-23 08:00:04.965 MSK [522] СООБЩЕНИЕ: stats collector's time 2020-01-23 08:01:00.659464+03 is later than backend local time 2020-01-23 08:00:04.965868+03
2020-01-23 08:00:04.966 MSK [523] СООБЩЕНИЕ: stats_timestamp 2020-01-23 08:01:00.659464+03 is later than collector's time 2020-01-23 08:00:04.96621+03 for database 0
Следует отметить, что очередей дольше 30 сек нет, но налицо медленная работа БД (или веб-морды заббикса), очень долго отрисовываются запросы, особенно графики.
Утилизация всякого рода поллеров незначительна, самое большое значение у icmp pinger , примерно 37%, среднее значение Utilization of poller data collector processes около 8%, но график коррелирует с графиком очередей:
Аналогичный график количества значений в секунду:
Прошу помощи. Подскажие, куда копать?
Предыстроия:
Сразу оговорюсь, что все эти вещи только начал осваивать, так что сильно не ругайте за безграмотность.
zabbix 4.0. + postgres. 170 узлов, из которых примерно половина только пингуются, 5800 элементов данных, Требуемое быстродействие сервера 90 новых значения в секунду.
Мониторится сетевое железо: свичи, маршрутизаторы.
По мере накопления данных в какой-то момент Housekeeper стал работать непозволительно долго, в моменты его работы тупила веб-морда, что меня бесило.
Postgres работала с дефолтными настройками. Было принято решение оптимизировать работу БД и прикрутить partitioning.
После попытки оптимизации параметров Postgres в общем-то и стали возникать очереди. До partitioning не дошло пока.
Увидев это безобразие, откатил конфиг postgres, но эффекта не последовало, очереди не уходили.
Решил обновить Zabbix и, возможно, мигрировать на TimescaleBD.
Пока только обновил Zabbix до 4.4. Также прошелся VACUUM'ом по БД, размер её снизился процентов на 25-30, проблема с хаускипером ушла.
В какой-то момент без каких-либо моих действий очередь снизилась до в среднем 2 элементов, изредка вырастала до полутора десятков простых проверок с задержкой 5 сек, как в общем-то и было ВСЕГДА, до того, как я полез в конфиг postgres.
Я уже было успокоился, но через несколько часов очереди вернулись, потом снова пропали, в общем всё видно на графике.
в логе заббикс сервера - множество slow query:
14140:20200123:123622.231 slow query: 55.545371 sec, "select i.itemid,i.hostid,i.status,i.type,i.value_type,i.k ey_,i.snmp_community,i.snmp_oid,i.port,i.snmpv3_se curityname,i.snmpv3_securitylevel,i.snmpv3_authpas sphrase,i.snmpv3_privpassphrase,i.ipmi_sensor,i.de lay,i.trapper_hosts,i.logtimefmt,i.params,ir.state ,i.authtype,i.username,i.password,i.publickey,i.pr ivatekey,i.flags,i.interfaceid,i.snmpv3_authprotoc ol,i.snmpv3_privprotocol,i.snmpv3_contextname,ir.l astlogsize,ir.mtime,i.history,i.trends,i.inventory _link,i.valuemapid,i.units,ir.error,i.jmx_endpoint ,i.master_itemid,i.timeout,i.url,i.query_fields,i. posts,i.status_codes,i.follow_redirects,i.post_typ e,i.http_proxy,i.headers,i.retrieve_mode,i.request _method,i.output_format,i.ssl_cert_file,i.ssl_key_ file,i.ssl_key_password,i.verify_peer,i.verify_hos t,i.allow_traps,i.templateid,id.parent_itemid from items i inner join hosts h on i.hostid=h.hostid left join item_discovery id on i.itemid=id.itemid join item_rtdata ir on i.itemid=ir.itemid where h.status in (0,1) and i.flags<>2"
14147:20200123:123652.249 slow query: 55.516263 sec, "commit;"
14148:20200123:123752.311 slow query: 55.498083 sec, "commit;"
14148:20200123:123827.369 slow query: 55.519832 sec, "commit;"
14147:20200123:123837.396 slow query: 55.546305 sec, "commit;"
14151:20200123:123847.375 slow query: 55.529957 sec, "commit;"
14148:20200123:123847.392 slow query: 55.533754 sec, "commit;"
и все как на подбор примерно 55 сек.
в логе postgres изредка возникают:
2020-01-23 08:00:04.965 MSK [522] СООБЩЕНИЕ: stats collector's time 2020-01-23 08:01:00.659464+03 is later than backend local time 2020-01-23 08:00:04.965868+03
2020-01-23 08:00:04.966 MSK [523] СООБЩЕНИЕ: stats_timestamp 2020-01-23 08:01:00.659464+03 is later than collector's time 2020-01-23 08:00:04.96621+03 for database 0
Следует отметить, что очередей дольше 30 сек нет, но налицо медленная работа БД (или веб-морды заббикса), очень долго отрисовываются запросы, особенно графики.
Утилизация всякого рода поллеров незначительна, самое большое значение у icmp pinger , примерно 37%, среднее значение Utilization of poller data collector processes около 8%, но график коррелирует с графиком очередей:
Аналогичный график количества значений в секунду:
Прошу помощи. Подскажие, куда копать?
Comment