Some more info:
Following are mgr:storedir stats after back to back downloads for 4 GB
data (ie same 2 GB twice).
Perhaps the 477 StoreEntries with MemObjects AND 468 Hot Object
Cache Items are not shared?
<stats>
Connection information for squid:
Number of clients accessing cache: 10
Number of HTTP requests received: 78410
Number of ICP messages received: 0
Number of ICP messages sent: 0
Number of queued ICP replies: 0
Number of HTCP messages received: 0
Number of HTCP messages sent: 0
Request failure ratio: 0.00
Average HTTP requests per minute since start: 8167.3
Average ICP messages per minute since start: 0.0
Select loop called: 1228150 times, 4.226 ms avg
Cache information for squid:
Hits as % of all requests: 5min: 44.7%, 60min: 44.7%
Hits as % of bytes sent: 5min: 44.9%, 60min: 44.9%
Memory hits as % of hit requests: 5min: 0.0%, 60min: 0.0%
Disk hits as % of hit requests: 5min: 88.9%, 60min: 88.9%
Storage Swap size: 2454128 KB
Storage Swap capacity: 1.2% used, 98.8% free
Storage Mem size: 1980 KB
Storage Mem capacity: 0.0% used, 0.0% free
Mean Object Size: 62.81 KB
Requests given to unlinkd: 0
Median Service Times (seconds) 5 min 60 min:
HTTP Requests (All): 0.03394 0.03394
Cache Misses: 0.04430 0.04430
Cache Hits: 0.02041 0.02041
Near Hits: 0.00000 0.00000
Not-Modified Replies: 0.00000 0.00000
DNS Lookups: 0.02896 0.02896
ICP Queries: 0.00000 0.00000
Resource usage for squid:
UP Time: 576.032 seconds
CPU Time: 476.166 seconds
CPU Usage: 82.66%
CPU Usage, 5 minute avg: 118.39%
CPU Usage, 60 minute avg: 88.17%
Process Data Segment Size via sbrk(): 81444 KB
Maximum Resident Size: 4967328 KB
Page faults with physical i/o: 2
Memory usage for squid via mallinfo():
Total space in arena: 82632 KB
Ordinary blocks: 75092 KB 4345 blks
Small blocks: 0 KB 0 blks
Holding blocks: 350592 KB 73 blks
Free Small blocks: 0 KB
Free Ordinary blocks: 7540 KB
Total in use: 7540 KB 2%
Total free: 7540 KB 2%
Total size: 433224 KB
Memory accounted for:
Total accounted: 27358 KB 6%
memPool accounted: 27358 KB 6%
memPool unaccounted: 405866 KB 94%
memPoolAlloc calls: 17695559
memPoolFree calls: 17764839
File descriptor usage for squid:
Maximum number of file descriptors: 589824
Largest file desc currently in use: 35
Number of file desc currently in use: 135
Files queued for open: 0
Available number of file descriptors: 589689
Reserved number of file descriptors: 900
Store Disk files open: 1
Internal Data Structures:
477 StoreEntries
477 StoreEntries with MemObjects
468 Hot Object Cache Items
39070 on-disk objects
</stats>
On Tue, Feb 18, 2014 at 1:52 AM, Rajiv Desai <rajiv_at_maginatics.com> wrote:
> Hello,
>
> Need some guidance for optimal sharing of cache amongst SMP workers
> using Large rock.
>
> Context:
>
> I am using squid cache with 8 SMP workers and a 200 GB rock cache stored on SMP.
> (Using squid-3.HEAD-20140127-r13248 which has LargeRock support to
> cache objects > 32 KB).
>
> I have set :
> maximum_object_size 4 MB
> cache_dir rock /mnt/squid-cache 204800 max-size=4194304
> cache_mem 0 MB
>
> My refresh pattern is very permissive which basically allows caching everything:
> refresh_pattern . 129600 100% 129600 ignore-auth
>
>
> Questions:
>
> I am trying to test optimal caching behavior where after I have
> downloaded 1 GB data (~16000 objects ~64KB each) the subsequent
> download should all be cache hits.
> However, I see several TCP misses in access.log. The hit ratio on
> subsequent download of the same objects is ~85%.
>
> 1. Is this expected in a multiple worker setup? If yes, can you please
> briefly explain what contributes towards these misses and how can this
> be minimized?
>
> 2. I set cache_mem to 0 coz I believe cache_mem sharing is
> opportunistic and hence all workers might not always share all objects
> in cache_mem. Is that correct? What impact does cache_mem size have on
> deterministic sharing of cache between workers.
>
> 3. Moreover are there any tips/guidelines to optimize % hit rate for
> previously downloaded objects.
>
> Thanks,
> Rajiv
Received on Tue Feb 18 2014 - 10:42:56 MST
This archive was generated by hypermail 2.2.0 : Tue Feb 18 2014 - 12:00:06 MST