-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Michel,
On Sun, 12 Aug 2007 17:51:06 -0300 (BRT)
"Michel Santos" <michel@lucenet.com.br> 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-----
Received on Mon Aug 13 2007 - 00:40:32 MDT
This archive was generated by hypermail pre-2.1.9 : Sat Sep 01 2007 - 12:00:03 MDT