The problem has solved, it was our mistake with authenticator :). Big thanks for help us. Think this expirience will be so useful for others. I'll send mgr:info where server will have most load (typically at the end and start of the month) for community statistics. P.S. I'll having some questions about possibility of dynamic acl's and date_and_time acl's instead of only time. Think I should read docs before asking. Amos Jeffries пишет: > Serg A. Androsov wrote: >> Amos Jeffries wrote: >>> That makes sense. Anything over your original cache_mem size would be >>> expected to cause issues somewhere down the logics. >>> >> Well the big work was done yesterday. I've disabled some code in >> accounting system preventing it from squid reconfiguration, use own >> mysql_auth helper and has some work with squid.conf. >> >> CPU load is dramatically down. The peaks is near 20%. >> >> Now I have some problems with CONNECT method. All connects to 443 port >> works (for example - icq), but other ports is not. >> Our clients use third tunnelling apps working with CONNECT method but >> now it'is not working. >> >> Here is new config (something was not rewritten, because of time, but >> will be): >> ----------------- >> http_port 8080 >> acl QUERY urlpath_regex cgi-bin \? >> cache deny QUERY >> acl apache rep_header Server ^Apache >> broken_vary_encoding allow apache >> >> cache_mem 1024 MB >> maximum_object_size 1024 KB >> maximum_object_size_in_memory 1024 KB >> cache_dir null /null >> >> access_log /var/log/squid/access.log squid >> >> auth_param basic program /usr/lib64/squid/mysql_auth >> auth_param basic children 20 >> auth_param basic realm Squid proxy-caching web server >> auth_param basic credentialsttl 20 second >> auth_param basic casesensitive off >> >> refresh_pattern ^ftp: 1440 20% 10080 >> refresh_pattern ^gopher: 1440 0% 1440 >> refresh_pattern . 0 20% 4320 >> >> acl all src 0.0.0.0/0.0.0.0 >> acl manager proto cache_object >> acl localhost src 127.0.0.1/255.255.255.255 >> acl admins src 172.16.1.0/24 >> acl to_localhost dst 127.0.0.0/8 >> acl users proxy_auth REQUIRED >> acl SSL_ports port 443 >> acl CONNECT method CONNECT >> acl good_url url_regex -i "/etc/squid/acl/good_url" >> >> http_access allow manager localhost >> http_access deny manager >> http_access allow localhost >> http_access allow all good_url >> #what wrong here? >> http_access allow users >> http_access allow users CONNECT > > Hmm, nothing wrong with that config that I can see now. > The 'allow users CONNECT' should be letting them through if auth'd. > I'm thinking some of the apps are not sending user:pass properly to squid. > > Can you get a good trace of the traffic to/from one of the dying clients > and squid? > > Amos > >> >> http_access deny all >> http_reply_access allow all >> >> icp_access allow all >> cache_effective_user nobody >> error_directory /usr/share/squid/errors/Russian-koi8-r >> coredump_dir /var/spool/squid >> >> ---------------------- >> With best regards, >> >> Serg. > >
