Ad Widget

**sire** · 31-08-2011, 13:51

Originally posted by novoselov.ai

Да, тоже самое - только сервер не перезапускался. И вроде всё работает. Сегодня понаблюдаю.

Как себя чувствует сервер?

**novoselov.ai** · 31-08-2011, 19:06

Originally posted by sire

Как себя чувствует сервер?

Code:

[SIZE="2"]2088:20110830:235949.928 SNMP Host [135.81-1228]: first network error, wait for 15 seconds
NOTICE:  ALTER TABLE / ADD PRIMARY KEY will create implicit index "partitions_history_text_2011_08_31_pkey" for table "history_text_2011_08_31"
CONTEXT:  SQL statement "alter table partitions.history_text_2011_08_31 add constraint partitions_history_text_2011_08_31_pkey PRIMARY KEY (id)"
PL/pgSQL function "copy_constraints" line 13 at EXECUTE statement
PL/pgSQL function "copy_constraints" line 2 at RETURN
SQL statement "SELECT  copy_constraints( $1 ,  $2 )"
PL/pgSQL function "partition_every_day" line 60 at PERFORM
SQL statement "SELECT  partition_every_day ( $1 , 'partitions.',  $2 )"
PL/pgSQL function "trig_part_day" line 2 at PERFORM
  2069:20110831:000004.181 SNMP Host [139.80-3528]: first network error, wait for 15 seconds[/SIZE]

Не смотря на дедлоки продолжает работать - сегодня не было дедлока.

**sire** · 01-09-2011, 14:10

Originally posted by novoselov.ai

Не смотря на дедлоки продолжает работать - сегодня не было дедлока.

У меня тоже дедлоки не повторялись.

**vladimir_omsk** · 30-10-2011, 17:27

Чтото у меня не заладилось с партицированием

Постгрес долго считает запросы типа:
select value from history_uint where itemid=29430 and clock<=1319907210 order by itemid,clock desc limit 5;

Code:

