Re: Optimizing squid

[Heiler Bemerguy <heiler.bemerguy@xxxxxxxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users

_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users