Снова о партиционировании БД zabbix

говорят на постресе быстрее работает

Говорят, в австралии на голове ходят

В postgres можно создавать отдельный файл для каждой партиции?

Ну знаешь у нас postgres + zabbix. Никто не жаловался

Очень рад за вас. Так в postgres можно хранить каждую партицию в отдельном файле?

У вас слишком много свободного времени, чтобы так морочиться на мониторингом :) (не ваш работодатель:)

У вас слишком много свободного времени, чтобы так морочиться на мониторингом :) (не ваш работодатель:)

У нас слишком забит болт на отдельные вопросы мониторинга ( капитан очевидность )

https://www.postgresql.org/docs/current/static/storage-file-layout.html

When a table or index exceeds 1 GB, it is divided into gigabyte-sized segments.

На счет руками не знаю.

Вообще, если хочешь дальше жрать mysql, то посмотри в сторону перконы, у нее вроде с производительностью получше.

https://mariadb.com/kb/en/mariadb/partitions-files/

По моему опыту, проще оптимизировать сервер БД, оставить housekeeper и не заморачиваться с партицированием. По крайней мере для Zabbix >= 3.

Так в postgres можно хранить каждую партицию в отдельном файле?

Насколько я понимаю, то партиции в постгресе представлены как отдельные таблицы. Так что скорее всего можно, но надо проверить.

Партиционирование рекоммендуют при больших размерах базы (сотни гигабайт). Лучше оптимизировать работу БД без партиционирования.

У вас слишком много свободного времени, чтобы так морочиться на мониторингом

А что по твоему должен делать админ, принтеры в бухгалтерии чинить?

Если MariaDB - советую смотреть в сторону TokuDB для history. Партиционирование зависит от объёма, в большинстве случаев пока хистори меньше десятка гигов, можно особо не напрягаться.

Что же касается innodb_file_per_table - вообще это давно пора включать «по умолчанию». Вероятность столкнуться со случаем, когда это вредно, чуть менее 0.

Перед конверсией таблиц опцию включить обязательно - иначе потом, чтобы выдрать таблицы в файлы из ibdata, придётся делать ALTER на таблицу. Объём ibdata при этом не уменьшается. Поэтому лучше сразу.

Ну и да. С этой опцией каждая партиция InnoDB будет лежать в отдельном файле.

Попробуй постгрес. Разница в производительности заббикса между мускулем и постгрес довольно большая.

Лжёшь, собака! ©

housekeeper - оставить. По моему опыту, с такими настройками он работает вполне пристойно и не деградирует со временем:

[x] Переопределить период хранения истории элементов данных
[x] Переопределить период хранения динамики изменения элементов данных

Также помогает скручивание интервала опроса у наиболее используемых item'ов. Если там стоит, например, 30 секунд - подумать надо ли оно настолько часто, или 2-3-5 минут вполне хватит.

При InnoDB с опцией innodb_file_per_table файлы партиций будут в виде отдельных файлов.

-rw-rw---- 1 mysql mysql 3317694464 июл 11 00:00 history_uint#P#p2017_07_10.ibd
-rw-rw---- 1 mysql mysql 3326083072 июл 12 00:00 history_uint#P#p2017_07_11.ibd
-rw-rw---- 1 mysql mysql 3326083072 июл 13 00:00 history_uint#P#p2017_07_12.ibd
-rw-rw---- 1 mysql mysql 3321888768 июл 14 00:00 history_uint#P#p2017_07_13.ibd
-rw-rw---- 1 mysql mysql 3330277376 июл 15 00:00 history_uint#P#p2017_07_14.ibd
-rw-rw---- 1 mysql mysql 3326083072 июл 16 00:00 history_uint#P#p2017_07_15.ibd
-rw-rw---- 1 mysql mysql 3317694464 июл 17 00:00 history_uint#P#p2017_07_16.ibd
-rw-rw---- 1 mysql mysql 1283457024 июл 17 08:03 history_uint#P#p2017_07_17.ibd
-rw-rw---- 1 mysql mysql     114688 июл 17 04:01 history_uint#P#p2017_07_18.ibd

О. 3 гига uint в сутки. Неплохо, редко вижу такие конфигурации. Не членомерства ради, а солидарности для:

