On 02/12/2015 06:11 PM, Yuri Voinov wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I talking not about another redirector. But about smart Squid
behaviour with redirector's children.
If I wanted to change redirector - I would have already done it. I am
aware of the existence of ufdvGuard. Moreover - I've tried to build it
on my system. Failed - it cannot build without dancing with a
tambourine. I have enough Squid with his tambourines.
You never tried the support desk of ufdbGuard either.
I only want to more control over redirector's processes. Not more. And
cnanging free redirector to commercial one is not an option.
ufdbGuard is not a commercial redirector, but is free and
works with any free database or your own database/blacklist.
It has an additional option to use a commercial database.
13.02.15 2:06, Marcus Kool пишет:
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:
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
_______________________________________________ squid-users
mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
iQEcBAEBAgAGBQJU3QjnAAoJENNXIZxhPexG6b4H/ibFEpNS5f25ESr3H6EttwrN
2kW2bWd52g3C7SeM783K9f92EOpNgwLSXd2SDKXnQAfJeYoYl6AqPge5vjg7l6R2
YB0PbAnjJZvju7gmRfYqhhcXAasGBPq1Ot5vbnoo6JNP3JEjoxRlFPo9KKPxXmLF
q32bw1z7D8hExkMBZx/Esq44kISpxo3fNx9Zd1EwhnzzXcX5qcwoZ46/pWOiHd5/
4hd9u1ZAoOFFfAc64YiP49rXcelAFgO7nl5NLOcx50n4F+uTa14lRhrhmmmex/Wz
tdwEXXpwnXsJKCwt/zMJo3StW05/DxmVXidjfUWuHlSA10RKRbsPRaWRBtKPba0=
=t+/k
-----END PGP SIGNATURE-----
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
