I'm running a simple datacomm-1 workload against squid-2-head and I'm finding
the thing is leaking storeentry's all over the place. The symptom is that
the MEM_MEM_NODE pool grows forever. I looked into it and found most of the
store entries were marked "release request" with one lock and nothing to
tidy it up. The only store entries which were being considered for reaping
by the memory replacement policy were those who weren't jammed in this state.
The ones who are jammed in this state were somehow removed from the policy
but didn't have their memory cleaned so all the 'fine' objects were being
quickly discarded.
Here's an example:
KEY 9228D59CF2585E28AB922554BEB4D152
GET http://192.168.1.7:8080/w0f575ba4.28ed1675:00000006/t01/_00000002
STORE_OK NOT_IN_MEMORY SWAPOUT_NONE PING_DONE
RELEASE_REQUEST,DISPATCHED,PRIVATE,VALIDATED
LV:1169728835 LU:1169728833 LM:-1 EX:1169728835
1 locks, 0 clients, 1 refs
Swap Dir -1, File 0XFFFFFFFF
inmem_lo: 24576
inmem_hi: 26087
swapout: 0 bytes queued
The locking primitives are:
2007/01/25 20:40:33| storeLockObject: (store_client.c:122): key '9228D59CF2585E28AB922554BEB4D152' count=2
2007/01/25 20:40:33| storeLockObject: (forward.c:877): key '9228D59CF2585E28AB922554BEB4D152' count=3
2007/01/25 20:40:33| storeLockObject: (peer_select.c:155): key '9228D59CF2585E28AB922554BEB4D152' count=4
2007/01/25 20:40:33| storeLockObject: (http.c:1423): key '9228D59CF2585E28AB922554BEB4D152' count=5
2007/01/25 20:40:33| storeUnlockObject: (peer_select.c:109): key '9228D59CF2585E28AB922554BEB4D152' count=4
2007/01/25 20:40:36| storeUnlockObject: (http.c:75): key '9228D59CF2585E28AB922554BEB4D152' count=3
2007/01/25 20:40:36| storeUnlockObject: (store_client.c:540): key '9228D59CF2585E28AB922554BEB4D152' count=2
2007/01/25 20:40:36| storeUnlockObject: (client_side.c:1332): key '9228D59CF2585E28AB922554BEB4D152' count=1
Hm, there's no call there to storeUnlockObject at all because of fwdStateFree?
That might be the missing unlock. But where'd it go?
Adrian
Received on Thu Jan 25 2007 - 06:02:00 MST
This archive was generated by hypermail pre-2.1.9 : Thu Feb 01 2007 - 12:00:02 MST