-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Michel,
On Sun, 12 Aug 2007 17:51:06 -0300 (BRT) "Michel Santos" <[EMAIL PROTECTED]> wrote: > > Tek Bahadur Limbu disse na ultima mensagem: > > > > > Ok let me upgrade my memory before setting it to 2 GB or more. > > I will set it to 768 MB for now since I have only 1 GB of memory at the > > moment. > > > > I believe with stock maxdsiz your squid process can not use more than the > 512MB limit ... so I do not know where you get 600 from > > maxdsiz is not only RAM related but defines the upper limit of memory a > process can use and so I believe your machine does not swap even if not > exist RAM enough for the process (generally) but enough to get to the > limit (maxdsiz) and that might be the reason your squid process crash when > it tries to use more than the 512 limit Well I remember seeing the number 600 at one time. For now "top" shows: PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 629 squid 1 96 0 472M 466M RUN 0 70:50 11.38% squid 681 squid 1 -8 0 5160K 1204K biord 1 2:49 0.00% diskd-daemon 680 squid 1 -4 0 5160K 1200K msgwai 0 2:42 0.00% diskd-daemon Let me monitor this process for a few days. I think it will cross the 512 mark but I am not sure how! > > > > >> > >> other values I saw are eventually not so good choices, as somaxconn > >> seems > >> way to high and nbmclusters are 0 ? > > > > Well I will reduce somaxconn to 8192. The reason why I set nbmclusters > > to 0 is because of satellite link delays and high number of tcp > > connections, I run out of mbufs. They easily reach between 64000 - > > 128000 and sometimes even more. Every now and then, I would lose tcp > > connections due to the high number of mbufs in use. So I found this > > little hack which keeps the number of mbufs utilization at bay. > > > > what size is your link? For each proxy, the link is burstable upto to 15 mbps. But they are grouped together in different groups. We have 6 groups. Each group has bandwidth ranging from 5 mbps to 20 mbps. However since our link comes via satellite, the proxies starts building a large number of mbufs especially when our uplink gets saturated. Since it's a satellite link, bandwidth is never enough no matter how big we are subscribing. We still have some time to go (maybe months, or years) before we get it from a fiber link. > > Sure this is not related to your crash and to your link either but > somaxconn is the queue size of pending connections and not the number of > connections and you are probably setting this far too high. somaxconn as > 1024 or max 2048 would be more reasonable and nmbcluster I would not set > higher than 128 or 256k > > if you eat that up you have other troubles and increasing this values does > not solve them I guess Well I am using nmbcluster = 256000 on some of my FreeBSD-6.2 machines because they don't support setting the nmbcluster to 0. Well let me try setting somaxconn to 2048. - From my observation in recent months, the mbufs value has not crossed 120K. I will probably use 128K or 256K. I read an article regarding setting somaxconn=32768 to help stop SYN flooding. http://silverwraith.com/papers/freebsd-ddos.php In your opinion, what's wrong with setting nmbcluster to 0 since, in this way, I never run out of mbufs? By the way, do you have some more special tweaks for FreeBSD systems? For example, I am using some values like the one below: kern.ipc.nmbclusters=256000 kern.maxfiles=16384 kern.maxfilesperproc=8192 net.inet.icmp.icmplim=0 net.inet.ip.fw.dyn_keepalive=0 net.inet.tcp.msl=2000 net.inet.tcp.recvspace=32768 net.inet.tcp.sendspace=32768 net.inet.ip.fw.dyn_keepalive=1 Can you comment on the above values? Thanking you... > > > > > michel > ... > > > > > **************************************************** > Datacenter Matik http://datacenter.matik.com.br > E-Mail e Data Hosting Service para Profissionais. > **************************************************** > > - -- With best regards and good wishes, Yours sincerely, Tek Bahadur Limbu (TAG/TDG Group) Jwl Systems Department Worldlink Communications Pvt. Ltd. Jawalakhel, Nepal -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGv/zgfpE0pz+xqQQRAgU9AKCoXXP3W0gWIniWnDkOADrn9QPAyACeOBP7 mrr2LZACgIl5BJrYaTaDAO4= =KqO0 -----END PGP SIGNATURE-----
