Помогите пожалуйста разобраться с базой

[vanishox]

1. Есть zabbix 1.8 + база на postgresql.
2. Мониторим 3000 девайсов ~ 25 000 интерфейсов.
3. Столкнулись с проблемой - база разрослась до 400 Гбайт за 1 год.
4. Вследствии этого часть запросов sql просто не обрабатывается.
5. Как следствие - перестает работать часть веб интерфейса, не отображаются графики, очередь и т.д.
6. Что можно сделать в данной ситуации?

7. Также есть вопрос по самой базе - подскажите пожалуйста из каких таблиц можно вытащить узлы, на которых в данный момент наблюдается проблема?

Поясню: Необходимо раз в 5 мин делать выборку ip адресов оборудования, на котором наблюдается авария (сработали определенные триггеры) и перекладывать в другую базу, на другом сервере.

[Gray]

Тут написано кой-ч

http://www.zabbix.com/forum/showthread.php?t=9925

вот моя тема

http://www.zabbix.com/forum/showthread.php?t=24814

для себя решил пока переходом больших таблиц(history, trends) на MyISAM и еженочный mysql optimize(InnoDB не будет при optimize уменьшать размер файлов...). Работает годно, но у меня объём не большой(7000 итемов) и не сервер, а так писюк лишний.

[vanishox]

Мда, нашел тройку лидеров:
history_uint - 230 Gb
history - 60 Gb
trends_uint - 50 Gb

Вопрос, что теперь с ними можно сделать?

vacuum [full] analyze - (оптимизатор) не помогает, запустил сутки назад, поначалу процесс хоть цпу жрал с памятью, под утро все - 0%.
reindex - такая же ситуация.

Что за данные хранятся в этих таблицах?
Можно ли дропнуть таблицу и создать заново? Чем это чревато?

[vanishox]

Хотелось бы на данном этапе хоть как-то срезать их размер, чтобы потом настроить vacuum и reindex периодически обрабатывать эти таблицы.

[Gray]

Что за данные хранятся в этих таблицах?
Можно ли дропнуть таблицу и создать заново? Чем это чревато?

Собственно собираемые данные и хранятся, дропнешь - не бует графиков, истории... history* это сами данные как есть, trends* это усреднённые старые данные. Причём из-за постоянного удаления старых данных и добавдления новых большая часть занимаего этими файлами места по сути пустое, мусор.

Хотелось бы на данном этапе хоть как-то срезать их размер, чтобы потом настроить vacuum и reindex периодически обрабатывать эти таблицы.

дамп, дроб дб, проверить что файлы причинных таблиц точно потёрты, востановление дампа. размер файлов станет чётко под размер данных, но эт временно. нужно как-то решать проблему housekeeping vs innodb tablespace

[SergeniuS]

дамп, дроб дб, проверить что файлы причинных таблиц точно потёрты, востановление дампа. размер файлов станет чётко под размер данных, но эт временно. нужно как-то решать проблему housekeeping vs innodb tablespace

Если создать дамп, удалить базу, а потом восстановить, то размер станет актуальным. Только причём тут innodb в СУБД PostgreSQL?

[Gray]

Если создать дамп, удалить базу, а потом восстановить, то размер станет актуальным. Только причём тут innodb в СУБД PostgreSQL?

простите был не внимателен.
но суть на самом деле та же, для посгреса периодически делайте vacuum

[vanishox]

