Re: Fwd: [squid-users] Performance tuning of SMP + Large rock

On Thu, Feb 13, 2014 at 3:02 PM, Alex Rousskov
<rousskov_at_measurement-factory.com> wrote:
> On 02/13/2014 03:01 PM, Rajiv Desai wrote:
>
>> When using LargeRock, what doe the io pattern correspond to? 16KB
>> random reads if slot size is 16KB?
>
> I am not 100% sure the reads are always 16KB. Squid may request less if
> Squid knows that the object ends sooner than the slot. You can check
> using strace or some such.
>
> I am also curious why you seem to be ignoring disk writes. In general,
> there are more disk writes than disk reads in a forward proxy
> environment. And it is disk writes that create the most problems for Squid.
>
>
>> Also, can I increase the slot size to a higher value at the expense
>> lower granularity?
>
> You can increase the slot size up to 32KB. IIRC, you cannot increase it
> higher without adjusting a hard-coded value in Squid, because the shared
> memory pages are hard-coded to be 32KB in size and worker/disker
> communication is done using those pages.

I increased the slot size for a fresh cache with:
cache_dir rock /mnt/squid-cache 204800 max-size=4194304 slot-size=32768

How to I confirm that the slot size I have configured for is being used?
Any logs or squidclient stats that will confirm that?

>
> Please make sure you actually need to increase it. It is possible that
> with 80KB mean object size, 80% of your objects are smaller than 10KB so
> increasing slot size may hurt rather than help...
>

This is a controlled dataset where objects are 50 KB to 100 KB in size
with a mean of 80 KB.

>
>>>> cache_mem 1024 MB
>>>>
>>>> with 4 workers:
>>>> workers 4
>>>>
>>>> I am running squid on a VM with 8 vCPUs(reserved cpu) and 8 GB RAM
>>>> (reserved). It does not seem to be bottlenecked by cpu or memory
>>>> looking at vmstat output.
>>>> I get a throughput of ~38MB/sec when all objects are read from cache
>>>> (with 64 outstanding parallel HTTPS reads at all times and avg object
>>>> size of 80 KB).
>>>
>>> The first question you have to ask is: What is the bottleneck in your
>>> environment? It sounds like you assume that it is the disk. Do you see
>>> disk often utilized above 90%? If yes, you are probably right. See the
>>> URL below for suggestions on how to measure and control disk utilization.
>>
>> The utilization is < 50% but unsure if that is because of async io.
>
> If the utilization is always so low, the bottleneck may be elsewhere.
>

When I perform a random read benchmarking test, iostat still shows
idle percentage > 50%.
Perhaps you are referring to a different utilization metric that I
should be looking at?

> If you do have disk writes in your workload, please make sure you do not
> look at average disk utilization over a long period of time (30 seconds
> or more?). With writes, you have to avoid utilization peaks because they
> block all processes, including Squid. If/when that happens, you can
> actually see Squid workers in D state using top or similar. The
> RockStore wiki page has more information about this complex stuff.
>

Disk writes occur on cache misses. When there high number of misses,
the wan bandwidth becomes a bottleneck with ~200 Mbps available
bandwidth so I am not too concerned about that.
The 1Gbps requirement is after I have completely primed the cache.
Hence I a more interested in read throughput from cache.

> Sorry, I do not know what you mean by "async io" in this context. Rock
> diskers use regular blocking disk I/O.
>
>
> Cheers,
>
> Alex.
>
>>> Rock store performance tuning suggestions are available at
>>> http://wiki.squid-cache.org/Features/RockStore
>
Received on Fri Feb 14 2014 - 00:37:52 MST