> 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
