> David Tosoff wrote:
>> Thanks Chris.
>>
>> I had already read both of the wiki post and the thread you directed me
>> to before I posted this to the group.
>>
>
> Excellent.
>
>> I already had compiled heap into my squid before this issue happened. I
>> am using heap GDSF. And, I wasn't able to find
>> "--enable-heap-replacement" as a compile option in './configure --help'
>> ... perhaps it's deprecated??
>
> Seems to be. Section 7.2 of the release notes says:
>
> *--enable-heap-replacement*
>
> Please use --enable-removal-policies directive instead.
>
Correct. wiki now updated, thank you for finding this.
>
>> Is it a still a valid compile option for 3.0 stable 13?
>>
>> In any event, a gentleman named Gregori Parker responded and helped me
>> with some suggestions and I've managed to stabalize the squid at ~20480
>> MB cache_mem
>>
>
> Nice.
>
>> The only thing I seem to be missing now is the SO_FAIL issue.
>> Correct me if I'm wrong, but I assume 'SO' stands for 'Swap Out'... But
>> how does this affect a system where there is nowhere for the squid to
>> swap out to (cache_dir null /tmp)...?
>>
>
> Well two things (not mentioned in the other replies) come to mind.
> First you did specify that you've compiled in support for a null type
> store_dir. Assuming you have the cache_dir null type is still a bit
> weird (in 3.0) in that it requires a valid directory, even though it's
> not supposed to write anything to it. Does /tmp exist, and does the
> Squid effective user have access to it?
NP: /tmp has some weird behavior when used for null store-dir. The files
squid saves there don't all interact nicely with the rules of /tmp
eraseability.
You might be better with a dedicated temp directory.
Amos
Received on Wed Apr 08 2009 - 02:17:07 MDT
This archive was generated by hypermail 2.2.0 : Wed Apr 08 2009 - 12:00:02 MDT