Houskeeping

[Colttt]

Hello,

must i use the "Houskeeper" and why? can i schedule it manually every night?
i dont find anything in the doxumentation.. http://www.zabbix.com/documentation

[untergeek]

There is no reason to use the housekeeper. That is, unless you want your database to continually grow and never be pruned of old data.

In your item definitions you put in a number of days to keep history and trends. The housekeeper reads these and prunes the history data older than these values. If you have a large zabbix database, however, this can be a lot of querying. Many of us have adapted other means of pruning old data, including the use of partitioned tables, to overcome this.

[Colttt]

ok.. thanks..
i think that's reason for my perfomance-problem..

If you have a large zabbix database, however, this can be a lot of querying.

what is large?

Many of us have adapted other means of pruning old data, including the use of partitioned tables, to overcome this.

and how?

[untergeek]

Perhaps the first thing to try would be to upgrade to 1.8.5

Next, with only 50 new values per second you're not adding a lot of new values. How many rows are in your history, history_uint, history_str, history_log and history_text tables?

Are you doing a lot of parsing of text data, e.g. log files, strings pulled, etc.? That can be very taxing on a database. Recently there have been other posts to the forums where CPU load to the database was a result of heavy log file data parsing in Zabbix.

With Postgres, that would mean you're doing "vacuum" or some such. I'm not as familiar with Postgres as I am with Oracle and MySQL, but you ought to check and see what's going on. In our own shop, we are going to partitioned tables. In the meanwhile, I took the same SQL used by the housekeeper and modified it to keep 7 days of text data and 30 days of numerical data across the board, rather than let Zabbix calculate it per item.

[Colttt]

hmm i would like to use the Debian-Reposity, and at the moment its only 1.8.2 in the stable repo..

i stored the values only 180days.. andi dont check logfiles or something like this, the only thing i parsed is an VMware-script.. nothing more.

i dont know how many rows i have in the history, i am not a SQL-genius

thanks a lot for help!

[untergeek]

Is that history for 180 days or trends for 180 days?

If history for 180 days, then yes, that could be a lot.

Try running SQL queries like this:

select count(*) from history;
select count(*) from history_uint;

You can put the other table names in if you need to. It sounds like you're mostly getting numbers, which are those two tables.

Debian is really far behind, as is usual with them, especially with the "stable" branch. You're far better off compiling your own Zabbix server code from source and keeping up to date that way.

[Colttt]

SQL_history: 62488694
more data you become on wedensday.. now i have closing time (Feierabend)

history is max 90days and the trends are max 180 days..

i hope that zabbix in a next major-version comes into the debian-backports..

[Colttt]

soo here are the values:
history: 65091869
history_uint: 18565762
history_str: 188483
history_log: 0
history_text: 0

but i think i´ve solved my performance-problem.. the "old" Documentaion v1.6 is the solution on Page 66

HousekkepingFrequency:
The parameter defines how often the daemon must perform housekeeping procedure (in hours). If PostgreSQL is used set the value to 24 as it will perform command VACUUM.

now i used 24 and it all works fine.. i wait for the next 24hours and ich hoffe das bleibt jetzt so

[Colttt]

soo now i can say i must disable Housekeeper.. its terrible yesterday i has a cpu-load over 15!

can i run housekeeper manualy? how did it other administrator? when the cpuload is high i dont become any value..

[Colttt]

has nobody an idea?

[Colttt]

ok, last push..

i need the sql-command from the houskeeper to run it manually

[untergeek]

Since Postgres uses vacuum, I'm not sure what the correct one is. I found the regular ones in the source code, though. Try grepping in there.