Re: Compiling for COSS (was Re: squid-2.4stable2 ?)

Adrian Chadd wrote:

> On Mon, Aug 20, 2001, Joe Cooper wrote:
>
>
>>It actually appears to be pretty zoomy now at 70 req/sec, and with near
>>ideal hit ratio so far. I'm going to give it a good workout today and
>>tonight and will present findings later. I think you might just be on
>>to something here.
>>
>
> It should be pretty good up to like 200req/sec.
> Feel free to stress it out a little more.

Hmmm... I don't think we're going to see 200 from this box. At 80
minutes in at 70 reqs/sec I'm seeing declining hit ratio and climbing
response time. Not bad, but definitely an indication that it won't go
much faster without some additional tuning. This might also be a
problem of the store size being a bit small at 1.6GB. I think it takes
about 3GB to fully handle a four hour datacomm-1 workload at this
request rate, or hit rates will drop as the test progresses (since
working set keeps growing in datacomm-1).

It may be that not having kernel aio is slowing things slightly from
what you're seeing (FreeBSD, I presume, has POSIX aio at the kernel level?).

But then CPU is still not quite saturated--it's sitting at 80-90% usage.
  So it's probably got a little room to grow. Maybe I'll run a little
faster when I add a second disk and more storage.

>>Is it safe to use multiple disks and cossdirs with the current COSS?
>
> Yup. It definitely is. I'm testing that now - inf act, that was
> the motivation behind getting the COSS aio working in the first
> place. :)

Cool. I'll give it a go then, with multiple disks. I need to do a
fresh install on a real test box, however (I mutilated it while trying
to debug a problem with ip_wccp in kernel 2.4).

But the tuning thing brings to mind some questions I have for you, since
this is all new territory for me.

Is noatime still appropriate/necessary for a COSS object store? I'm
guessing it would be (and I can't test it on my current test machine
since my COSS dir is on a normal partition with other normal system stuff).

Is there anything else that ought to be altered on the system to
optimize for this kind of workload? Perhaps increasing the disk flush
buffers, such that writes/reads are more aggregated?

Interrupts are still going extraordinarily high on write flushes (like
12000-16000 showing up on a 'vmstat 1'). Context switches aren't bad
though...I would have thought not being kernel level aio would cause
extra context switches...but then I'm ignorant on this subject so can't
really judge how things ought to be behaving.

Overall, anyway, this box is performing just about the same as it would
with an aufs Squid. Maybe a wee bit slower, but not much. This is
really great news, given that COSS is still so young, and not extremely
tuned yet (and I don't know how to tune for it). Great work, indeed,
Adrian. Stable even! ;-)
                                   --
                      Joe Cooper <joe@swelltech.com>
                  Affordable Web Caching Proxy Appliances
                         http://www.swelltech.com
Received on Mon Aug 20 2001 - 13:54:26 MDT