Re: [squid-users] High load server Disk problem

Hi,

2010/8/19 Amos Jeffries <squid3_at_treenet.co.nz>:
>> I'd like to know if I can adjust the max-size option of coss, with
>> something like "--with-coss-membuf-size" ? Or is really hard-coded?
>
> It can be altered but not to anything big...

What's something not big? Around 10MB?

Does --with-coss-membuf-size=10485760 do the trick?

> No.  The "buf"/slices are equivalent to swap pages for COSS. Each is swapped
> in/out of disk as a single slice of the total cache. Objects are arranged on
> them with temporal locality so that ideally requests from one website or
> webpage all end up together on a single slice.

That's the "stripe", right?

> Your COSS dirs are already sized at nearly 64GB each (65520 MB). With
> objects up to 1MB stored there. That holds most Windows updates, which are
> usually only a few hundred KB each.

Actually I do a windowsupdate fetch not with ranges, but the full
file, since windowsupdate requests from windows machines only send out
partial content requests, but with the same URL.

> I'm not sure what your slice size is, but 15 of them are stored in RAM at
> any given time. You may want to increase that membuf= parameter a bit, or
> reduce the individual COSS dir size (requires a COSS dir erase and rebuild).

Hmm, I could only get it up to 15 with the current build. But I'll
test to see how big can I increase it.

> The rule-of-thumb for effective swap management seems to be storing 5min of
> data throughput in memory to avoid overly long disk IO wait times. Assuming
> an average hit-rate of around 20% that comes to needing 1min of full HTTP
> bandwidth in memory either (combined: cache_mem RAM cache + COSS membuf) at
> any given time.
>
> Disclaimer: thats just my second-rate interpretation of a recent thesis
> presentation on memory vs flash vs disk service. So testing is recommended.

That's a good tip, thanks :)

- Robert
Received on Thu Aug 19 2010 - 12:57:09 MDT