hi henrik,
>> I think it is the same.. just trapped a bit earlier than I expected.. I have
>> attached a small patch which fixes what I saw in the source. Please give it
>> a try.
ok, building with the latest patch ... AND,
cache_peer 127.0.0.1 parent 8118 7 no-query default
'top' still shows high CPU usage:
...
1319 squid 85.9% 0:17.65 1 15 34 3.15M 5.09M 4.32M 40.5M
1317 squid 0.0% 0:00.00 1 10 31 288K 5.09M 240K 37.4M
...
and "... -k debug" _still_ is reporting:
....
2005/09/11 16:05:42| comm_poll: 1+0 FDs ready
2005/09/11 16:05:42| comm_poll: 1+0 FDs ready
2005/09/11 16:05:42| comm_poll: 1+0 FDs ready
2005/09/11 16:05:42| comm_poll: 1+0 FDs ready
2005/09/11 16:05:42| comm_poll: 1+0 FDs ready
2005/09/11 16:05:42| eventRun: RUN ID 291
2005/09/11 16:05:42| eventRun: Running 'MaintainSwapSpace', id 290
2005/09/11 16:05:42| storeMaintainSwapSpace: f=0.000000, max_scan=100,
max_remove=10
2005/09/11 16:05:42| cbdataFree: 0x11315f0
2005/09/11 16:05:42| cbdataFree: Freeing 0x11315f0
2005/09/11 16:05:42| storeUfsDirMaintain: /var/squid/cache removed 0/10
f=0.000 max_scan=100
2005/09/11 16:05:42| eventAdd: Adding 'MaintainSwapSpace', in 1.000000
seconds
2005/09/11 16:05:42| comm_poll: 1+0 FDs ready
2005/09/11 16:05:42| comm_poll: 1+0 FDs ready
2005/09/11 16:05:42| comm_poll: 1+0 FDs ready
2005/09/11 16:05:42| comm_poll: 1+0 FDs ready
2005/09/11 16:05:42| comm_poll: 1+0 FDs ready
2005/09/11 16:05:42| comm_poll: 1+0 FDs ready
....
cheers,
richard
This archive was generated by hypermail pre-2.1.9 : Sat Oct 01 2005 - 12:00:03 MDT