QUERY PLAN
 Limit  (cost=140086.14..140086.15 rows=4 width=30) (actual time=148061.150..148061.170 rows=4 loops=1)
   ->  Sort  (cost=140086.14..140234.40 rows=59302 width=30) (actual time=148061.146..148061.156 rows=4 loops=1)
         Sort Key: public.history_uint.clock
         Sort Method:  top-N heapsort  Memory: 17kB
         ->  Result  (cost=0.00..139196.61 rows=59302 width=30) (actual time=116.489..148036.739 rows=7599 loops=1)
               ->  Append  (cost=0.00..139196.61 rows=59302 width=30) (actual time=116.486..148010.274 rows=7599 loops=1)
                     ->  Index Scan using history_uint_1 on history_uint  (cost=0.00..8.27 rows=1 width=18) (actual time=0.040..0.040 rows=0 loops=1)
                           Index Cond: ((itemid = 29430) AND (clock <= 1319907210))
                     ->  Bitmap Heap Scan on history_uint_2011_10_24 history_uint  (cost=187.07..12801.43 rows=5273 width=30) (actual time=116.441..14994.848 rows=757 loops=1)
                           Recheck Cond: ((itemid = 29430) AND (clock <= 1319907210))
                           ->  Bitmap Index Scan on partitions_history_uint_2011_10_24_1  (cost=0.00..185.76 rows=5273 width=0) (actual time=116.263..116.263 rows=757 loops=1)
                                 Index Cond: ((itemid = 29430) AND (clock <= 1319907210))
                     ->  Bitmap Heap Scan on history_uint_2011_10_25 history_uint  (cost=386.26..26379.80 rows=11358 width=30) (actual time=316.088..30883.383 rows=1440 loops=1)
                           Recheck Cond: ((itemid = 29430) AND (clock <= 1319907210))
                           ->  Bitmap Index Scan on partitions_history_uint_2011_10_25_1  (cost=0.00..383.42 rows=11358 width=0) (actual time=286.401..286.401 rows=1440 loops=1)
                                 Index Cond: ((itemid = 29430) AND (clock <= 1319907210))
                     ->  Bitmap Heap Scan on history_uint_2011_10_26 history_uint  (cost=387.41..26634.42 rows=11469 width=30) (actual time=214.775..29137.962 rows=1440 loops=1)
                           Recheck Cond: ((itemid = 29430) AND (clock <= 1319907210))
                           ->  Bitmap Index Scan on partitions_history_uint_2011_10_26_1  (cost=0.00..384.54 rows=11469 width=0) (actual time=214.325..214.325 rows=1440 loops=1)
                                 Index Cond: ((itemid = 29430) AND (clock <= 1319907210))
                     ->  Bitmap Heap Scan on history_uint_2011_10_27 history_uint  (cost=381.79..26273.17 rows=11313 width=30) (actual time=349.761..33227.081 rows=1440 loops=1)
                           Recheck Cond: ((itemid = 29430) AND (clock <= 1319907210))
                           ->  Bitmap Index Scan on partitions_history_uint_2011_10_27_1  (cost=0.00..378.96 rows=11313 width=0) (actual time=316.198..316.198 rows=1440 loops=1)
                                 Index Cond: ((itemid = 29430) AND (clock <= 1319907210))
                     ->  Bitmap Heap Scan on history_uint_2011_10_28 history_uint  (cost=386.33..26394.51 rows=11365 width=30) (actual time=334.549..21986.800 rows=1440 loops=1)
                           Recheck Cond: ((itemid = 29430) AND (clock <= 1319907210))
                           ->  Bitmap Index Scan on partitions_history_uint_2011_10_28_1  (cost=0.00..383.49 rows=11365 width=0) (actual time=295.244..295.244 rows=1440 loops=1)
                                 Index Cond: ((itemid = 29430) AND (clock <= 1319907210))
                     ->  Bitmap Heap Scan on history_uint_2011_10_29 history_uint  (cost=316.96..20705.01 rows=8523 width=30) (actual time=158.083..17755.053 rows=1082 loops=1)
                           Recheck Cond: ((itemid = 29430) AND (clock <= 1319907210))
                           ->  Bitmap Index Scan on partitions_history_uint_2011_10_29_1  (cost=0.00..314.83 rows=8523 width=0) (actual time=142.393..142.393 rows=1084 loops=1)
                                 Index Cond: ((itemid = 29430) AND (clock <= 1319907210))
 Total runtime: 148061.300 ms
(33 rows)

Получается, постгрес отрабатывает каждую партицию на условие where, потом делает ORDER BY и LIMIT. Если подневных партиций будет на несколько месяцев, то ох как ему взгрустнется...
Размер дневных табличек ~1млн+ записей.
Как напинать постгрес делать ORDER BY и LIMIT прежде, чем переходить к следующей партиции ?
PS. PostgreSQL 8.4.4, Zabbix 1.8.8.
PPS: И мне кажется, в функциях для партиций на неделю и далее надо бы поправить на

Code:

    -- интервалы для constraint check
    check_beg = extract(epoch FROM date_trunc('week', to_timestamp(clock)));
    check_end =  extract(epoch FROM date_trunc('week', to_timestamp(clock) + interval '1 week'));

Code:

    -- условие для проверки
    check_condition =
    '(
       ' || check_field || ' >= ' || quote_literal (check_beg) || ' and
       ' || check_field || ' < ' || quote_literal (check_end) || '
     )';

Или не надо ?

**vladimir_omsk** · 31-10-2011, 08:41

Originally posted by vladimir_omsk

Как напинать постгрес делать ORDER BY и LIMIT прежде, чем переходить к следующей партиции ?
PS. PostgreSQL 8.4.4

Разобрался, 8.4 никак, надо обновляться в 9.1.

Code:

E.2. Release 9.1
E.2.3.1.2. Optimizer
    Allow inheritance table scans to return meaningfully-sorted results (Greg Stark, Hans-Jurgen Schonig, Robert Haas, Tom Lane)
    This allows better optimization of queries that use ORDER BY, LIMIT, or MIN/MAX with inherited tables.

