-----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. I only want to more control over redirector's processes. Not more. And cnanging free redirector to commercial one is not an option. 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
