> Да неужто? Валить все данные в одну (две - хистори и тренд)
> таблицу это более типовое использование?А-ага. для 3-4-20 хостов и sqlite-а -- самое то.
Ну, и о себе:
4x history + 2x trends. +их индексы. => 99%+ бд. relname | size | size_b
trends_uint | 22 GB | 24 074 412 032
history | 17 GB | 17 982 316 544
history_1 | 13 GB | 14 055 489 536
history_uint | 11 GB | 12 208 955 392
history_uint_1 | 11 GB | 11 488 436 224
trends | 11 GB | 11 354 144 768
trends_uint_pkey | 10 GB | 10 905 575 424
trends_pkey | 4910 MB | 5 148 925 952
history_text | 918 MB | 962 666 496
alerts | 418 MB | 438 370 304
history_str | 326 MB | 341 729 280
history_text_pkey | 285 MB | 298 926 080
history_str_1 | 259 MB | 271 941 632
events | 233 MB | 244 039 680
> Как мне кажется, partitioning - один из основных, как по мне, залогов
> успеха в использовании zabbix'a. Можно, конечно, тратить деньги на SAS-винты (а
> они недешевы) и =усиление= остального железа. Но хотя бы помесячная разбивка
> history - почему бы и нет? Даже без partitioning, а просто
> - новый месяц - новая таблица? Мб, конечно, я что-то не
> понимаю в этом, тогда прошу просветить меня в этом вопросе.
Здесь history [в массе] 3 day(*) и сбор раз в минуту, trends 365d.
Все history - 54гига из 104~(**) -- "горячие", переписываются полностью (float/int по кр.мере; 51.9ГБ) каждые 3 дня... тормозят и фрагментируются...... . . . . . .....
housekeeper-ы, vacuum-ы, pg_repack-и -- ужос, ухос, ужос. А, да! thin lvm + fstrim!11
Работаем! //"А, чтобы попасть куда-нибудь, нужно бежать вдвое быстрее."
(*) какое там "новый месяц". И трендсы, месяца ч-з 3 после репака, - тоже тормозят.
(**) "из 104~" - репак неделю тому, .../base/ size был 93.7ГБ. NVPS="1.12 K", avg(1mnth) Да, тот самый кейс для партишенинга... Да... Обдумываю. Третий год! Но 8 шпинделей и 128ГБ озу -- много проще и :) "безопаснее".
