On Fri, Mar 12, 2010 at 10:10 AM, Jan Safranek <[email protected]> wrote: > On 03/05/2010 08:34 PM, Leonardo Chiquitto wrote: >> >> On Tue, Mar 2, 2010 at 12:40 PM, Robert Story<[email protected]> wrote: >>> >>> On Mon, 11 Jan 2010 12:29:56 -0200 Leonardo wrote: >>> LC> Dave, I'm interested in using a part of your work on the new >>> filesystem >>> LC> MIB to fix the problem described in this bug. To avoid reinventing >>> the >>> LC> wheel, do you think you can send me the definition of struct >>> LC> netsnmp_fsys_info? >>> >>> Just wondering if any progress was made here? Were you able to get the >>> missing struct definition from Dave? >> >> Unfortunately not. I spent some time reading that part of the code and >> trying >> to fix the problem, but so far I failed. I'd be really thankful if someone >> could >> take a look at it. > > There is a patch in Red Hat Bugzilla: > https://bugzilla.redhat.com/show_bug.cgi?id=532672. It keeps track of > already used indexes and tries to read /etc/mtab in the same order, which > can lead to the file being re-read for each index. > I've tested it, it works, but I don't like rewinding /etc/mtab back and > forth... what do you think, can it lead into performance problems?
Jan, thanks a lot for the patch. I tested here and it resolves the problem. >From the performance point of view, I think your analysis in the bug is >correct: the time to retrieve the mounts list grows exponentially. Here's a summary of the tests I did with a large number of mounts: - Time to run "snmpwalk -c public -v1 localhost StorageDescr" Not-patched, 350 mounts: 0.8 second. Patched, 350 mounts: 16 seconds Patched, 250 mounts: 6 seconds Patched, 200 mounts: 3.5 seconds Patched, 150 mounts: 2 seconds Patched, 100 mounts: 0.5 second I think that for users with more than 300 mounts it could be a problem. With less than 100 mounts the performance penalty is negligible, IMHO. I also believe there are not many users out there with hundreds of mounted file systems without using something like AutoFS to avoid wasting resources. I'd appreciate if this patch could be accepted as a solution until the new implementation to retrieve file system information (agent/mibgroup/hardware/fsys) is finished. Thanks! Leonardo ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
