[squid-users] Optimizing squid
Heiler Bemerguy
heiler.bemerguy at cinbesa.com.br
Wed Feb 24 20:40:10 UTC 2016
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
Why would it show a process using cpu while actually it's waiting for a
I/O.. ?
Best Regards
--
Heiler Bemerguy - (91) 98151-4894
Assessor Técnico - CINBESA (91) 3184-1751
Em 24/02/2016 17:13, Yuri Voinov escreveu:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> 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,
>>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQEcBAEBCAAGBQJWzg7aAAoJENNXIZxhPexG/1MIAJnQdPpdH3OvlkNrHhdEf+bm
> CrjM6BCvsADHW9udmeH4jS/U3ko4iLI/oayQELIP3WoH+hQ5pszyp8u0zfDfUkn6
> s4vFOOvgSUmPxn70FQhFX93z6IhySFkKHiSvUMuN/2prH86pFz3J6+byxUMySKoU
> lXkImzeFVBHJLMaaVOlAZ1SwJUVb2LhUgoY7GesK7gT2mW09phFGG9I/3Sz+0Jmx
> fYkZBZLPMoIPNknJqlebsv/s8CaQ3Vb4bpstLZgVNxlBX0UmW7Ohu7cNOrTFXovb
> ooojx4nsDl8esDfrfJ/NSBVuxi7vO7jAP82gqkoJB3qQkHtAi6O66Qvr5gSBt7s=
> =/h/N
> -----END PGP SIGNATURE-----
>
>
>
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20160224/725d1c90/attachment.html>
More information about the squid-users
mailing list