Problem with adding a new trigger to an existing template

[moshe]

Hi,
We have a system with lots of items and devices as you can see in the attached picture.

Because of the amount of devices and items we are unable to add a new trigger for exist templet (ICMP ping templet).
I create a new trigger on existing template, set all parameter and press ADD button after this I gets a blank white screen, and nothing happens.
I don't get confirmation of the action (at the top of the screen with a green V).

I also tried through the API and still failed.

Would love your help.

[kloczek]

Hi,
We have a system with lots of items and devices as you can see in the attached picture.

Because of the amount of devices and items we are unable to add a new trigger for exist templet (ICMP ping templet).
I create a new trigger on existing template, set all parameter and press ADD button after this I gets a blank white screen, and nothing happens.
I don't get confirmation of the action (at the top of the screen with a green V).

If you are using MySQL DB backend add to my.cnf "transaction-isolation = READ-COMMITTED".
That single option is one of the biggest advantages of the MySQL over PostgreSQL in large scale zabbix stacks.
Other thing is that not to many people are aware that to modify something in any database first you need to read something so low latency read operations with high hits/misses ratio from database cache is crucial on making such modification enough fast. If you see that during such modifications you have way more read IOs on DB backend that is symptom of not have enough RAM to cache tables content related to the configuration.

[moshe]

Thanks for you answer
I will try to add transaction-isolation = READ-COMMITTED to my my.cnf file and check behaviour.
You suggest to change cache size too ?

[kloczek]

Thanks for you answer
I will try to add transaction-isolation = READ-COMMITTED to my my.cnf file and check behaviour.
You suggest to change cache size too ?

If you are using daily created history* tables partitions usually you should have RAM around sum of those daily created partitions to allow at least keep in VFS cache content of those files to allow operate on in-RAM cached data. If you have veeery big env an you are forced to use every 12h, 6h, 4h or smaller partitions that RAM size still will be at least size of last history* tables partitions.
Not all history* tables data are critical however usually that size of RAM allows to cover as well mass triggers updates/add/delete operations as well.

If you have triggers definitions which are trying to evaluate frequently data older than one day more RAM may be needed. Exact GoodEnough(tm) RAM size may depend on other factors but usually what I've described here Works(tm).

transaction-isolation=READ-COMMITTED allows read data from database to evaluate new monitoring data against triggers or display graphs during mass monitoring configuration changes so during those operations new data coming from monitored hosts/proxies should be digested and other people should be able to see graphs, triggers, alarms.
If some template changes may take longer you need to increase php.ini timeouts. If those timeouts will be not enough long php will be killing SQL insert/update/delete queries applying those templates changes across all hosts.

[moshe]

Thank you, the action helped and improved performance by 10%.
I was able to solve the problem myself. I turned off DEBUG MODE.
And now it was performed correctly.