<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p><br>
</p>
<br>
<div class="moz-cite-prefix">21.03.2018 14:55, FredB пишет:<br>
</div>
<blockquote type="cite"
cite="mid:113632435.70726986.1521622553336.JavaMail.root@zimbra4-e1.priv.proxad.net">
<pre wrap="">
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Perhaps I should retry SMP but unfortunately in the past I had many
issues with, and some features I'm using still SMP-unaware
</pre>
</blockquote>
<pre wrap="">Squid's SMP itself does not solves SSL Bump issues. It's about
different
things, and, IMHO, irrelevant your load profile.
</pre>
</blockquote>
<pre wrap="">
I'm thinking about that, because the single squid core is 100% CPU
I tried with 900MB and 50MB without more success, I also added sslflags-NO_DEFAULT_CA
How much simultaneous users do you have ? and bandwidth ? </pre>
</blockquote>
200 users, 2 Gbps downstream.<br>
<blockquote type="cite"
cite="mid:113632435.70726986.1521622553336.JavaMail.root@zimbra4-e1.priv.proxad.net">
<pre wrap="">
I'm using this right now, the number of process used is very better now but still an issue with CPU
acl nobump dstdomain "/home/squid/domains"
http_port 8080 ssl-bump cert=/etc/squid/ca_orion/cert generate-host-certificates=on sslflags=NO_DEFAULT_CA dynamic_cert_mem_cache_size=500MB
sslcrtd_program /usr/lib/squid/ssl_crtd -s /usr/lib/squid/ssl_db -M 500MB
sslcrtd_children 1000 startup=100 idle=5</pre>
</blockquote>
<span id="result_box" class="" lang="en"><span>It does not work that
way.</span> <span>There are still many processes.</span> <span
class="">Scaling is rarely linear.<br>
<br>
Pls keep in mind, squid itself is thread-unaware. So, with </span></span><span
id="result_box" class="short_text" lang="en"><span class="">thousands
of children you make serialization point by yourself from
squid's size.<br>
Another serialization point is SSL db on disk, due to it uses
file locking mechanism.<br>
<br>
Both reasons leads to make bottleneck on SSL certgen processes.<br>
<br>
So, you can't simple set 1000 children and expect good
performing.<br>
<br>
Just for record:<br>
Performance tuning/scaling makes different. Much different.<br>
<br>
1. You require to set good initial approximation. Not by
proportion "1 user - 1 child instance".<br>
2. Then run your load and get performance statistics.<br>
3. Analyze results.<br>
4. Based on step 3, increasing/decreasing parameter value.<br>
<br>
General rule: change only one parameter during tuning/scaling
iteration.<br>
</span></span><span id="result_box" class="" lang="en"><span
class=""></span></span>
<blockquote type="cite"
cite="mid:113632435.70726986.1521622553336.JavaMail.root@zimbra4-e1.priv.proxad.net">
<pre wrap="">
sslproxy_capath /etc/ssl/certs/
sslproxy_foreign_intermediate_certs /etc/squid/ssl_certs/imtermediate.ca.pem
acl step1 at_step SslBump1
ssl_bump peek step1 all
ssl_bump splice nobump
ssl_bump bump all
Maybe there is a problem with memory, but as you can see here CPU is the point </pre>
</blockquote>
Yes, indeed. You eat up too much RAM due to misconfiguration. But
also you have 2 waiting points descrived above.<br>
<br>
I can recommend you get wait CPU/IO performance events to make sure.<br>
<br>
Wait IO events can increasing CPU consumption, when such structures
of queues overflows etc. Usually this occurs on thread-aware apps
with spin-count synchronization mech, however, often can occurs on
single-threaded applications depenging implementation.<br>
<blockquote type="cite"
cite="mid:113632435.70726986.1521622553336.JavaMail.root@zimbra4-e1.priv.proxad.net">
<pre wrap="">
top - 09:50:04 up 16:16, 1 user, load average: 1,72, 1,78, 1,39
Tasks: 393 total, 3 running, 390 sleeping, 0 stopped, 0 zombie
%Cpu(s): 8,4 us, 1,2 sy, 0,0 ni, 89,6 id, 0,3 wa, 0,0 hi, 0,5 si, 0,0 st
KiB Mem: 66086692 total, 28654240 used, 37432452 free, 2974568 buffers
KiB Swap: 1952764 total, 0 used, 1952764 free. 17653336 cached Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
9803 squid 20 0 3913044 3,452g 13464 R 99,9 5,5 7:47.47 squid
10051 e2guard+ 20 0 0,122t 284392 5124 S 25,6 0,4 1:33.10 e2guardian
9804 squid 20 0 21956 5628 4420 S 7,3 0,0 0:48.93 ssl_crtd
9805 squid 20 0 21952 5672 4372 S 6,3 0,0 0:31.25 ssl_crtd
9806 squid 20 0 21952 5476 4252 S 2,7 0,0 0:19.10 ssl_crtd
9807 squid 20 0 21952 5616 4408 S 2,3 0,0 0:13.88 ssl_crtd
9808 squid 20 0 21952 5540 4332 S 2,3 0,0 0:10.59 ssl_crtd
9810 squid 20 0 21956 5536 4332 S 2,0 0,0 0:05.61 ssl_crtd
9809 squid 20 0 21952 5584 4372 S 1,7 0,0 0:07.40 ssl_crtd
9996 squid 20 0 25612 2924 2696 S 1,3 0,0 0:05.47 diskd
9995 squid 20 0 25612 2744 2516 S 1,0 0,0 0:04.41 diskd
9811 squid 20 0 21964 5588 4372 S 0,7 0,0 0:03.72 ssl_crtd
9813 squid 20 0 21848 5660 4464 S 0,7 0,0 0:01.96 ssl_crtd </pre>
</blockquote>
As you can see, your Squid's consumes most CPU. And __not__
ssl_crtd. So, most probably you have bottleneck between squid and
ssl_crtd due to reasons above.<br>
<blockquote type="cite"
cite="mid:113632435.70726986.1521622553336.JavaMail.root@zimbra4-e1.priv.proxad.net">
<pre wrap="">
Amos, there is way to add the domain requested in message like this ?
2018/03/21 09:45:30| Error negotiating SSL on FD 1835: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed (1/-1/0)
2018/03/21 09:45:30| Error negotiating SSL on FD 4782: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed (1/-1/0)
It can be very, very, useful for analysis
Thanks
FredB
_______________________________________________
squid-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.org</a>
<a class="moz-txt-link-freetext" href="http://lists.squid-cache.org/listinfo/squid-users">http://lists.squid-cache.org/listinfo/squid-users</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
"C++ seems like a language suitable for firing other people's legs."
*****************************
* C++20 : Bug to the future *
*****************************</pre>
</body>
</html>