-rw-rw---- 1 mysql mysql 167772160 Jul 17 04:56 history_uint_P_p20170716_SP_p20170716sp0_key_cidx_clock_itemid_b9e69f1c_2_1d.tokudb
-rw-rw---- 1 mysql mysql 218103808 Jul 17 18:42 history_uint_P_p20170716_SP_p20170716sp0_key_cidx_itemid_clock_b9e69f1c_3_1d.tokudb
-rw-rw---- 1 mysql mysql 150994944 Jul 17 00:02 history_uint_P_p20170716_SP_p20170716sp0_main_b9e69f1c_4_1d.tokudb
-rw-rw---- 1 mysql mysql 167772160 Jul 17 04:57 history_uint_P_p20170716_SP_p20170716sp1_key_cidx_clock_itemid_b9e69f1d_2_1d.tokudb
-rw-rw---- 1 mysql mysql 234881024 Jul 17 18:43 history_uint_P_p20170716_SP_p20170716sp1_key_cidx_itemid_clock_b9e69f1d_3_1d.tokudb
-rw-rw---- 1 mysql mysql 150994944 Jul 17 00:02 history_uint_P_p20170716_SP_p20170716sp1_main_b9e69f1d_4_1d.tokudb
-rw-rw---- 1 mysql mysql 150994944 Jul 17 04:58 history_uint_P_p20170716_SP_p20170716sp2_key_cidx_clock_itemid_b9e69f1e_2_1d.tokudb
-rw-rw---- 1 mysql mysql 234881024 Jul 17 18:44 history_uint_P_p20170716_SP_p20170716sp2_key_cidx_itemid_clock_b9e69f1e_3_1d.tokudb
-rw-rw---- 1 mysql mysql 150994944 Jul 17 00:02 history_uint_P_p20170716_SP_p20170716sp2_main_b9e69f1e_4_1d.tokudb
-rw-rw---- 1 mysql mysql 150994944 Jul 17 04:59 history_uint_P_p20170716_SP_p20170716sp3_key_cidx_clock_itemid_b9e69f1f_2_1d.tokudb
-rw-rw---- 1 mysql mysql 234881024 Jul 17 18:45 history_uint_P_p20170716_SP_p20170716sp3_key_cidx_itemid_clock_b9e69f1f_3_1d.tokudb
-rw-rw---- 1 mysql mysql 150994944 Jul 17 00:02 history_uint_P_p20170716_SP_p20170716sp3_main_b9e69f1f_4_1d.tokudb
-rw-rw---- 1 mysql mysql 167772160 Jul 17 05:00 history_uint_P_p20170716_SP_p20170716sp4_key_cidx_clock_itemid_b9e69f20_2_1d.tokudb
-rw-rw---- 1 mysql mysql 234881024 Jul 17 18:46 history_uint_P_p20170716_SP_p20170716sp4_key_cidx_itemid_clock_b9e69f20_3_1d.tokudb
-rw-rw---- 1 mysql mysql 150994944 Jul 17 00:02 history_uint_P_p20170716_SP_p20170716sp4_main_b9e69f20_4_1d.tokudb
-rw-rw---- 1 mysql mysql 150994944 Jul 17 05:01 history_uint_P_p20170716_SP_p20170716sp5_key_cidx_clock_itemid_b9e69f21_2_1d.tokudb
-rw-rw---- 1 mysql mysql 218103808 Jul 17 18:47 history_uint_P_p20170716_SP_p20170716sp5_key_cidx_itemid_clock_b9e69f21_3_1d.tokudb
-rw-rw---- 1 mysql mysql 150994944 Jul 17 00:02 history_uint_P_p20170716_SP_p20170716sp5_main_b9e69f21_4_1d.tokudb
-rw-rw---- 1 mysql mysql 150994944 Jul 17 03:50 history_uint_P_p20170716_SP_p20170716sp6_key_cidx_clock_itemid_b9e69f22_2_1d.tokudb
-rw-rw---- 1 mysql mysql 218103808 Jul 17 18:48 history_uint_P_p20170716_SP_p20170716sp6_key_cidx_itemid_clock_b9e69f22_3_1d.tokudb
-rw-rw---- 1 mysql mysql 150994944 Jul 17 00:02 history_uint_P_p20170716_SP_p20170716sp6_main_b9e69f22_4_1d.tokudb
-rw-rw---- 1 mysql mysql 150994944 Jul 17 03:51 history_uint_P_p20170716_SP_p20170716sp7_key_cidx_clock_itemid_b9e69f23_2_1d.tokudb
-rw-rw---- 1 mysql mysql 234881024 Jul 17 18:48 history_uint_P_p20170716_SP_p20170716sp7_key_cidx_itemid_clock_b9e69f23_3_1d.tokudb
-rw-rw---- 1 mysql mysql 150994944 Jul 17 00:02 history_uint_P_p20170716_SP_p20170716sp7_main_b9e69f23_4_1d.tokudb

housekeeper - оставить. По моему опыту, с такими настройками он работает вполне пристойно и не деградирует со временем:

Такому твоему опыту я не верю - у меня свой есть ;)

Прочитай следующие два предложения.

Включил innodb_file_per_table. Перезапустил mysql, убедился что global variable сохранился

Перевёл БД zabbix на движок innodb

Экспортировал всё, дропнул бд zabbix, удалил разросшийся ibdata ( при остановленном mysql ), импортировал данные БД zabbix обратно

Нагрузка на диск осталась той же ( ~ 50 write iops, почти без чтения ), но теперь удаление старых партиций освобождает место на диске

Попробуй постгрес. Разница в производительности заббикса между мускулем и постгрес довольно большая.

Через пару месяцев попробую. Пока мне с запасом хватает mysql ( даже без тюнинга ) - основные тормоза у меня на стороне powershell скрипта, который заливает данные через zabbix_sender

ls -alh | grep history_uint | grep 2017_07 | awk '{ print $5, $9 }'

28G history_uint#P#p2017_07_01.ibd 29G history_uint#P#p2017_07_02.ibd 28G history_uint#P#p2017_07_03.ibd 40G history_uint#P#p2017_07_04.ibd

При таких объемах только партиционирование, домохозяйку расстрелять .

P.S. MariaDB

28G в сутки, серьёзно...

Домохозяйку - да, факт :) То, как оно там «из коробки» сделано, вообще критики не выдерживает.

Могу ещё посоветовать TokuDB/LZMA для хисторей, оно его подсожмёт раз в 5-7, обменивая снижение размера и дисковой активности на ресурсы CPU. Со стабильностью проблем не возникало. Единственный момент - не забыть задать достаточный размер буфера для TokuDB.

Тем более, что TokuDB как раз оптимизирован для таблиц с непрерывным аппендом.

основные тормоза у меня на стороне powershell скрипта

Как с этим справились?