-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 BTW, now I have average 300-400 Mb total memory consumption over all working instances of squidGuard. And see only one problem - idle processes never dies after peak hours, and therefore idle= parameter is meaningless. 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 iQEcBAEBAgAGBQJU3QxDAAoJENNXIZxhPexGJK8H/3N3Td4opmjjuEH8WDfWJllO UxTHGzZ134pgv5gl52QLahAn1gmq99MqPYWQOlwlgLjCJEiarH4aE5G5evlfeZLs 9lAY7aZVqyb1z6iOBI+93mxjzSVqkjQ9gO7V2K6/pP6bQhos3Z1IAoFq2rHSGe/6 XBdqrTqg4wKgDGLRPkN0d5PP5MQakJdsCZ+jogDzi0hkx//1g264s+j4isdlw+UY iWTAX2rtqj0So4TwUPSFd8MRmzKB82gMaRTh3yr/F+TcMyrcJQdUgefVWdVi59qB 4CPw5mm1V4gGkjrGbuHnq8XOwrjL6k95KRnBiy8V4d5ZG7Jv1wiE8v8VwDc7mqg= =sGS+ -----END PGP SIGNATURE----- _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
