-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 13/01/2015 1:15 a.m., Yuri Voinov wrote: > > Yep. > > Memory leaking - if it really it - will be occurs on all > platforms. > > If not - this is OS-specific issue. libc, malloc library problem. > But not squid itself. > By definition a memory leak is memory which is "forgotten" / dereference by the application (squid) without correctly calling free/delete to release the memory back to the OS. I am confident that those types of leaks do not exist at al in Squid 3.4. These rounds of mmory exhaustion problems are caused by pseudo-leaks, where Squid incorrectly holds onto memory (has not forgotten it though) far longer than it should be. > > 12.01.2015 18:06, Eugene M. Zheganin пишет: >> Hi. > >> On 12.01.2015 16:41, Eugene M. Zheganin wrote: >>> I'm now also having a strong impression that squid is leaking >>> memory. Now, when 3.4.x is able to handle hundreds of users >>> during several hours I notice that it's memory usage is >>> constantly increasing. My patience always ends at the point of >>> 1.5 Gigs memory usage, where server memory starts to be >>> exhausted (squid is running with lots of other stuff) and I >>> restart it. This is happening on exactly the same config the >>> 3.3.13 was running, so ... I have cache_mem set to 512 megs, >>> diskd, medium sized cache_dir and lots of users. Is something >>> changed drastically in 3.4.x comparing to the 3.3.13, or is it, >>> as it seems, a memory leak ? >> Squid 3.4 on FreeBSD is by default compiling with the >> --enable-debug-cbdata option and when 45th log selector is at >> it's default 1, cache.log is filling with CBData memory leaking >> alarms. Here is the list for the last 40 minutes, sorted with the >> occurrence count: > >> 104136 Checklist.cc:160 81438 Checklist.cc:187 177226 >> Checklist.cc:320 84861 Checklist.cc:45 89151 CommCalls.cc:21 >> 22069 DiskIO/DiskDaemon/DiskdIOStrategy.cc:353 120 >> UserRequest.cc:166 29 UserRequest.cc:172 55814 >> clientStream.cc:235 5966 client_side_reply.cc:93 4516 >> client_side_request.cc:134 5568 dns_internal.cc:1131 4859 >> dns_internal.cc:1140 86 event.cc:90 7770 external_acl.cc:1426 >> 1548 fqdncache.cc:340 7467 helper.cc:856 39905 ipcache.cc:353 >> 11880 store.cc:1611 181959 store_client.cc:154 256951 >> store_client.cc:337 6835 ufs/UFSStoreState.cc:333 > >> are those all false alarms ? Those have been confirmed as false alerts. The C-style code releases locks first while still holding a pointer (and logs the warning about leak) then frees that pointer (outside the cbdata code) ... the C++ code does it the other way around with cbdata code doing free before releasing the final lock. I am back at the head-scratching stage about where those cbdata issues are coming from. Amos -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJUs9TrAAoJELJo5wb/XPRjHMsIAL48yDQP91+DaX3F1ctY4uYw hFMMiSL48rd/4KYvwXs+7Cy2HEzcF7mMQpkcY92MdX0PYtsTAIDnP5Cggm56knqB aV4UtwgethI5qvcJlGRXrCpsmqEYjvC4w7PEdvEBRyzAZTv9g36hWMMc9IZtMX6R Yqga9pnUPvIl1Cm1e/5eD/kPfxJm4KMdBrW1jRyhD9z515F+1rko5rD0wIGZBomn KFi/ieb52JPa5+nZLKgn3q/8EQyvsVC56J0UeuZwPj1qrZE13fLAEawydxyv9/PJ RbTaoYAOzcXTTwylOrTRntnwZr+qN5pSr7eUVYv+XdEoVHrII49RlwtB6qJrUfM= =ychL -----END PGP SIGNATURE----- _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
