[ZBX-5640] Timeout deleting host with many items Created: 2012 Oct 01  Updated: 2024 Apr 10  Resolved: 2017 Sep 26

Status: Closed
Project: ZABBIX BUGS AND ISSUES
Component/s: Frontend (F)
Affects Version/s: 2.0.2
Fix Version/s: None

Type: Incident report Priority: Major
Reporter: Michael Schwartzkopff Assignee: Unassigned
Resolution: Won't fix Votes: 4
Labels: api, performance, slow, timeout
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

SLES 11 SP 1


Team: Team B
Team: Team B
Sprint: Sprint 17

 Description   

Hi,

I configured a template with low level discovery. A host now shows many (>4000) items. Now I want to delete that host again. Config -> Host -> Select host -> Delete selected -> Go.

Now the GUI shows a grey screen and nothing happens.

Clicking to Config -> Hosts after some time shows that the host is still there.

Unlink and clear of the specific Template also fails with timeout.

Michael.



 Comments   
Comment by Michael Schwartzkopff [ 2012 Oct 01 ]

Hi,

I solved the problem by

DELETE * FROM items WHERE hostid="...";

But that is definitely not user-friendly.

Comment by Oleksii Zagorskyi [ 2012 Oct 02 ]

This is very-very bad idea to delete anything manually from database.
Many objects in the DB are related.

Comment by Michael Schwartzkopff [ 2012 Oct 02 ]

Thanks for your positive feedback. Now I know how NOT to do it. But I still do not know how to fix the problem.

Comment by Christopher Ferraro [ 2013 Jan 08 ]

I had this 'timeout' issue when trying to unlink templates or delete LLD trigger prototypes from templates that had a lot (30 - 150) of hosts linked. Finally discovered that it was a PHP memory issue. Found messages like this is the httpd logs:

"PHP Fatal error: Allowed memory size of 268435456 bytes exhausted"

The required PHP memory_limit setting for Zabbix is 128M. I had mine set to 256M, but had to bump it to 2G before I could unlink/delete the above successfully.

Modify memory_limit in your php.ini file and restart httpd to pick up the change.

Hope this helps

Comment by Ildefonso Camargo [ 2013 Jul 24 ]

Greetings,

I am having this problem too, but things are just out of control... I know, for sure, that the amount of items added is almost insane, but that's what we wanted to do, however, we never thought that it would be so hard to delete the host! (or at least unlink the template).

We already set PHP memory limit to 1GB, and timeout to 1800 seconds... it just timeout.

I think a fix for this is necessary. Something that sets the deletion process to a background process, I think that, maybe, something like this:

1. Mark the host/item/... as "deleted", but just the items, not the item's values.
2. Let the housekeeper (or partitioning, or whatever) take care of the values removal (by deleting or partition dropping).
3. In a future, when the item no longer has values associated with it: the server deletes it.
4. When the deleted host no longer have items associated: it gets deleted.

This way, it could take several weeks, maybe months for a item/host to completely disappear, but from the user point of view: it was deleted (because it is no longer visible).

For now, I'll try to get this host and template deleted, somehow....

Thanks!

Ildefonso Camargo

Comment by richlv [ 2013 Jul 24 ]

zabbix already does it that way - actual history and trend values are not deleted by the frontend...

Comment by richlv [ 2016 Oct 14 ]

other issues about bad api performance :

Comment by Michelle Taggart [ 2017 Mar 30 ]

This is a PHP memory limit issue. On CentOS/RHEL implementation, you will need to modify PHP's memory limit. The file is typically located here:

/etc/httpd/conf.d/zabbix.conf

Mine looks like this:

<Directory "/usr/share/zabbix">
    Options FollowSymLinks
    AllowOverride None
    Require all granted

    <IfModule mod_php5.c>
        php_value max_execution_time 300
        php_value memory_limit 512M
        php_value post_max_size 16M
        php_value upload_max_filesize 2M
        php_value max_input_time 300
        php_value always_populate_raw_post_data -1
        php_value date.timezone America/New_York
    </IfModule>
</Directory>

<Directory "/usr/share/zabbix/conf">
    Require all denied
</Directory>

<Directory "/usr/share/zabbix/app">
    Require all denied
</Directory>

<Directory "/usr/share/zabbix/include">
    Require all denied
</Directory>

<Directory "/usr/share/zabbix/local">
    Require all denied
</Directory>

I've increased ours to 512MB. That should fix your issue as well.

Restart apache after the change and try again.

Comment by Alexander Vladishev [ 2017 Sep 26 ]

Performance of deleting host with many items was improved in version 3.4.0:

Number of applications: 10
Number of items: 4034
Number of triggers: 15
Number of graphs: 2005

2.0.2

Total time: 6.956846
Total SQL time: 5.2984650000002
SQL count: 28555 (selects: 142 | executes: 28413)
Peak memory usage: 324M

2.0.21

Total time: 6.692669
Total SQL time: 5.0246620000002
SQL count: 28466 (selects: 122 | executes: 28344)
Peak memory usage: 324M

2.2.20

Total time: 5.280494
Total SQL time: 3.6363550000002
SQL count: 28441 (selects: 113 | executes: 28328)
Peak memory usage: 310M

3.0.11

Total time: 5.963973
Total SQL time: 3.8218160000001
SQL count: 28455 (selects: 128 | executes: 28327)
Peak memory usage: 366M

3.2.8

Total time: 6.812552
Total SQL time: 4.1360620000002
SQL count: 32506 (selects: 129 | executes: 32377)
Peak memory usage: 414M

3.4.0

Total time: 1.531616
Total SQL time: 1.264756
SQL count: 201 (selects: 114 | executes: 87)
Peak memory usage: 62M

3.4.2

Total time: 1.390731
Total SQL time: 1.145264
SQL count: 222 (selects: 131 | executes: 91)
Peak memory usage: 66M
Comment by Alexander Vladishev [ 2017 Sep 26 ]

I close this issue as "Won't Fix"

Comment by Vladimir Ulogov [ 2018 Sep 19 ]

So, if I have host with 40K Items (I know, it's insane, but ... and thanks for an LLD) and do want to remove this Host, I'm screwed. Right ?

Generated at Fri Apr 19 21:47:40 EEST 2024 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.