[ZBX-8833] cache for dynamic snmp items indexes values by hostid and port Created: 2014 Sep 29  Updated: 2017 May 30  Resolved: 2014 Oct 31

Status: Closed
Project: ZABBIX BUGS AND ISSUES
Component/s: Proxy (P), Server (S)
Affects Version/s: 2.0.13
Fix Version/s: 2.0.14rc1, 2.2.8rc1, 2.4.2rc1, 2.5.0

Type: Incident report Priority: Blocker
Reporter: Aleksandrs Saveljevs Assignee: Unassigned
Resolution: Fixed Votes: 0
Labels: cache, snmp, snmpdynamicindex
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: File index-by-interfaceid.patch    

 Description   

Suppose we have the following SNMP item with dynamic index:

ifInOctets["index","ifDescr","GigabitEthernet0/1"]

What a poller does when it encounters this item for the first time, is it walks "ifDescr" tree, remembering at which index each value resides. In this case, suppose "GigabitEthernet0/1" resides at index 5, so it remembers that and returns the value of "ifInOctets.5" as the value of the item.

When it encounters this item for the second time, the poller queries the cache and gets 5 as the index for "GigabitEthernet0/1", asks the device for "ifDescr.5" to see whether cache entry is still valid. If it is, it proceeds with "ifInOctets.5". Otherwise, it rebuilds the cache as described above.

The problem is that this caching is done using (hostid, port, OID, value) tuples. In the case above, it will cache 5 for key (hostid, port, "ifDescr", "GigabitEthernet0/1"). Usually this works OK, but breaks when a host has multiple interfaces with the same port, but different IP addresses, as we have seen people use in practice.

In Zabbix 2.0, we introduced multiple interfaces per host, but, apparently, the way this cache works was not updated.

The practical implication is significantly increased CPU usage, because on a large number of occasions the cache has to be rebuilt.



 Comments   
Comment by Aleksandrs Saveljevs [ 2014 Sep 29 ]

Attached is a sample patch that replaces the (hostid, port) part of the index with just interfaceid.

Comment by Alexander Vladishev [ 2014 Oct 09 ]

(1) Will better use CONN + PORT to cache instead of interfaceid.

  1. we can change ip, dns or port on interface
  2. network discovery with snmp checks does not have interfaceids

asaveljevs RESOLVED in r50124.

wiper CLOSED

Comment by Andris Zeila [ 2014 Oct 27 ]

(2) Would be better to separate memory management functions from other parameters in zbx_hashset_create_ext() function.

Also vectors have clean() function, so we should keep similar naming:

void	zbx_hashset_create_ext(zbx_hashset_t *hs, size_t init_size,
				zbx_hash_func_t hash_func,
				zbx_compare_func_t compare_func,
				zbx_clean_func_t clean_func,
				zbx_mem_malloc_func_t mem_malloc_func,
				zbx_mem_realloc_func_t mem_realloc_func,
				zbx_mem_free_func_t mem_free_func
				)

asaveljevs RESOLVED in r50220.

wiper CLOSED

Comment by Andris Zeila [ 2014 Oct 28 ]

Successfully tested, but please see the (2) subissue

Comment by Aleksandrs Saveljevs [ 2014 Oct 28 ]

(3) Fix for 2.0, which simply replaces indexing by (hostid, port) with (addr, port) is available in development branch svn://svn.zabbix.com/branches/dev/ZBX-8833-2.0 .

wiper CLOSED

Comment by Aleksandrs Saveljevs [ 2014 Oct 28 ]

(4) After this issue is merged into trunk, we shall create a separate branch under this issue and change "zbx_vector_ptr_clear(zbx_vector_ptr_t *vector, zbx_mem_free_func_t free_func)" to "zbx_vector_ptr_clear(zbx_vector_ptr_t *vector, zbx_clean_func_t clean_func)".

asaveljevs Fixed in development branch svn://svn.zabbix.com/branches/dev/ZBX-8833 . RESOLVED.

wiper after lengthy discussions was decided that vector should not free values array in its clear() and clear_ext() functions.
REOPENED

asaveljevs RESOLVED in r50294 through r50301.

wiper CLOSED

asaveljevs Merged into pre-2.5.0 (trunk) r50327.

Comment by Aleksandrs Saveljevs [ 2014 Oct 28 ]

Fixed in pre-2.0.14 r50235, pre-2.2.8 r50240, pre-2.4.2 r50241, and pre-2.5.0 (trunk) r50242.

Generated at Sat Apr 20 04:08:28 EEST 2024 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.