Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 02 Jan 2012 16:21:27 -0500
From:      Robert Boyer <rwboyer@mac.com>
To:        Eduardo Morras <nec556@retena.com>
Cc:        "Muhammet S. AYDIN" <whalberg@gmail.com>, freebsd-questions@freebsd.org
Subject:   Re: freebsd server limits question
Message-ID:  <AD321296-15AC-493D-9885-DE29A70DA33B@mac.com>
In-Reply-To: <0LX600GBUUP8AWE1@ms02044.mac.com>
References:  <CAP28s1DhhsSV%2Bz8BuRDVjHypD%2BpECuXQEH5BKjJRKMorcWL0rw@mail.gmail.com> <0LX600GBUUP8AWE1@ms02044.mac.com>

next in thread | previous in thread | raw e-mail | index | archive | help
To deal with this kind of traffic you will most likely need to set up a =
mongo db cluster of more than a few instances=85 much better. There =
should be A LOT of info on how to scale mongo to the level you are =
looking for but most likely you will find that on ruby forums NOT on =
*NIX boards=85.

The OS boards/focus will help you with fine tuning but all the fine =
tuning in the world will not solve an app architecture issue=85

I have setup MASSIVE mongo/ruby installs for testing that can do this =
sort of volume with ease=85 the stack looks something like this=85.

Nginix=20
Unicorn
Sinatra
MongoMapper
MongoDB

with only one Nginix instance can feed an almost arbitrary number of =
Unicorn/Sinatra/MongoMapper instances that can in turn feed a properly =
configured MongoDB cluster with pre-allocated key distribution so that =
the incoming inserts are spread evenly against the cluster instances=85

Even if you do not use ruby that community will have scads of info on =
scaling MongoDB.

One more comment related to L's advice - true you DO NOT want more =
transactions queued up if your back-end resources cannot handle the TPS =
- this will just make the issue harder to isolate and potentially make =
the recovery more difficult. Better to reject the connection at the =
front-end than take it and blow up the app/system.

The beauty of the Nginix/Unicorn solution (Unicorn is ruby specific) is =
that there is no queue that is feed to the workers when there are no =
workers - the request is rejected. The unicorn worker model can be =
reproduced for any other implementation environment (PHP/Perl/C/etc) =
outside of ruby in about 30 minutes. It's simple and Nginix is very well =
suited to low overhead reverse proxy to this kind of setup.

Wishing you the best - if i can be of more help let me know=85

RB

On Jan 2, 2012, at 3:38 PM, Eduardo Morras wrote:

> At 20:12 02/01/2012, Muhammet S. AYDIN wrote:
>> Hello everyone.
>>=20
>> My first post here and I'd like to thank everyone who's involved =
within the
>> FreeBSD project. We are using FreeBSD on our web servers and we are =
very
>> happy with it.
>>=20
>> We have an online messaging application that is using mongodb. Our =
members
>> send messages to "the voice" show's (turkish version) contestants. =
Our two
>> mongodb instances ended up in two centos6 servers. We have failed. So =
hard.
>> There were announcements and calls made live on tv. We had +30K/sec
>> visitors to the app.
>>=20
>> When I looked at the mongodb errors, I had thousands of these:
>> http://pastie.org/private/nd681sndos0bednzjea0g. You may be wondering =
why
>> I'm telling you about centos. Well, we are making the switch from =
centos to
>> freebsd FreeBSD. I would like to know what are our limits? How we can =
set
>> it up so our FreeBSD servers can handle min 20K connections =
(mongodb's
>> connection limit)?
>>=20
>> Our two servers have 24 core CPUs and 32 GBs of RAM. We are also very =
open
>> to suggestions. Please help me out here so we don't fail deadly, =
again.
>>=20
>> ps. this question was asked in the forums as well however as someone
>> suggested in the forums, i am posting it here too.
>=20
> Is your app limited by cpu or by i/o? What do vmstat/iostat says about =
your hd usage? Perhaps mongodb fails to read/write fast enough and =
making process thread pool bigger only will make problem worse, there =
will be more threads trying to read/write.
>=20
> Have you already tuned mongodb?
>=20
> Post more info please, several lines (not the first one) of iostat and =
vmstat may be a start. Your hd configuration, raid, etc... too.
>=20
> L=20
>=20
> _______________________________________________
> freebsd-questions@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to =
"freebsd-questions-unsubscribe@freebsd.org"




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AD321296-15AC-493D-9885-DE29A70DA33B>