[squid-users] Optimizing squid

Wed Feb 24 20:51:33 UTC 2016

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

It's simple. It is strange that you do not understand. Do you have a
thread on the CPU, the pending IO. Then comes another one. Third. Do you
think that makes the OS? It unloads it in a swap? Ha ha, with several
tens of gigabytes of RAM you have not found it necessary to create a
swap. Or the OS does not unload the active processes in the swap. What's
next? CPU becomes like a juggler with 600 oranges. He will sweat as you
think? The problem is compounded by the virtual environment. It has its
own cache? How it works with cache synchronization guest?

This is performance for dummies.

I've already told you, you need to look at what direction. To do it or
not - at your wish.

25.02.16 2:40, Heiler Bemerguy пишет:
>
> Not to mention only 10GB of cache is almost useless for us... lol
>
> 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

Can you believe even in God. Squid makes heavy use of input-output and
keep in mind processors are directly connected with the input-output
subsystem.
>
> Why would it show a process using cpu while actually it's waiting for
a I/O.. ?

I told you. Use more appropriate tool than top itself to investigate
bottleneck. You can't see it directly.

>
> Best Regards
>
> --
> Heiler Bemerguy - (91) 98151-4894
> Assessor Técnico - CINBESA (91) 3184-1751
>
> Em 24/02/2016 17:13, Yuri Voinov escreveu:
> AFAIK, if you solve issue with cache_mem 10 GB and completely disabled
> disk cache, then you had disk IO bottleneck exactly. You completely
> disable disk caches. So, all obvious now.
>
> But - what you will do after squid restart? :))))))))))))) A deadly cold
> memory cache, hehehe
>
> 25.02.16 1:44, Heiler Bemerguy пишет:
> >>> Hi Eliezer, thanks for your reply.
> >>>
> >>> As you've suggested, I removed all cache_dirs to verify if the rest
> was stable/fast and raised cache_mem to 10GB. I didn't disable access
> logs because we really need it..
> >>> And it is super fast, I can't even notice it using only ONE core..
> (and it isn't running as smp)
> >>> %Cpu0  :  0,7 us,  1,0 sy,  0,0 ni, 98,3 id,  0,0 wa,  0,0 hi,  0,0
> si,  0,0 st
> >>> %Cpu1  :  8,8 us,  5,6 sy,  0,0 ni, 76,1 id,  0,0 wa,  0,0 hi,  9,5
> si,  0,0 st
> >>> %Cpu2  :  8,7 us,  4,0 sy,  0,0 ni, 83,3 id,  0,0 wa,  0,0 hi,  4,0
> si,  0,0 st
> >>> %Cpu3  :  5,4 us,  3,4 sy,  0,0 ni, 86,2 id,  0,0 wa,  0,0 hi,  5,0
> si,  0,0 st
> >>> %Cpu4  :  7,8 us,  5,1 sy,  0,0 ni, 73,5 id,  6,8 wa,  0,0 hi,  6,8
> si,  0,0 st
> >>> %Cpu5  :  1,0 us,  1,0 sy,  0,0 ni, 98,0 id,  0,0 wa,  0,0 hi,  0,0
> si,  0,0 st
> >>>   PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+ COMMAND
> >>> 11604 proxy     20   0 11,6g  11g 5232 S  48,4 72,2  72:31.24 squid
> >>>
> >>> Start Time:     Wed, 24 Feb 2016 15:38:59 GMT
> >>> Current Time:   Wed, 24 Feb 2016 19:18:30 GMT
> >>> Connection information for squid:
> >>>         Number of clients accessing cache:      1433
> >>>         Number of HTTP requests received:       2532800
> >>>         Average HTTP requests per minute since start:   11538.5
> >>>         Select loop called: 68763019 times, 0.192 ms avg
> >>>         Storage Mem size:       9874500 KB
> >>>         Storage Mem capacity:   94.2% used,  5.8% free
> >>>
> >>> I don't think I had a bottleneck on I/O itself, maybe the hash/search
> of cache indexes was too much for a single thread?
> >>> Best Regards,
> >>>
>>
>>
>>
>> _______________________________________________
>> squid-users mailing list
>> squid-users at lists.squid-cache.org
>> http://lists.squid-cache.org/listinfo/squid-users
>
>
>
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJWzhfUAAoJENNXIZxhPexGlloIALSld4PZGTKbdAdQFHntDKkz
7tWH69kRPRUh7aSmQKmedqrEDXnz4N/dnWOvfzw3IGkpXPUqRk3OtJTpve/iC8Tz
TPUSETRAyedYm8OT1hwzqcdQ04AykFjB6Kg+cGn0eAtkruhviHDIbMiB9bMyAi2E
WURGPqLkzPjKJzuHPWkLfE1tg82lOyybBIL0fC5gDG45Yb4yIykVNjQA829LdQah
orh/iBSWV0OUSm9FXgbowXfNniBAiJohJbv9Ykux+uSEaQhlPm3/nXdRrl4yliYR
iamYe/JiBNKeKaF1GdwwSvUzYRdmXfN32HaEaCLrpu6UtOFpctSY+e2fu+AHb2c=
=vNyO
-----END PGP SIGNATURE-----

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20160225/4abaed1c/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x613DEC46.asc
Type: application/pgp-keys
Size: 2437 bytes
Desc: not available
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20160225/4abaed1c/attachment-0001.key>