Zabbix - optymalizacja pod kątem wydajności

Wydajność IO daje się we znaki

Na razie wszystkie instalacje które wykorzystuje pracują na bazie MySQL.
Możliwe że w przypadku zastosowania innej bazy takie problemy nie występują.

W większych instalacjach zdarzyły mi się problemy dotyczące housekeeper-a który zaczął wykonywać za dużo operacji IO na dysku. Do pewnego momentu próbowałem modyfikować parametry mysql-a jednak nie dawało to sensownych rezultatów.

Podjąłem dlatego próbę zmniejszania częstości pytania itemów.
Do pewnego momentu robiłem to z poziomu interface, jednak poddałem się i zacząłem modyfikować dane z poziomu sql-a.

Przyjąłem założenie aby nie definiować itemów które maja duże history. Domyślnie zabbix zakłada itemy które maja history = 90 dni. Sprawdzona optymalna wartość to 7 dni.

Może to nie jest jedyny sposób optymalizacji, możliwe że trzeba zabrać się za partycjonowanie tabel jak w jednym z linków. Poniższy przykład może być jednak pomocny do diagnostyki skali problemu.

Przydatne SQL

Poniżej zebrałem parę zapytań, które się bardzo przydają:

Sprawdzenie items pod kątem częstości odświeżania
  select delay,type from items group by delay,type;

Wielkość tabeli z historia
  show table status like 'history';

Badanie wilkości tabelek o nazwie jak maska '%history%'
  SELECT table_rows, table_name AS "Table",  
  round(((data_length + index_length) / 1024 / 1024), 2) "Size in MB"  
  FROM information_schema.TABLES  WHERE table_schema = "zabbix" and

  table_name like '%history%';

Sprawdzenie które itemy maja największą ilość wpisów historii
  select itemid, count(itemid) from history group by itemid order by count(itemid);

Usuwanie starej historii itemów od daty (dane podać w formacie timestamp unix)
  delete from history where itemid in(xxx,xxx,xxx) and clock<1380585600;

Usuwanie historri po kawałku
  delete FROM history  where clock < UNIX_TIMESTAMP(date_sub(current_timestamp, 
  interval 7 day)) limit 1000000;

  delete from history_uint where clock<UNIX_TIMESTAMP(date_sub(current_timestamp, 
  interval 4 day)) limit 1000000;

Sprawdzenie które itemy mają historię dłuższą niż 7 dni (w definicji)
  select itemid, name, key_ from items where history > 7;

Liczba itemow w tysiacach
  select count(cnt), cnt from (select round(count(itemid)/1000) cnt 
  from history_uint group by itemid) a group by cnt;

Operacje na datach w tabelkach z historią

Data w formacie unix
  FROM_UNIXTIME()

  select FROM_UNIXTIME(clock) from history order by itemid desc limit 10;

Godzina (data) o 7 dni wcześniej
  date_sub(current_timestamp, interval 7 day) 

Konwersja na date w formacie unix timestamp
  UNIX_TIMESTAMP()

  select UNIX_TIMESTAMP(date_sub(current_timestamp, interval 7 day));

Sprawdzenie ile jest rekordów historii starszej niż 3 dni
  select count(*) from history where
  clock<UNIX_TIMESTAMP(date_sub(current_timestamp, interval 3 day));

  select count(*) from history_uint where
  clock<UNIX_TIMESTAMP(date_sub(current_timestamp, interval 3 day));

Indexy

Sprawdzenie indexow dla tabelki
  SHOW INDEX FROM history_uint;

Opis tabel

Niektóre rzeczy dobrze mieć pod ręką.

Database tables for history/trends and theirs item type:

• history – numeric (float)
• history_uint – numeric (unsigned integers)
• history_str – character (up to 255 bytes)
• history_log – log
• history_text – text
• trends – numeric (float)
• trends_uint – numeric (unsigned integers)

Notatnik

Parsowanie zapytania

  QueryHandler .handleQuery

  JMXHelper

Linki

http://zabbixzone.com/zabbix/history-and-trends/, http://zabbixzone.com/zabbix/partitioning-tables/