Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
If aggregating results from thousands of GetNext() calls in memory, the runtime seems unable to release some of the memory allocated by send() (or dispatch() now). The situation can be improved by copying the resliced response slice in dispatch(), rather than having the runtime keep a reference to a larger (and partially usefull) buffer array. This is the bug I was trying to squash in b84d786. The logic of adjusting the buffer size dynamically seems to be still valid though. With this change, the actual buffer size allocated to handle the response is no longer a problem so I changed the rxBufSizeMin and rxBufSizeMax to more aggressive/generous defaults (and min buffer size is proportional to request size). This will probably make buffer resizing an exceptional event.
- Loading branch information
3e6fc99
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fantastic++ Great work @benjamin-thomas . This change looks good. I remember putting the FIXME comment above the buffer make & read a while back. I wanted to fix it at the time but did not have the bandwidth. My thinking was that we may need to drop to a lower packet read level and check MSG_TRUNC and/or work out exactly how go was wrapping the lower-level recv calls. Your n+1 of course will work well. Also auto scaling the initial buffer size based on the oid count is clever.
I'll do a bit of testing. I think we may meed to be a little more aggressive with the initial buffer size. e.g. fine for numeric values, but may commonly overflow with typical OctetStrings causing re-requests. For reference, both netsnmp and snmp4j allocate ~64k buffers upfront by default.
The slice copy is clever.
I'll open a issue/ticket on the thinking around the initial buffer size.
Great work @benjamin-thomas and @soniah
3e6fc99
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the kind words :)
You gotta love pprof! :D
3e6fc99
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep. If VizGraph is working :-)