<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
-----BEGIN PGP SIGNED MESSAGE----- <br>
Hash: SHA256 <br>
<br>
But you can continue to think that the problem is in the Squid. :)
And keep looking for a magical setting configuration. :)<br>
<br>
25.02.16 2:40, Heiler Bemerguy пишет:<br>
<span style="white-space: pre;">><br>
> Not to mention only 10GB of cache is almost useless for us...
lol<br>
><br>
> But I still think cpu is cpu and i/o is i/o. "WAIT" fields on
both TOP and VMSTAT shows almost always a ZERO<br>
><br>
> Why would it show a process using cpu while actually it's
waiting for a I/O.. ?<br>
><br>
> Best Regards<br>
><br>
> -- <br>
> Heiler Bemerguy - (91) 98151-4894<br>
> Assessor Técnico - CINBESA (91) 3184-1751<br>
><br>
> Em 24/02/2016 17:13, Yuri Voinov escreveu:<br>
> AFAIK, if you solve issue with cache_mem 10 GB and completely
disabled<br>
> disk cache, then you had disk IO bottleneck exactly. You
completely<br>
> disable disk caches. So, all obvious now.<br>
><br>
> But - what you will do after squid restart? :))))))))))))) A
deadly cold<br>
> memory cache, hehehe<br>
><br>
> 25.02.16 1:44, Heiler Bemerguy пишет:<br>
> >>> Hi Eliezer, thanks for your reply.<br>
> >>><br>
> >>> As you've suggested, I removed all cache_dirs to
verify if the rest<br>
> was stable/fast and raised cache_mem to 10GB. I didn't
disable access<br>
> logs because we really need it..<br>
> >>> And it is super fast, I can't even notice it
using only ONE core..<br>
> (and it isn't running as smp)<br>
> >>> %Cpu0 : 0,7 us, 1,0 sy, 0,0 ni, 98,3 id,
0,0 wa, 0,0 hi, 0,0<br>
> si, 0,0 st<br>
> >>> %Cpu1 : 8,8 us, 5,6 sy, 0,0 ni, 76,1 id,
0,0 wa, 0,0 hi, 9,5<br>
> si, 0,0 st<br>
> >>> %Cpu2 : 8,7 us, 4,0 sy, 0,0 ni, 83,3 id,
0,0 wa, 0,0 hi, 4,0<br>
> si, 0,0 st<br>
> >>> %Cpu3 : 5,4 us, 3,4 sy, 0,0 ni, 86,2 id,
0,0 wa, 0,0 hi, 5,0<br>
> si, 0,0 st<br>
> >>> %Cpu4 : 7,8 us, 5,1 sy, 0,0 ni, 73,5 id,
6,8 wa, 0,0 hi, 6,8<br>
> si, 0,0 st<br>
> >>> %Cpu5 : 1,0 us, 1,0 sy, 0,0 ni, 98,0 id,
0,0 wa, 0,0 hi, 0,0<br>
> si, 0,0 st<br>
> >>> PID USER PR NI VIRT RES SHR S %CPU
%MEM TIME+ COMMAND<br>
> >>> 11604 proxy 20 0 11,6g 11g 5232 S 48,4
72,2 72:31.24 squid<br>
> >>><br>
> >>> Start Time: Wed, 24 Feb 2016 15:38:59 GMT<br>
> >>> Current Time: Wed, 24 Feb 2016 19:18:30 GMT<br>
> >>> Connection information for squid:<br>
> >>> Number of clients accessing cache:
1433<br>
> >>> Number of HTTP requests received:
2532800<br>
> >>> Average HTTP requests per minute since
start: 11538.5<br>
> >>> Select loop called: 68763019 times,
0.192 ms avg<br>
> >>> Storage Mem size: 9874500 KB<br>
> >>> Storage Mem capacity: 94.2% used,
5.8% free<br>
> >>><br>
> >>> I don't think I had a bottleneck on I/O itself,
maybe the hash/search<br>
> of cache indexes was too much for a single thread?<br>
> >>> Best Regards,<br>
> >>><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> squid-users mailing list<br>
>> <a class="moz-txt-link-abbreviated" href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.org</a><br>
>> <a class="moz-txt-link-freetext" href="http://lists.squid-cache.org/listinfo/squid-users">http://lists.squid-cache.org/listinfo/squid-users</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> squid-users mailing list<br>
> <a class="moz-txt-link-abbreviated" href="mailto:squid-users@lists.squid-cache.org">squid-users@lists.squid-cache.org</a><br>
> <a class="moz-txt-link-freetext" href="http://lists.squid-cache.org/listinfo/squid-users">http://lists.squid-cache.org/listinfo/squid-users</a></span><br>
<br>
-----BEGIN PGP SIGNATURE-----
<br>
Version: GnuPG v2
<br>
<br>
iQEcBAEBCAAGBQJWzhg0AAoJENNXIZxhPexGeYMH/A2H5roWWgZBm8ZzyxnN11Aw
<br>
Otc6OpWWCU+3fzsuM/AyJMd1Fi+sZ1BU4yEAGtorEJ68fvPguLukK+cU8ezOUJ4D
<br>
5O0YXxeuha+bbL/yIHW3/8B8NHi4EEN39E3f00DGU8lD8H9xJtYOL6bf/oUlYue7
<br>
IWa3anQZmQa6QFz/ZIWUZ8hatWk3zyXmF5zR2joODP/Ej47RwJ+TWshVgX6SZQKP
<br>
C0CeY8wYbLG9PZOmtJc4S9FMKRM+F+7OzP1hvflMpV2+8zhCyPVD0JUfFJF8mKq+
<br>
9BPVooIv5XKhv3KRJjcFomUvQqBrLJ8eJai6NQyqX24iRq/GmCQIgyvT+dhae9A=
<br>
=uwlY
<br>
-----END PGP SIGNATURE-----
<br>
<br>
</body>
</html>