Re: [squid-users] "Quadruple" memory usage with squid

Amos Jeffries wrote:
> Robert Collins wrote:
>> On Wed, 2009-11-25 at 10:43 -0200, Marcus Kool wrote:
>>
>>> There are alternative solutions to the problem:
>>> 1. redesign the URL rewriter into a multithreaded application that
>>

1b.
   Kinkie has just reminded me about the helper muxer/demuxer he has
been working on for the SMP support in Squid-3. This is still
experimental at present but would also be worth a try if you are
willing. He's posted it to squid-dev now.

It's a perl script that wraps a non-threaded helper binary and lets
Squid talk threaded helper protocol to a bunch of them through a single
muxer child.

* So Squid only forks once to start the muxer, and further
forks/whatever are done inside the muxer. Hopefully with only its much
smaller memory footprint, if the problem still exists at all down at
that level.

  * Usage is basically to set the relevant Squid concurrency value to
the number of helpers the muxer is to run. Running M muxers at N
concurrency level causes N*M helpers to be available in parallel.

>>> 2. redesign the URL rewriter where the URL rewriter rereads
>>
>>> 3. modify the URL rewriter to accept multiple request
>>
>>> 4. use less URL rewriters. You might get an occasional
>>
>> 5. Experiment with vfork.
>>
>> -Rob
>
> Any of the above plus:
>
> Log daemon is overdue for a patch to make it cap file size and
> auto-rotate when the cap is hit. If you are able to assist with that
> development you can then use the logging daemon instead of expensive log
> rotates by squid itself.

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE7 or 3.0.STABLE20
   Current Beta Squid 3.1.0.15