Hi, 2010/8/19 Amos Jeffries <squid3@xxxxxxxxxxxxx>: >> 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
