Yuri,
I suggest to consider using ufdbGuard instead of squidGuard.
Besides being faster is has a different structure:
the redirector that squid starts is a small lightweight process
that forwards requests to ufdbguardd, a multithreaded daemon which
has the URL database in memory. The database is optimised
for memory and occupies less memory than all those squidguard
processes - where each process has a database cache of 10% or 15%
of the database - so 64 processes means that ufdbguard uses 640%
of the size of the database.
Marcus
On 02/12/2015 05:01 PM, Yuri Voinov wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
13.02.15 0:49, Amos Jeffries пишет:
On 13/02/2015 7:01 a.m., Yuri Voinov wrote:
Hi gents,
subj.
And, of course - question. How to do that? I've don't seen this,
if it exists.
For example, for this config stub:
url_rewrite_program /usr/local/bin/squidGuard -c
/usr/local/squidGuard/squidGuard.conf url_rewrite_children 100
startup=0 idle=1 concurrency=0
After daily activity, at midnight, still remain near 60
processes. Absolutely idle.
So, why?
The idle=1 parameter "Sets a minimum ..."
It actually is quite expensive to start them. At least one client
is being held in a pause waiting for it, and others are slowed down
while the CPU spawns the process.
I understand. But Apache-like model will be better. And so, it works
much years in web-front's. Timeout for idle - then shutdown all idle
processed.
Chances are high that the next day, or even a few seconds later
you will need to use them again anyway. So its a bit better to have
them idle than to discard completely.
*Particularly* since you have no concurrency for the helper. A
single
SquidGuard was never been threaded.
client loading a page with many objects can initiate many parallel
requests. Each of which will need to be processed by one of those
helpers.
I understand. But will be better to have more weak instrumentation to
manage children. Either Apache-like, or default.
First query latency is important, but when I tun out of memory, this
query will never be executed in any case.
Moreover - some kernels - especially after swap out idle process, can
not return it quickly to CPU.
The system, which has permanently low memory, have hi risk to slow
down to deep swaping.
Amos, current mechanism is so ungainly. I want to have more powerful
control over rewriter processes.
Now they live their lives. By the end of the day I have a lot of
running processes that do not do anything. And can occupy more than 1
GB of RAM valuable. And there is no mechanism other than sporadic
displacement of the operating system. If you accidentally took the memory.
It's better than it was before, when I had 100 running redirectors
always and 1.5 GB of memory consumed with the threat of a swap, but
worse than the management of processes in Apache. And, therefore,
memory management.
Amos _______________________________________________ squid-users
mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBAgAGBQJU3PiBAAoJENNXIZxhPexGL9QIAMgNh7ANHIfxBAITFka4tJB6
neM0p29jBYlNHskrLyVNqhgDL6XagRCCYp9VzJqVajtCDCejasxx0NV0qDW19uu0
7HcepMGhL6l9WDGm9JyvQo4uz4/00F9ZE3EvUu2lyZmIFaX39rDNnVg64b7EbrJI
fKoS0MfoXSPi+8I+nMcaGNdvWXIKXqsVhL5EJ6X690c2XvpjCv9HmGnf1/k2O6qe
GJprX0yPDgXj0OJhNeM1WZfSa+PQIjD6VXwuqUXpSPU9DFnBT5sZoZ9QqZdUc3Io
fhahOi7Rve3QD13sPb+4FE+pIZECLdvvJ1lWySn+l5zOJD5ZoEGis3qGJmj7xNM=
=hYfs
-----END PGP SIGNATURE-----
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