**zalex_ua** · 03-11-2011, 22:09

Originally posted by vladimir_omsk

Чтото у меня не заладилось с партицированием

Постгрес долго считает запросы типа:
select value from history_uint where itemid=29430 and clock<=1319907210 order by itemid,clock desc limit 5;

Code:

Index: src/libs/zbxdbhigh/db.c
===================================================================
--- src/libs/zbxdbhigh/db.c	(revision 22074)
+++ src/libs/zbxdbhigh/db.c	(working copy)
@@ -2013,7 +2013,12 @@
 	if (0 != clock_from)
 		offset += zbx_snprintf(sql + offset, sizeof(sql) - offset, " and clock>%d", clock_from);
 	if (0 != clock_to)
-		offset += zbx_snprintf(sql + offset, sizeof(sql) - offset, " and clock<=%d", clock_to);
+	{
+		if (0 != last_n)
+			offset += zbx_snprintf(sql + offset, sizeof(sql) - offset, " and clock between %d and %d", clock_to - 86400, clock_to);
+		else
+			offset += zbx_snprintf(sql + offset, sizeof(sql) - offset, " and clock<=%d", clock_to);
+	}
 
 	if (0 != last_n)
 	{

Этот патч улучшает работу четырех функций: MIN MAX AVG SUM если в качестве параметра функции вызывается количество значений (#3) а не период времени (180)
Но имейте ввиду что в патче интервал времени для запрашиваемого количества значений истории ограничен одними сутками (86400 секунд), то есть интервал обновления ваших айтемов * параметр функции триггера не должен быть больше 24*3600

**zalex_ua** · 11-11-2011, 18:45

Originally posted by vladimir_omsk

Разобрался, 8.4 никак, надо обновляться в 9.1.

Code:

e.2. Release 9.1
e.2.3.1.2. Optimizer
    allow inheritance table scans to return meaningfully-sorted results (greg stark, hans-jurgen schonig, robert haas, tom lane)
    this allows better optimization of queries that use order by, limit, or min/max with inherited tables.

Владимир, есть ли у Вас какие либо новости по тестированию версии 9.1?

**vladimir_omsk** · 14-11-2011, 05:49

Переезал на PostgreSQL 9.1.1.

1) Чтобы заработал метод Merge Append, потребовалось создать отдельный индекс на поле clock (парный индекс заббикса на itemid,clock кушать не захотел)
2) после накопления четырех-пяти партиций заметил увеличение загрузки CPU постргесом (до 30-40% от ядра на каждый процесс, было до этого <10%) - после патча, выложенного zalex_ua (спасибо большое, кстати) загрузка вернулась на штатный уровень.
3) план:

Code:

EXPLAIN ANALYZE  select value from history_uint where itemid=32332 and clock<=1321290000 order by clock desc limit 5;
 Limit  (cost=0.32..3586.18 rows=5 width=24) (actual time=4.148..10.199 rows=5 loops=1)
   ->  Result  (cost=0.32..93793905.88 rows=130783 width=24) (actual time=4.142..10.179 rows=5 loops=1)
         ->  Merge Append  (cost=0.32..93793905.88 rows=130783 width=24) (actual time=4.139..10.164 rows=5 loops=1)
               Sort Key: public.history_uint.clock
               ->  Index Scan Backward using history_uint_clock on history_uint  (cost=0.00..38.15 rows=1 width=8) (actual time=0.166..0.166 rows=1 loops=1)
                     Index Cond: (clock <= 1321290000)
                     Filter: (itemid = 32332)
               ->  Index Scan Backward using partitions_history_uint_clock_2011_10_31 on history_uint_2011_10_31 history_uint  (cost=0.00..3178742.88 rows=4443 width=24) (actual time=0.094..0.094 rows=1 loops=1)
                     Index Cond: (clock <= 1321290000)
                     Filter: (itemid = 32332)
               ->  Index Scan Backward using partitions_history_uint_clock_2011_11_01 on history_uint_2011_11_01 history_uint  (cost=0.00..8174690.32 rows=11403 width=24) (actual time=0.186..0.186 rows=1 loops=1)
                     Index Cond: (clock <= 1321290000)
                     Filter: (itemid = 32332)
               ->  Index Scan Backward using
