On 1/08/2013 8:20 p.m., Ahmad wrote:
hi pavel ,
thanks alot for clarification ,
i think that after reading the article about memory usage , i think that my
squid box is not getting the benefit of my rams (48G)
i have 3 hardsisk each one im obtainging 90 G for cache dir ,
cache_dir aufs /cache1 90000 32 256
cache_dir aufs /cache2 90000 32 256
cache_dir aufs /cache3 90000 32 256
so if i calculate ram dissipation for cache_dir it will be about 15 * (90
* 3) = 4050 M from main memory assume *5G*
again my total memory is 48 G
also i put cache_mem = 1000 which is *1 G *
assume another margin with *5 G at most*
so , my memory usage is 5+1+5 = 11 G from 48 G
*my question is ,*
should i increase cache_mem value ???? or increase cache_dir space ????
Try adding a rock type cache_dir next. That will improve the response
speed for under-32KB objects a fair bit.
also , should i find a better performance after that ???
Better question is what your performance currently is?
Are you certain that memory is the biggest cause of low performance in
your proxy?
And the answer:
again , my machine is being pumped with 350 M with about 2300 Users.
By 350M from X users I assume you means 350Mbps ??
When it comes to bandwidth throughput Squid is quite limited by the
process of parsing HTTP. This is the main limiter we find in high
performance situations.
I tend to find one Squid process able to handle 50-150 Mbps reliably
well, depending on the request/second rate that exists within that
traffic. The more req/sec there are the slower the Mbps rate handled is.
If you are already getting 350Mbps out of it, _very_ well done.
I suggest your next step (after adding a rock cache_dir) is to attempt
enabling SMP support for 3 or 4 workers. Your analysis of the memory
needs shows that the box can handle them. Each worker will use the
amount you calculated above.
Amos
