[squid-users] SSLBump, system requirements ?
Yuri
yvoinov at gmail.com
Wed Mar 21 12:56:41 UTC 2018
21.03.2018 14:55, FredB пишет:
>>> Perhaps I should retry SMP but unfortunately in the past I had many
>>> issues with, and some features I'm using still SMP-unaware
>> Squid's SMP itself does not solves SSL Bump issues. It's about
>> different
>> things, and, IMHO, irrelevant your load profile.
>
> 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 ?
200 users, 2 Gbps downstream.
>
> 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
It does not work that way. There are still many processes. Scaling is
rarely linear.
Pls keep in mind, squid itself is thread-unaware. So, with thousands of
children you make serialization point by yourself from squid's size.
Another serialization point is SSL db on disk, due to it uses file
locking mechanism.
Both reasons leads to make bottleneck on SSL certgen processes.
So, you can't simple set 1000 children and expect good performing.
Just for record:
Performance tuning/scaling makes different. Much different.
1. You require to set good initial approximation. Not by proportion "1
user - 1 child instance".
2. Then run your load and get performance statistics.
3. Analyze results.
4. Based on step 3, increasing/decreasing parameter value.
General rule: change only one parameter during tuning/scaling iteration.
>
> 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
Yes, indeed. You eat up too much RAM due to misconfiguration. But also
you have 2 waiting points descrived above.
I can recommend you get wait CPU/IO performance events to make sure.
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.
>
> 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
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.
>
>
> 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
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
--
"C++ seems like a language suitable for firing other people's legs."
*****************************
* C++20 : Bug to the future *
*****************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20180321/35830dcb/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: OpenPGP digital signature
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20180321/35830dcb/attachment.sig>
More information about the squid-users
mailing list