...и так все партиции до последней
               ->  Index Scan Backward using partitions_history_uint_2011_11_14_clock on history_uint_2011_11_14 history_uint  (cost=0.00..2809937.81 rows=3924 width=24) (actual time=1.688..7.699 rows=5 loops=1)
                     Index Cond: (clock <= 1321290000)
                     Filter: (itemid = 32332)
  Total runtime: 10.343 ms

Доверия тоже не внушает, тк всеравно подключает все партиции...

Ну и поймал пару дедлоков, пока не ковырялся с чем их едят, лечил перезапуском заббикс-сервера.

**zalex_ua** · 28-04-2012, 16:23

По идее эта проблема решена вот здесь https://support.zabbix.com/browse/ZBX-4881 начиная с версии 1.8.13

**dmitryalexeeff** · 04-05-2012, 07:14

Предложение

----------

**nightwitch** · 05-05-2012, 07:00

тестировался Zabbix 1.8.12/Postgres 9.1.1

Работает прекрасно, проблем замечено не было.
+ использовался патч от zalex_ua
Ищет только по нужной партиции.

**Alexei** · 05-05-2012, 18:53

Originally posted by dmitryalexeeff

Может вместо нативных хранимых процедур сделать пакет внешних утилит для настройки и обслуживания партиционирования?
Единый так сказать логический интерфейс для всех СУБД.

Очень вероятно, что это будет релизовано в одной из будущих версий, но не в 2.0.x.

**crypt** · 12-05-2012, 08:18

Originally posted by dotneft

Написал небольшой мануал (еще в процессе) для партиционирования в PostgreSQL:

http://www.zabbix.com/wiki/non-engli..._in_postgresql

Хотелось бы услышать замечания, улучшения.... ну вообщем всё что считаете нужным высказать

После эксплуатации Zabbix (600 items/sec) в конфигурации с партиционированием Postgres, появились некоторые соображения и замечания по поводу предложенной схемы. Коротко опубликовал их в блоге (english):

http://crypt47.bl0gspot.com/2012/05/partitioning-of-zabbix-database.html

p.s.
ссылки запрещены, так что вот в таком вот виде.

Нужно заменить ноль в bl0g на "o".

**sire** · 12-05-2012, 08:29

Приветствую, crypt!

В болге Вы пишете "2. Более не потребуется использование “housekeeper”. Эту функцию самоотчистки базы данных от устаревших данных истории и тенденций можно отключить в файле конфигурации Zabbix сервера." А что происходит с удалёнными элементами данных (items), узлами сети, шаблонами и прочими данными, которые хранятся в непартиционированных таблицах?

Прошу прощения, невнимательно прочитал сообщение. Переадресую свой вопрос dotneftу.

**zalex_ua** · 12-05-2012, 11:01

Originally posted by sire

А что происходит с удалёнными элементами данных (items), узлами сети, шаблонами и прочими данными, которые хранятся в непартиционированных таблицах?

Они удаляются в момент удаления из фронтенда

Наверное вопрос был не совсем корректен, сорри.

Кстати, одна из таблиц которая теряет смысл своего содержимого это housekeeper при отключении хаускипера.
Она используется хаускипером для контроля удаления присутствующей истории УЖЕ удаленных айтемов. В схема с партишинингом эта таблица будет содержать определенные данные, которые никак не будут использоваться, количесво записей будет медленно расти по мере изменений конфигурации (удалении айтемов).
При обычном функционировании (с хаускипером) эта таблица большинство времени пуста, и только иногда там на некоторое время появляются данные.

Ad Widget

Партиционирование в PostgreSQL

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment