-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tue, 20 Mar 2007 00:37:53 -0300 (BRT) "Michel Santos" <michel@xxxxxxxxxxxxxx> wrote: > > > > > You can add kern.maxfilesperproc=8192 in /etc/sysctl.conf to increase your > > squid file descriptors to 8192. > > You may also have to change your kern.maxfiles parameter to say about 8192 > > or 16384. > > > > all this sugestions are kind of high, hardly you get over 2000 open files > unless you have a heavy loaded server, this starts somewhere over 6-10mb/s > sustained http througput when you may need more open files Hi Michel, My proxy servers do handle high active connnections during peak hours. Currently one of it is using about 4600 file descriptors. As Chris pointed out it might be due to high latency because our bandwidth comes through satellite and my proxy server is utilizing 8 mbps traffic currently. > > when you use coss you do not get even close to half of it I am using COSS and it works flawlessly at present. > > on FBSD you ever should query your system as with sysctl kern.openfiles to > see what is going on and then when *really* coming to the limit you might > like to raise it a little and otherwise not kern.openfiles shows 4318. > > > > Well if your proxy serves less than 30 requests per second, then ufs > > storage is fine. However if your demands are above 30 requests per second, > > then either diskd and aufs will be good. However you may need to tweak > > your kernel to implement diskd for FreeBSD. > > > > you say it so easy as if were that easy, firstable what your machine > supports and needs is relative to the machine's processing power. There is > no such 30 req/sec limit or switch-over-rule ... I admit there is no such rule but I am using it as a base for measurement and comparison. Obviously, req/sec is an easier and a better unit than say open_files/sec. > > but I agree, on FreeBSd you might consider diskd but the difference is > small and depends on the machine and the throughgoing http-traffic and if > your HD can really take the load (or better: answer the requests in time) > > so my opinion hear is using ufs is good and stable and fits high load for > whom is not a specialist in system fine tuning, if you are knowing nasty > kernel stuff *and* have really nasty hardware and like to get the most out > of it then you should go diskd - but - better having a perfect UPS and a > server which never crashs, you may loss your cache content, anyway it's a > long way to get this 5-10% more (in comparism to ufs) Well I am saying this based on our proxy servers using ufs, diskd, aufs and coss. Usually median service time indicates the browsing speed and after alot of data collection, miss median service time's value has predicted our overall bandwidth utilization quite accurately and also the browsing speed. Our proxy servers using COSS usually gives the less amount of miss median service time. I have read articles and posts regarding ufs and they do suggest that ufs usually peaks out at 30-40 requests per second. However I have not really performed rigorous tests and benchmarks regarding ufs so I could be a little biased here. > > aufs? hands off Alot of people including myself are using aufs. However we are not using it extensively. > > > > Try using these in your kernel config file: > > > > options MSGMNB=8192 # max # of bytes in a queue > > options MSGMNI=40 # number of message queue identifiers > > options MSGSEG=512 # number of message segments per queue > > options MSGSSZ=64 # size of a message segment > > options MSGTQL=2048 # max messages in system > > > > options SHMSEG=16 > > options SHMMNI=32 > > options SHMMAX=2097152 > > options SHMALL=4096 > > > this values might be kind of unreasonable but probably does not influence > anything depending on your load, so you may not see if it is or not is > unless you monitor SHM and MSG on your system. So I believe when you can > live with SHMSEG=16 you do not need to set anything at all, it is lower > than FreeBSD's default These complied values are working for my servers up till now. Well I once had a problem regarding diskd without the above compilation options. But that was long ago and you may be right that I won't see any difference with or without it. > > btw setting SHMMAX is old stuff, you should set SHMMAXPGS which adjust > automatically SHMMAX considering the other tweaked SHM values, if you do > it your way you may find undesired behaviour > > anyway ipc.* are tunables so you do *not* need to compile them into your > kernel I will test it in near future just by tweaking the tunables. > > if you want to tune diskd read first a lot of postgres sql tuning matter > which are the only lonly guys which seem ever having worked serious > (except me of course ;) ) with this IPC stuff on FreeBSD. What you find on > squid's website regarding FreeBSD makes diskd work on old versions but not > tuned. I will read about them in the future.:) And thanks for your feedback and suggestions. > > > > > 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 http://www.wlink.com.np -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (FreeBSD) iD8DBQFF/++UVrOl+eVhOvYRAldUAJ4grNWsF83Au4oxGxBjAjlIM2zZqgCfcIu+ iLaEFf2/ugY/sNozV7e8sng= =E41W -----END PGP SIGNATURE-----
