This kind of behavior is usually due to using an inefficient lookup,
especially combined with using the table_iterator helper. See the "Con
Mitigation" heading of http://www.net-snmp.org/wiki/index.php/Table_iterator
if you are using the table_iterator helper.
Bill
On Wed, Jul 2, 2014 at 11:0
When doing some performance measurement, I found that a surprising amount
of time was spent in netsnmp_large_fd_set_resize(). It turns out that a
newly-created large fd set often has an lfs_setsize of zero, and a desired
size of FD_SETSIZE, and the current code zeroes out the bits in between
lfs_s
On Mon, Jul 07, 2014 at 05:33:53PM -0400, Bill Fenner wrote:
> When doing some performance measurement, I found that a surprising amount
> of time was spent in netsnmp_large_fd_set_resize(). It turns out that a
> newly-created large fd set often has an lfs_setsize of zero, and a desired
> size of
