[squid-users] Is Squid can shutdown unused idle redirector's children?
Yuri Voinov
yvoinov at gmail.com
Fri Feb 13 08:44:14 UTC 2015
Amos,
I understand the idea of the current implementation. I read the manual
no one time. I only want one thing - let the administrator to decide how
to adjust his system to him. Not through patches. By means of parameters.
Squid runs on different OS'es, and it is logical to have a flexible
mechanism for managing child redirectors processes. This must be
mandatory option. The similar to automatically close applications on
Android. As I said, changing the redirector is not an option.
Development of a crutch to automatically stop the processes is not an
option.
I misled the common interpretation of shared processes and management in
other software products. But I believe that to be able to automatically
close the unnecessary processes and free up resources is correct.
On my OS, I have a very powerful system resource management that allows,
in particular, killing idle processes or processes over the limit. But
other operating systems do not have advanced resource management. And
this is not good solution. How to behave Suid when OS forbade him to
start another redirector? Or begin to kill idle processes? Fatal error
and fall? I don't know. And do not want to test on production server.
In addition, the operating system with a constant load of RAM in the
90-95% is just on the edge of a swap or a kernel panic. For Solaris this
is not care - but it has a very specific kernel. Most of the other OS
just goes to swap or initiates OOM.
In my opinion the software that claims to be a universal platform, is
bound to have a more flexible mechanism for managing processes. As
Oracle, for example. Which is known to work on all platforms without
exception.
WBR, Yuri
13.02.15 6:34, Amos Jeffries пишет:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 13/02/2015 8:54 a.m., Yuri Voinov wrote:
>> So simple.
>>
>> I want to see only one additional parameter.
>>
>> idle_timeout.
>>
>> When I specify it to 0 - by default - all started rewriter
>> processess remains after user requests,
>>
>> but! it I specify it over 0 in seconds - all idle rewriters after
>> timeout must dies to achieve idle= value.
>>
>> Logically, isn't it? This permits me to design, how cache will
>> works with user's sessions. And, moreover, in other software
>> products such behavior with shared processes is the default. I.e -
>> Oracle shared server. Apache WEB server in some configurations. And
>> others.
> Your examples are software which spawns a whole worker process for
> each user transaction, executes that one transaction then tears down
> the whole worker process.
>
> Apache is a good example, we had some of their devs coming to us a few
> years ago asking for explanations about how Squid manages to process
> some of the I/O stuff asynchronously as they are/were moving Apache to
> something like *our* process model for performance reasons.
>
>
>> Otherwise idle= parameter for children just do not make sense.
>> SQUID decides for me, it's better for my system. I want to have
>> better control over rewriter's children and memory consumption.
>>
>> Did you agree?
> Why would anyone agree with someone who does not understand the
> current behaviour and repeatedly insults it due to their own lack of
> understanding?
>
>
>
>
> You already rejected the ufdbGuard suggestion which offers you better
> memory operations, peformance, and Squid integration.
>
>
> If you know perl I suggest taking the helper-mux tool
> (tools/helper-mux/ in the sources) and adjusting it to do the timeout
> management. That will gain you three major benefits in one go:
> 1) concurrency
> 2) smaller virtual memory overheads
> 3) the helper fine tuning
>
>
> Alternatively you can pay for a patch to be written into Squid adding
> the automatic closure. I would be happy to take on that contract.
>
> Amos
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (MingW32)
>
> iQEcBAEBAgAGBQJU3UZ3AAoJELJo5wb/XPRjyEwIAKDMAGGjV3QPQgV4lx+RRsgr
> TIG8BoxvpSUyViRcNUQ4YsH+eg4r4BT835m5EByPU0B5WlM+3+07jJjoMEqarsWK
> aDqjow3g0TcSwaZngKh6u6lkDt0WSYemhYQajg7ggf8wa150td5n7/DjWCcxoYVp
> ia+Js9tzN6oqwWJCihWeBlCd9gJ2QVExrKKL8JrdBZNOkYJpENtB/E0DhmrICy4O
> UtumFkvbNfUpku2SapvIkhqPHfDPl8QwS/ZZZvLTnV1vmWuTmGaGjWvLF3fT8ISr
> owgjsKni04AvvAjUfn3XzRXHWu/F8LE4P+zieskv5v0upejaEvwHRCl4zj0jaKQ=
> =7g6V
> -----END PGP SIGNATURE-----
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
More information about the squid-users
mailing list