Tek Bahadur Limbu disse na ultima mensagem: > Michel Santos wrote: >> Tek Bahadur Limbu disse na ultima mensagem: >>> diskd indeed seems to fail under load especially when approaching >>> 200/300 requests per second. >> >> are you sure this numbers are correct? where do you get them from? > > Hi Michel, > > I am getting these numbers from one of my busy proxy server. At peak > times, I get anywhere from 150-200 requests per second. However to cross > the 300 mark, it only happens when 1 or 2 of my other proxy servers go > down and then our load balancer redirects web requests to whichever > proxy server is up and functioning. > so you get 12000/min right? But when I asked where you get them from I wanted to know how you count them, snmp? cachemgr? how much mem the server has installed? > > I guess that I may have to really commit my time and resources to find > out if other factors could be causing this to happen. > > Haven't you faced any automatic restart of your Squid process. Does that > mean that your Squid process uptime is months? > never dies by it's own, my problem are power problems and loose human endpoints (fingers) :) what is you kern.maxdsiz value? How much memory squid is using just before it crashs? is it using swap? what ipcs tells you then or under load? > > They have been in production for years and each of their average uptime > is about 120 days. As far as the load is concerned, my CPU usage never > goes above 30-40% but sometimes my memory usage crosses 80% of it's > capacity though. > what hardware is it? Which freebsd version your run? And how is your layout, standalone proxy server, gateways or cache hierarchy? > By the way, do you have some optimal settings which can be applied to > diskd? Below are some values I use: > > options SHMSEG=128 > options SHMMNI=256 > options SHMMAX=50331648 # max shared memory segment size (bytes) > options SHMALL=16384 # max amount of shared memory (pages) > options MSGMNB=16384 # max # of bytes in a queue > options MSGMNI=48 # number of message queue identifiers > options MSGSEG=768 # number of message segments > options MSGSSZ=64 # size of a message segment > options MSGTQL=4096 # max messages in system > > Correct me where necessary. > that does not say so much, better you send what comes from sysctl kern.ipc anyway you probably should not limit SHMMAX but set SHMMAXPGS so then SHMMAX is correctly calculated and no need to compile them, that are sysctl tunables I believe any wrong value would not make your server crash, worst case that your msg queues get stucked what would then put squid's disk r/w access on hold but not to crash, well, let say I never saw a server crashing for ipc congestion, the client simply stops communicating Michel ... **************************************************** Datacenter Matik http://datacenter.matik.com.br E-Mail e Data Hosting Service para Profissionais. ****************************************************
