>>delay_class 1 2
>>delay_access 1 allow 192.168.1.239/255.255.255.255
>что-то меня сомнение берет на такой синтаксис ! уверен что сквид на
>него не ругается?
Сквид не ругается. cache.log чистый, но я всеравно последовал Вашему совету и переписал правила как Вы советуете.
К великому сожалению результат не изменился.>еслто что то не работает - включай debug на уровень 9
> конфиге сквида и смотри cache_log
Я и до этого включал debug_options ALL,9
Но в тех 17 мегах, которые создались за пару секунд я ничего не понял. Приведу маленький кусочек из лога:
2006/08/16 09:19:20| comm_select: 2 FDs ready at 1155709160
2006/08/16 09:19:20| comm_select: FD 17 ready for read
2006/08/16 09:19:20| comm_select: FD 17 calling read_handler 0044A8BD(010311F0)
2006/08/16 09:19:20| httpReadReply: FD 17: len 284.
2006/08/16 09:19:20| storeAppend: appending 284 bytes for '6679FD87FD9E5C01EAA8ED826D6A0C5E'
2006/08/16 09:19:20| memAppend: len 284
2006/08/16 09:19:20| InvokeHandlers: 6679FD87FD9E5C01EAA8ED826D6A0C5E
2006/08/16 09:19:20| InvokeHandlers: checking client #0
2006/08/16 09:19:20| storeSwapOut: ftp://ftp.downloads1.kaspersky-labs.com/zips/av-i386&ids-cumul.zip
2006/08/16 09:19:20| storeSwapOut: store_status = STORE_PENDING
2006/08/16 09:19:20| storeSwapOut: mem->inmem_lo = 806912
2006/08/16 09:19:20| storeSwapOut: mem->inmem_hi = 813073
2006/08/16 09:19:20| storeSwapOut: swapout.queue_offset = 0
2006/08/16 09:19:20| storeSwapOut: lowest_offset = 810741
2006/08/16 09:19:20| httpPconnTransferDone: FD 17
2006/08/16 09:19:20| httpPconnTransferDone: content_length=8478360
2006/08/16 09:19:20| commSetTimeout: FD 17 timeout 900
2006/08/16 09:19:20| commSetSelect: FD 17 type 1
2006/08/16 09:19:20| comm_select: FD 13 ready for write
2006/08/16 09:19:20| comm_select: FD 13 calling write_handler 0042A749(01123C08)
2006/08/16 09:19:20| commHandleWrite: FD 13: off 0, sz 2048.
2006/08/16 09:19:20| commHandleWrite: write() returns 2048
2006/08/16 09:19:20| cbdataValid: 0111EEB8
2006/08/16 09:19:20| clientWriteComplete: FD 13, sz 2048, err 0, off 812789, len -1
2006/08/16 09:19:20| storeClientCopy: 6679FD87FD9E5C01EAA8ED826D6A0C5E, seen 812789, want 812789, size 4096, cb 00422312, cbdata 0111EEB8
2006/08/16 09:19:20| cbdataLock: 0111EEB8
2006/08/16 09:19:20| cbdataLock: 01128EF8
2006/08/16 09:19:20| storeClientCopy2: 6679FD87FD9E5C01EAA8ED826D6A0C5E
2006/08/16 09:19:20| storeClientCopy3: Copying from memory
2006/08/16 09:19:20| memCopy: offset 812789: size 4096
2006/08/16 09:19:20| storeSwapOut: lowest_offset = 812789
2006/08/16 09:19:20| cbdataValid: 0111EEB8
2006/08/16 09:19:20| clientSendMoreData: ftp://ftp.downloads1.kaspersky-labs.com/zips/av-i386&ids-cumul.zip, 284 bytes
2006/08/16 09:19:20| clientSendMoreData: FD 13 'ftp://ftp.downloads1.kaspersky-labs.com/zips/av-i386&ids-cumul.zip', out.offset=812789
2006/08/16 09:19:20| comm_write: FD 13: sz 284: hndl 004226AF: data 0111EEB8.
2006/08/16 09:19:20| cbdataLock: 0111EEB8
2006/08/16 09:19:20| commSetSelect: FD 13 type 2
2006/08/16 09:19:20| cbdataUnlock: 0111EEB8
2006/08/16 09:19:20| cbdataUnlock: 01128EF8
2006/08/16 09:19:20| cbdataUnlock: 0111EEB8
2006/08/16 09:19:20| comm_select: 1 FDs ready at 1155709160
2006/08/16 09:19:20| comm_select: FD 13 ready for write
2006/08/16 09:19:20| comm_select: FD 13 calling write_handler 0042A749(01123C30)
2006/08/16 09:19:20| commHandleWrite: FD 13: off 0, sz 284.
2006/08/16 09:19:20| commHandleWrite: write() returns 284
2006/08/16 09:19:20| cbdataValid: 0111EEB8
2006/08/16 09:19:20| clientWriteComplete: FD 13, sz 284, err 0, off 813073, len -1
2006/08/16 09:19:20| storeClientCopy: 6679FD87FD9E5C01EAA8ED826D6A0C5E, seen 813073, want 813073, size 4096, cb 00422312, cbdata 0111EEB8
2006/08/16 09:19:20| cbdataLock: 0111EEB8
2006/08/16 09:19:20| cbdataLock: 01128EF8
2006/08/16 09:19:20| storeClientCopy2: 6679FD87FD9E5C01EAA8ED826D6A0C5E
2006/08/16 09:19:20| storeClientCopy3: Waiting for more
2006/08/16 09:19:20| cbdataUnlock: 01128EF8
2006/08/16 09:19:20| cbdataUnlock: 0111EEB8
2006/08/16 09:19:20| comm_select: 1 FDs ready at 1155709160
2006/08/16 09:19:20| comm_select: FD 13 ready for read
2006/08/16 09:19:20| comm_select: FD 13 calling read_handler 0041C93B(0116E6A8)
2006/08/16 09:19:20| clientReadRequest: FD 13: reading request...
2006/08/16 09:19:20| clientReadRequest: FD 13: (10054) WSAECONNRESET, Connection reset by peer.
2006/08/16 09:19:20| comm_close: FD 13
2006/08/16 09:19:20| commCallCloseHandlers: FD 13
2006/08/16 09:19:20| commCallCloseHandlers: ch->handler=0041BC5D
2006/08/16 09:19:20| cbdataValid: 0116E6A8
2006/08/16 09:19:20| connStateFree: FD 13
2006/08/16 09:19:20| httpRequestFree: ftp://ftp.downloads1.kaspersky-labs.com/zips/av-i386&ids-cumul.zip
2006/08/16 09:19:20| httpRequestFree: al.url='ftp://ftp.downloads1.kaspersky-labs.com/zips/av-i386&ids-cumul.zip'
2006/08/16 09:19:20| cbdataLock: 00C69878
2006/08/16 09:19:20| cbdataLock: 0116E6A8
2006/08/16 09:19:20| cbdataUnlock: 0116E6A8
2006/08/16 09:19:20| cbdataUnlock: 00C69878
2006/08/16 09:19:20| cbdataFree: 0128D7A8
2006/08/16 09:19:20| cbdataFree: Freeing 0128D7A8
2006/08/16 09:19:20| storeClientUnregister: called for '6679FD87FD9E5C01EAA8ED826D6A0C5E'
2006/08/16 09:19:20| storeClientUnregister: store_client for ftp://ftp.downloads1.kaspersky-labs.com/zips/av-i386&ids-cumul.zip has a callback
2006/08/16 09:19:20| cbdataValid: 0111EEB8
2006/08/16 09:19:20| clientSendMoreData: (null), -1 bytes
2006/08/16 09:19:20| clientSendMoreData: FD 13 '[null_entry]', out.offset=813073
2006/08/16 09:19:20| clientWriteComplete: FD 13, sz 0, err 0, off 813073, len 0
2006/08/16 09:19:20| comm_close: FD 13
может кто посоветует как застаить работать delay_pools, или это нюансы виндового сквида???