Всем спасибо за советы.
Удалось разобраться с тройкой лидеров.
1. Грохнул - восстановил базу - их размеры уменьшились где-то до половины.
2. Ручками вычистил данные - оставил только с 2012-01-01.
3. После этого бэкап таблиц с последующим рестором - уменьшило их еще в 10 - 11 раз. Теперь графики рисуются и заббикс летает по сравнению с тем, что было.
4. Слежу за размерами таблиц, делаю каждодневно VACUUM ANALYZE - посмотрю поможет ли это как-то сдержать рост таблиц.
5. Странно, но когда при размере 115 Гб (до дроп и рестора таблиц) запустил VACUUM FULL ANALYZE - размер таблицы так и остался 115 Гб, хотя почитал - люди пишут, что таблица должна уменьшится в размере и занять только размер под актуальные данные.
6. Есть идея периодически запускать скрипт, который чистит вручную все данные и оставляет только за месяц- два, может в связке с VACUUM поможет сдержать рост табличек, а то все танцы с бубнами над ними продлились 2 дня, пришлось тушить сервак на это время.
7. Не поможет - буду мучать разбиение таблиц.

Теперь вопрос:

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

[turboon]

Да, именно в таблице triggers они и хранятся
Значение value = 1 - означает включенный триггер.

[vanishox]

Похоже я не так выразился, мне нужны не все активные триггеры, а все "сработавшие" триггеры, то есть по которым появилось состояние "ПРОБЛЕМА".

[Horror777]

А вот это кажется уже таблица events

[OKyHb]

7. Не поможет - буду мучать разбиение таблиц.

У нас MySQL, но именно партицирование таблиц и отключение housekeeper'a решило наши проблемы с производительностью. 186G трендов за 8 месяцев - и никакого негативного эффекта для базы или веб интерфейса.

[vanishox]

Я тоже скорее всего перейду на партиционирование.
Откопал запрос, который дергает все "проблемные" интерфейсы (может кому-нибудь пригодится):

SELECT  DISTINCT   h.host, t.description, t.status, t.value, t.priority, '1970-01-01'::timestamp + ((t.lastchange::integer)::text)::interval, t.comments
 FROM triggers t,functions f,items i,hosts_groups hg,rights r,users_groups ug, hosts h 
WHERE ((t.triggerid  BETWEEN 000000000000000 AND 099999999999999)) 
 AND f.triggerid=t.triggerid 
 AND f.itemid=i.itemid 
 AND i.hostid=h.hostid
 AND hg.hostid=i.hostid 
 AND r.id=hg.groupid  
 AND r.groupid=ug.usrgrpid 
 AND ug.userid=19 
 AND r.permission>=2 
 AND NOT EXISTS(  
		SELECT ff.triggerid  
		 FROM functions ff, items ii  
		WHERE ff.triggerid=t.triggerid  
			AND ff.itemid=ii.itemid  
			AND EXISTS(  
				   SELECT hgg.groupid  
				    FROM hosts_groups hgg, rights rr, users_groups gg  
 				   WHERE hgg.hostid=ii.hostid  
					AND rr.id=hgg.groupid  
					AND rr.groupid=gg.usrgrpid  
					AND gg.userid=19 
					AND rr.permission<2
				  )
		) 
 AND  NOT EXISTS ( 
		  SELECT ff.functionid 
		   FROM functions ff 
  		  WHERE ff.triggerid=t.triggerid 
			AND EXISTS ( 
				    SELECT ii.itemid 
					FROM items ii, hosts hh 
				    WHERE ff.itemid=ii.itemid 
					AND hh.hostid=ii.hostid 
					AND ( ii.status<>0 OR hh.status<>0 )
				   ) 
		 ) 
 AND t.status=0 
 AND (  (t.value IN (1))  ) 

ORDER BY t.priority DESC

Возник другой вопрос - нужно дернуть ссылку на карту, в которой находится определенный узел сети.

Допустим есть у нас коммутатор 172.20.0.1 - нужно выдернуть ссылку на карту, в которой он находится.

Кто-нибудь подобное делал?

[Horror777]

SELECT sysmapid FROM sysmaps_elements WHERE  elementid = '$hostid' limit 1

<meta http-equiv='refresh'; content='0; url=http://localhost/zabbix/maps.php?sysmapid=$sysmapid >

[vanishox]

Horror777

Спасибо!