RE: Memory usage fix (patch)

> -----Original Message-----
> From: Henrik Nordstrom
> Sent: Thursday, March 17, 2005 9:12 AM
>
> On Thu, 17 Mar 2005, Steven Wilton wrote:
>
> > The problem is that uncacheable objects (ie size >
> maximum_object_size,
> > or download managers doing multiple partial requests on
> large files) are
> > always held in memory. Squid does free this memory as the
> data is sent
> > to the client, but it doesn't look like there's a backoff
> mechanism when
> > the data is arriving at a much faster rate than it is being
> sent to the
> > client.
>
> Normally this is dealt with by the fwdCheckDefer function. Maybe your
> epoll implementation does not use the filedescriptors defer
> function to
> back off when needed?

I did make some changes to my original epoll patch, and the epoll patch now
work with the commSetDefer() function. I had this new version running
overnight, and within a couple of hours squid had grown to double it's
normal size, and we were getting negative hit rates on bytes. This was
caused by the fwdCheckDefer function not stopping the download as expected.
The squid has been patched with the lfs patch (downloaded from
http://devel.squid-cache.org/cgi-bin/diff2/lfs-2.5.patch?s2_5 yesterday),
and a couple of the 2.5.STABLE9 patches from
http://www.squid-cache.org/Versions/v2/2.5/bugs/.

The problem is that once squid starts hitting swap we start getting
complaints. We have also noticed that certain clients have an unusual usage
pattern that seems to cause squid to ue lots of memory, obviously bypassing
the checks in fwdCheckDefer. I'll see if I can track this down.

-- 
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.7.3 - Release Date: 3/15/2005