Re: squid-2.4 release ?

On Sun, Jan 07, 2001 at 07:43:31PM -0600, 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).

Note that reiserfs_raw kernels have some hacks (in particular, on
inode cache) that may adversely impact performance in non-reiserfs_raw
mode. So to be just, you should use non-reiserfs_raw kernel for
non-reiserfs_raw tests.

> 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!
>
> 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

Kernel VM subsystem fails to keep up with kernel memory allocation
requests. I remember running into this (with 2.2 kernels, though).
You can try to tune bdflush to flush dirty buffers more aggressively,
to make life easier for the vm subsystem.

-- sizif
Received on Mon Jan 08 2001 - 00:47:38 MST