Here's the latest 5 minute snapshot. Squid-3 has hit the store mem limit
and is now having to delete in-memory objects to make room for incoming
requests.
(This is using datacomm-1. I wanted to see the worst-case performance -
ie, squid has to keep removing objects without getting any benefit from
HITs.)
Last 5 min averages: (Cumulated time: 1078655379460, 391.72 sec)
Probe Name Events cumulated time best case average worst
case Rate / sec % in int
PROF_UNACCOUNTED 7152744 99510227852 0 13912
424549192 18259.89 9.225
PROF_OVERHEAD 9600 1245452 0 129
88644 24.51 0.000
HttpStateData_readReply 255904 579118330532 0 2263029
23144291000 653.28 53.689
StoreEntry_write 2876390 561660160848 0 195265
23142919280 7343.00 52.070
storeGetMemSpace 2876390 522628513852 0 181695
23142884908 7343.00 48.452
comm_check_incoming 338548 328590409336 0 970587
40595044 864.26 30.463
I'm guessing readReply, write and storeGetMemSpace are nested (in that order.)
I'm curious as to why the rate/sec of readReply and write/storeGetMemSpace are
different.
I'll leave this running for 12 hours and report back.
Adrian
