Comments 21
SATA software RAID 1 — это у вас неслабое такое бутылочное горлышко.
Очень рекомендую настроить autopartitioning для БД zabbix.
www.zabbix.org/wiki/Docs/howto/zabbix2_postgresql_autopartitioning
Конкретно, инструкция для таблиц:
history
history_sync
history_uint
history_str_sync
history_log
trends
trends_uint

И удалять дневные партиции старше 30 дней.
И отключить housekeeper в zabbix.
А то у вас через пару месяцев все будет очень тормозить.
Оно и сейчас плохо себя чувствует, если у вас la 2-3.
Если не собираетесь использовать galera master-master replication, то Вам сюда MariaDB+TokuDB. После Токи забыли, что такое InnoDB
Да ессно сделать партиционирование с автоудалением партиций и сделать stackoverflow.com/questions/21586298/tokudb-sorting-time-different-between-asc-vs-desc
в конфиг сервера.

Мы еще пару индексов стандартных сделали clustering=yes.
Но есть маленький затык, сейчас будем обновляться до 2.4, а там сервер сам создает временные таблицы и вот как то пока не уверены как пройдет :)
Ссылка на Postgresql, а у ТС Mysql. Так лучше: www.zabbix.com/wiki/non-english/ru/partitioning_in_mysql
Собственно, на основании этого мануала настраивал на аналогичной железке в хц. База давно перевалила за 30ГБ,
текущий load average: 0,99, 0,73, 0,65 (уже конец месяца).
>SATA software RAID 1 — это у вас неслабое такое бутылочное горлышко.
Простите, на чем основано это утверждение?
На характере нагрузки на дисковую подсистему.
SATA диски очень не любят одновременно кучу операций чтения + записи.
Особенно, если это не последовательная запись/чтение.
При работе zabbix+mysql мы имеем постоянную запись в БД + периодические чтения массы данных, когда рисуются графики.
Параллельно работает housekeeper (процесс, который удаляет старые данные из таблиц history, т.е. читает и пишет).
Если бы база была postgresql, там ещё мог быть запущен autovacuum (который при постоянной записи в БД может больше вредить).
Т.е. именно то, что не любят SATA диски.
Дисковый кеш на 64 мб тут не поможет, умного рейд контроллера с памятью нету, оперативки немного.
Я бы предложил топикстартеру посмотреть htop, iotop, iostat.
Вполне возможно, там неплохой iowait.
А когда база разрастется за пределы оперативки, все будет тормозить ещё сильнее.

А нагрузка у них очень немалая.
1,5 тыс item'ов в секунду — это много.
Имхо, их спасает, что у них ещё немного пользователей работает с веб мордой, 11 users online.
Скажем, когда их 50, и у всех открыты скрины с графиками, возникает значительная нагрузка базы на чтение.
Графики рисуются средствами php+БД, т.е. просто берутся из базы, там не используется кеширование средствами zabbix.

Когда zabbix перестанет успевать обрабатывать данные, на графиках начнутся пробелы.
В этом случае я бы рекомендовал SAS диски + raid контроллер со своей памятью и raid10.
В этом случае я бы рекомендовал SAS диски + raid контроллер со своей памятью и raid10.


А какую именно задачу должен решать контроллер с памятью, которая не решается при помощи md или zfs? В конкретных цифрах, если можно.
Я не сравнивал md, zfs и контроллер с памятью.
Я правильно понял, что вы имеете в виду zfs на linux?
Если из теории, контроллеры используют различные алгоритмы балансировки нагрузки по дискам.
Насколько я помню, они это делают даже на raid1.
Ситуация такова, что линуксовый md делает всё то же самое, что и хардварный контроллер, только лучше. Даже в Windows Server программный raid работает как минимум не хуже. Поэтому и вопрос: зачем нужен хардварный контроллер массивов и какова его роль в данном случае?

ZFS, конечно же, на Linux. Вряд ли центосадмины настолько упороты, чтобы именно мониторинг запускать на NetBSD.
А у вас есть конкретные цифры?
И расскажите, пожалуйста, чем хорош zfs, применительно к данном случаю?
Я думал о ней, как об объединении fs и lvm.
Единственные конкретные цифры, которые я помню, были в статье в году 2007-2008. В те времена софтовый рейд незначительно проигрывал (какому-то) хардварному рейду. Насколько я знаю (и могу судить по доступным серверам), сейчас дела обстоят сильно лучше. Статью обязательно найду и дам ссылку. Это если говорить только о скорости записи байтов и не принимать в рассчёт другие аспекты (переезд с сервера на сервер с помощью RAID-1, например).

ZFS умеет не только fs + lvm2, но ещё и RAID-Z. Про это можно было бы написать отдельную статью, но они и так уже все написаны.
О, да! partitioning для zabbix — это точно must-have. Вообще не понятно, почему они его в дистрибутив не включают. При любой более-менее серьезной нагрузке housekeeper становится убийцей.
Что-то интересные и подозрительные числа у вас получаются:
всего добавлено в мониторинг 84221 item'ов, из них 5970 выключено и 17184 в статусе zbx_notsupported.
Все верно, общее число 107375, но из них:
мониторится — 78 %
в статусе «disabled» ~6%
в статусе «not supported» — 16%

Конечно, это может быть не критично, но мое мнение — лучше избегать такой ситуации, когда будут присутствовать «not supported» элементы, чтобы:
1. Не было месива из элементов в конфигурации хоста (например, хотя бы даже для удобства просмотра и банального порядка в конфурации хоста)
2. Для удобства отслеживания «not supported» элементов, в случае если по какой-то причине элемент перешел в такой статус. Будет обидно, а порой и критично, если вдруг элемент перешел в такой статус, при этом произошло событие, а оповещение не пришло.
3. По умолчанию производится перепроверка «not supported» элементов каждые 10 минут. Итого в данной ситуации получаем, что каждые 10 минут перепрвоеряется 16% потенциально ненужных элементов.
Да, в этом случае лучше всего делать мониторинг мониторинга (item на количество not supported items). Но во время введения в эксплуатацию и отладки такое может случаться часто, особенно если есть LLD айтемы.
У меня сервера на поддержке разбросаны по интернету. Передавать данные мониторинга от них в нешифрованном виде я посчитал непозволительной роскошью, поэтому на заббикс-сервере поднят openvpn сервер, раздающий приватную ipv6-подсеть, по которой работает стандартное обнаружение заббикса. Чтобы хост был добавлен в систему достаточно просто назначить ему роль service_vpn.
Only those users with full accounts are able to leave comments. Log in, please.