Time-critical problem at Sun: exploding smbd memory usage --- Here's the real fix!
Richard Bollinger
rabollinger at home.com
Wed Sep 5 22:37:27 GMT 2001
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.
Rich Bollinger, Elliott Company
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fixleaks.patch
Type: application/octet-stream
Size: 419 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba-technical/attachments/20010905/dc3d763d/fixleaks.obj
More information about the samba-technical
mailing list