How are you doing the memory profiling? That's incredible :)
![[User Picture]](http://l-userpic.livejournal.com/54541970/2) | From: brad 2006-06-27 05:15 am (UTC)
| (Link)
|
Gtop for these measurements, but as part of the slimming process: a lot of Devel::Size, Devel::Peek, Data::Dumper and (as of today) Artur's new Devel::Gladiator.
Devel::Gladiator hahaha that rocks. What does it do?
![[User Picture]](http://l-userpic.livejournal.com/54541970/2) | From: brad 2006-06-27 04:49 pm (UTC)
| (Link)
|
Walks the arena.
That one publically available somewhere? Don't notice it on CPAN.
![[User Picture]](http://l-userpic.livejournal.com/54541970/2) | From: brad 2006-06-27 11:57 pm (UTC)
| (Link)
|
![[User Picture]](http://l-userpic.livejournal.com/4721253/164057) | From: xb95 2006-06-27 06:41 am (UTC)
| (Link)
|
You'll have to explain this to me - how the hell can you get 300,000 connections on a single machine? Won't it run out of fds?
Or can you set the max to something higher in the kernel? But then don't you run out of kernel fd memory?
From: (Anonymous) 2006-06-27 06:51 am (UTC)
| (Link)
|
Dude, autotuning of available fd's have been in linux since 2.6.
The short answer is: it should work.
Depending on the current system-wide limits, it might be necessary to bump them first. Something like:
cat /proc/sys/fs/file-max echo 1200000 > /proc/sys/fs/file-max Next, it will probably hit the per-process limit, usually 1024. You'll probably need to increase the hard limit first. This can be by adding the following lines to /etc/security/limits.conf:
* soft nofile 400000 * hard nofile 400000 You'll probably want to only apply this to a single user, perhaps your trusted friend foo:
foo soft nofile 400000 foo hard nofile 400000 Then, you can use the usual ulimit to adjust it per-session:
ulimit -n 400000
Unless there's a problem with the networking end of things, this should work just fine. I wrote a little test that fopen()-ed 300,000 files without trouble.
![[User Picture]](http://l-userpic.livejournal.com/43717921/4152185) | From: divelog 2006-06-27 06:50 am (UTC)
# XXX - Hack | (Link)
|
Hmm so did you fix the fugly exec call to ldapsearch I imagine :)
![[User Picture]](http://l-userpic.livejournal.com/54541970/2) | From: brad 2006-06-27 03:44 pm (UTC)
Re: # XXX - Hack | (Link)
|
Nope. That's just in the SixApart office subclass of DJabberd. I did change it to cache the company directory for an hour though, figuring we're hiring at less than one new employee per hour. :-)
Wow! Can I get just the vanilla c25k server framework, without jabberd?
![[User Picture]](http://l-userpic.livejournal.com/54541970/2) | From: brad 2006-06-27 04:50 pm (UTC)
| (Link)
|
That's just epoll. If you want to make event-based programs easily check out Danga::Socket or POE on CPAN.
unless there's some info I'm missing (like how many IPs the box has), you'll run out of ports before the 300k connections. IPv4 TCP is a bitch, but we gotta live with it until IPv6 TCP6 is a lot more mature (read: north american residental ISPs start offering IPv6).
![[User Picture]](http://l-userpic.livejournal.com/54541970/2) | From: brad 2006-06-27 03:42 pm (UTC)
| (Link)
|
Well, I'm not opening ephemeral ports. Port exhaustion is the client's problem.
Is DJabberd threaded (can Perl do threads?) or all entirely event-driven?
![[User Picture]](http://l-userpic.livejournal.com/54541970/2) | From: brad 2006-06-27 03:43 pm (UTC)
| (Link)
|
event-driven. Although child processes speaking over socketpairs (or processes elsewhere on the network speaking over tcp) can do slow blocking operations on behalf of the non-blocking event loop. Like database lookups, etc.
Cool, so it's multi-process with some method of inter-process communication. Very sexy.
LJ needs to open a New Jersey office, so I can apply to work there. For reals. :-)
woah. thats...awesome. wow.
You made me try to think of the twelve letter word for scalability that starts with c and ends with k, before I looked it up.
> [forget design pattern name] yeah- i don't know if it's been formalized- i call it a "handler pool"- in the (best known in apache as the threadpool) model of spawning an anticipated number of X-handlers and then using them as needed- of course, it's the event-driven interface behind them that enables the scalability, but it saves cycles and memory to have a semi-fixed number of objects there at all times, and sacrifice ultimate responsiveness for scalability- i'm currently adding such functionality to Io's socket interface :)
sounds like things are coming together. has anything panned out of your work with jive? (we use their open source server at work for company communications) |