Комментарии 21
SATA software RAID 1 — это у вас неслабое такое бутылочное горлышко.
Очень рекомендую настроить autopartitioning для БД zabbix.
www.zabbix.org/wiki/Docs/howto/zabbix2_postgresql_autopartitioning
Конкретно, инструкция для таблиц:
И удалять дневные партиции старше 30 дней.
И отключить housekeeper в zabbix.
А то у вас через пару месяцев все будет очень тормозить.
Оно и сейчас плохо себя чувствует, если у вас la 2-3.
Очень рекомендую настроить 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.
Спасибо за рекомендацию.
Воспользуемся.
Воспользуемся.
Прошу прощения, у не разглядел вас mysql.
Вам более актуален вот этот коммент.
Вам более актуален вот этот коммент.
Если не собираетесь использовать galera master-master replication, то Вам сюда MariaDB+TokuDB. После Токи забыли, что такое InnoDB
Да ессно сделать партиционирование с автоудалением партиций и сделать stackoverflow.com/questions/21586298/tokudb-sorting-time-different-between-asc-vs-desc
в конфиг сервера.
Мы еще пару индексов стандартных сделали clustering=yes.
Но есть маленький затык, сейчас будем обновляться до 2.4, а там сервер сам создает временные таблицы и вот как то пока не уверены как пройдет :)
в конфиг сервера.
Мы еще пару индексов стандартных сделали 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 (уже конец месяца).
Собственно, на основании этого мануала настраивал на аналогичной железке в хц. База давно перевалила за 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.
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.
Я правильно понял, что вы имеете в виду zfs на linux?
Если из теории, контроллеры используют различные алгоритмы балансировки нагрузки по дискам.
Насколько я помню, они это делают даже на raid1.
Ситуация такова, что линуксовый md делает всё то же самое, что и хардварный контроллер, только лучше. Даже в Windows Server программный raid работает как минимум не хуже. Поэтому и вопрос: зачем нужен хардварный контроллер массивов и какова его роль в данном случае?
ZFS, конечно же, на Linux. Вряд ли центосадмины настолько упороты, чтобы именно мониторинг запускать на NetBSD.
ZFS, конечно же, на Linux. Вряд ли центосадмины настолько упороты, чтобы именно мониторинг запускать на NetBSD.
А у вас есть конкретные цифры?
И расскажите, пожалуйста, чем хорош zfs, применительно к данном случаю?
Я думал о ней, как об объединении fs и lvm.
И расскажите, пожалуйста, чем хорош zfs, применительно к данном случаю?
Я думал о ней, как об объединении fs и lvm.
Единственные конкретные цифры, которые я помню, были в статье в году 2007-2008. В те времена софтовый рейд незначительно проигрывал (какому-то) хардварному рейду. Насколько я знаю (и могу судить по доступным серверам), сейчас дела обстоят сильно лучше. Статью обязательно найду и дам ссылку. Это если говорить только о скорости записи байтов и не принимать в рассчёт другие аспекты (переезд с сервера на сервер с помощью RAID-1, например).
ZFS умеет не только fs + lvm2, но ещё и RAID-Z. Про это можно было бы написать отдельную статью, но они и так уже все написаны.
ZFS умеет не только fs + lvm2, но ещё и RAID-Z. Про это можно было бы написать отдельную статью, но они и так уже все написаны.
Это было довольно просто.
О, да! partitioning для zabbix — это точно must-have. Вообще не понятно, почему они его в дистрибутив не включают. При любой более-менее серьезной нагрузке housekeeper становится убийцей.
Что-то интересные и подозрительные числа у вас получаются:
всего добавлено в мониторинг 84221 item'ов, из них 5970 выключено и 17184 в статусе zbx_notsupported.
всего добавлено в мониторинг 84221 item'ов, из них 5970 выключено и 17184 в статусе zbx_notsupported.
Всего 107тыс.
Все верно, общее число 107375, но из них:
мониторится — 78 %
в статусе «disabled» ~6%
в статусе «not supported» — 16%
Конечно, это может быть не критично, но мое мнение — лучше избегать такой ситуации, когда будут присутствовать «not supported» элементы, чтобы:
1. Не было месива из элементов в конфигурации хоста (например, хотя бы даже для удобства просмотра и банального порядка в конфурации хоста)
2. Для удобства отслеживания «not supported» элементов, в случае если по какой-то причине элемент перешел в такой статус. Будет обидно, а порой и критично, если вдруг элемент перешел в такой статус, при этом произошло событие, а оповещение не пришло.
3. По умолчанию производится перепроверка «not supported» элементов каждые 10 минут. Итого в данной ситуации получаем, что каждые 10 минут перепрвоеряется 16% потенциально ненужных элементов.
мониторится — 78 %
в статусе «disabled» ~6%
в статусе «not supported» — 16%
Конечно, это может быть не критично, но мое мнение — лучше избегать такой ситуации, когда будут присутствовать «not supported» элементы, чтобы:
1. Не было месива из элементов в конфигурации хоста (например, хотя бы даже для удобства просмотра и банального порядка в конфурации хоста)
2. Для удобства отслеживания «not supported» элементов, в случае если по какой-то причине элемент перешел в такой статус. Будет обидно, а порой и критично, если вдруг элемент перешел в такой статус, при этом произошло событие, а оповещение не пришло.
3. По умолчанию производится перепроверка «not supported» элементов каждые 10 минут. Итого в данной ситуации получаем, что каждые 10 минут перепрвоеряется 16% потенциально ненужных элементов.
11111111
У меня сервера на поддержке разбросаны по интернету. Передавать данные мониторинга от них в нешифрованном виде я посчитал непозволительной роскошью, поэтому на заббикс-сервере поднят openvpn сервер, раздающий приватную ipv6-подсеть, по которой работает стандартное обнаружение заббикса. Чтобы хост был добавлен в систему достаточно просто назначить ему роль service_vpn.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Наш Zabbix