Time-critical problem at Sun: exploding smbd memory usage --- Here's
the real fix!
Jeremy Allison
jeremy at valinux.com
Thu Sep 6 02:33:14 GMT 2001
Richard Bollinger wrote:
>
> Using an old memory allocation debugging / tracking tool (mem_man), I monitored what was going
> on while smbd processed our 300+ printer printcap file...
>
> After processing 300 printers, the stats were as follows:
> Mem Manager : 196110 blocks, allocation 11553K, real allocation 11553K, 0 errors
>
> Of that, talloc() accounted for 192036 of the malloc() calls and 11280K of the space allocated.
>
> Sure, all of that would be freed eventually, but it amounts to a torture test for the system's
> malloc() / free() capabilities, which apparently aren't as aggressive at recovering / releasing
> free space with Solaris as with Linux :-).
>
> I tracked the problem to an O(N^2) loop... add_all_printers() calls pcap_printer_fn(), which in
> turn calls lp_add_one_printer(), which in turn calls lp_servicenumber(), which in turn calls
> lp_servicename(), which in turn calls lp_string(), which in turn calls talloc().
>
> Here's the fix to lp_servicenumber(), based on similar code in getservicebyname()...
>
> --- ../source/param/loadparm.c Fri Aug 31 07:15:36 2001
> +++ ./param/loadparm.c Wed Sep 5 22:11:36 2001
> @@ -3418,7 +3424,8 @@
>
> for (iService = iNumServices - 1; iService >= 0; iService--)
> if (VALID(iService) &&
> - strequal(lp_servicename(iService), pszServiceName))
> + ServicePtrs[iService]->szService &&
> + strequal(ServicePtrs[iService]->szService, pszServiceName))
> break;
>
> if (iService < 0)
>
> After the fix is in, the same memory monitoring tools reveal these stats:
> Mem Manager : 4054 blocks, allocation 537K, real allocation 537K, 0 errors
>
> Of that, talloc() now accounts for only 7 of the malloc() calls and 357 bytes allocated.
*Great* detective work ! Thanks. I'll commit this fix
to 2.2 and HEAD as soon as samba.org comes back on
line for me :-).
Jeremy.
More information about the samba-technical
mailing list