Re: squid-2.4 release ?

On Sun, Jan 07, 2001, Joe Cooper wrote:
> Over the past several days I've had some time for performing benchmarks.
> I'll be posting the results in another day or two. I'm running into a
> few issues of stability under load, as well as slight performance
> degradation from 2.2STABLE5 (and obviously slower than reiser_raw, as is
> expected).
>
> The biggest concern is that I can consistently make Squid crash by
> pushing it a little beyond it's load handling capability. This may be
> simply an issue of CPU saturation, but the error I see (sometimes, other
> times no error is presented) in the cache.log is one of a couple of
> memory related errors. Either:
>
> FATAL: logfileWrite: /var/log/squid/access.log: (12) Cannot allocate memory
>
> or more commonly:
>
> 2001/01/07 03:09:31| comm_poll: poll failure: (12) Cannot allocate memory
> 2001/01/07 03:09:31| Select loop Error. Retry 1
> 2001/01/07 03:09:31| comm_poll: poll failure: (12) Cannot allocate memory
> ...2-9... Same error, repeated...
> 2001/01/07 03:09:31| comm_poll: poll failure: (12) Cannot allocate memory
> 2001/01/07 03:09:31| Select loop Error. Retry 10
> FATAL: Select Loop failed!

This is scary considering thats the errno from poll() rather than
squid failing to allocate memory.

> Oh, and I also see a few of these in there too:
>
> 2001/01/07 03:09:17| comm_open: socket failure: (105) No buffer space
> available

Hrm. That doesn't look good either - again, another problem with the
kernel not being able to allocate RAM.

Which kernel/libc version is this running under? I'm currently generating
a gprof set for my modio code right now, but tomorrow I'll set off a
"normal" squid running datacomm-1 and see if it suceeds. The last test
I did a week or so ago was fine.

[snip]

> Another interesting item, is that the memory usage climbs towards the
> end of the run. The Squid process goes from about 42MB during the first
> couple of hours to as high as 90MB (usually more like 50-60MB) by the
> end when it crashes. Available memory is still quite high at about 50MB
> even after the process size has climbed, so we are not actually running
> out of memory. I won't say it's a leak, but it does seem a little
> greedy with memory as it begins to get overloaded, and since the errors
> are always memory related, I guess there might be a problem there.
>

[snip]

Memory fragmentation would be an issue but I wouldn't think it would
cause mass hysteria from the kernel running out of RAM. Something else
might be afoot here.

> this squid-HEAD? Could there be added fragmentation with this new code?
> Nevermind. It looks like it hasn't been changed in the snapshot Squid
> I'm running. I could have sworn I saw a message saying it was being
> merged.)

Yes, cbdata went in on friday.

Thanks!

Adrian

-- 
Adrian Chadd			"Sex Change: a simple job of inside
<adrian@creative.net.au>	  to outside plumbing."
				    - Some random movie