Ideally we should take in account the dc_interface->max_snmp_succeed when calculating the seed for nextchecks in get_item_nextcheck_seed() function. Instead of returning interfaceid if bulk is enabled we should return some hash based on interfaceid, number of items using this interface and max_snmp_succeed value. We do keep lists of snmp items by interface, so it should be possible. Something like interfaceid * itemid % (number of items / max_snmp_succeed) (when number of items > max_snmp_succeed).

Can someone tell me if this is somehow related to ZBXNEXT-3988?

zalex_ua I'd say the ZBXNEXT-3988 has "top level" influence on current case as well, but issue described here is an independent, specific one.

glebs.ivanovskis Thank you!

As a workaround, there is optional <from> parameter in zabbix[queue,<from>,<to>], it can be increased (default value is 6 seconds) to make queue readings more stable. It will introduce some latency in detecting delayed checks, but <from> should not be too high to account for slow SNMP polling and latencies will be tolerable.

Continues under ZBXNEXT-4103

Just want to leave here a note as for my statement "data size the device should reply by"

Here is an example output of "show snmp" management command of cisco switch:

Router# show snmp

Chassis: 01234567
37 SNMP packets input
    0 Bad SNMP version errors
    4 Unknown community name
    0 Illegal operation for community name supplied
    0 Encoding errors
    24 Number of requested variables
    0 Number of altered variables
    0 Get-request PDUs
    28 Get-next PDUs
    0 Set-request PDUs
78 SNMP packets output
    0 Too big errors (Maximum packet size 1500)
    0 No such name errors
    0 Bad values errors
    0 General errors
    24 Response PDUs
    13 Trap PDUs

SNMP logging: enabled
    Logging to 192.168.1.1.162, 0/10, 13 sent, 0 dropped.
SNMP Manager-role output packets
    4 Get-request PDUs
    4 Get-next PDUs
    6 Get-bulk PDUs
    4 Set-request PDUs
    23 Inform-request PDUs
    30 Timeouts
    0 Drops
SNMP Manager-role input packets
    0 Inform response PDUs
    2 Trap PDUs
    7 Response PDUs
    1 Responses with errors

SNMP informs: enabled
    Informs in flight 0/25 (current/max)
    Logging to 192.168.1.1.162
        4 sent, 0 in-flight, 1 retries, 0 failed, 0 dropped
    Logging to 192.168.1.1.162
        0 sent, 0 in-flight, 0 retries, 0 failed, 0 dropped

note please this part:

78 SNMP packets output
    0 Too big errors (Maximum packet size 1500)

looks like it says about what I supposed initially - if prepared reply will be more than 1500 bytes(it depends on values, whose length is variable/unpredictable), snmp device will reply with tooBig error.
Not because of OIDs number, but because of reply size in bytes!