libpurple in server
mark at kingant.net
Fri Jun 1 03:38:52 EDT 2007
On Fri, 1 Jun 2007 09:41:33 +0400, Alexey Nezhdanov wrote
> On Friday 01 June 2007 09:26, Ethan Blanton wrote:
> > Christopher Baus spake unto us the following wisdom:
> > > I'm currently working on such a project. I think the only potential
> > > issue is handling the single threaded event loop in a scalable manner.
> > > For instance doing I/O when handling messages is going to block the
> > > entire glib event distribution until the I/O completes. This will result
> > > in poor CPU and I/O utilization.
> > So, while this is true at some level, you should be able to handle an
> > awful lot of IM connections before this becomes a problem. Most of
> > your I/O will be simple buffer reads and writes, and the only real
> > cost you'll pay is the system call overhead. (Disk I/O in libpurple
> > is about the only thing which might degenerate into something other
> > than a buffer read or write, as it is blocking.)
> > If you're wanting to serve thousands of IM accounts at the same time,
> > you'll certainly have to do something about this ... if you're wanting
> > to serve dozens or hundreds (for a small company or school, say), I
> > doubt this will become a problem. Threads are not necessary nearly as
> > often as people like to think. :-)
> I am working on such application too.
> The biggest problem that we are coping with atm is memory leak. One
> hundred accounts online gives about 70-100M RSS increase per hour.
> Also CPU consumption starts increasing and drops only when we
> restart the serverside component so it returns to much lower RSS and
> CPU usage. If anybody can give any hint how to catch these leaks -
> it will be very helpful. So far we wasn't able to find the source of
> such perfomance. We used 1.3.0 then beta2 then beta6 (and up to
> present moment). Leak was always present, just currently it become a
> problem as number of users rising.
I've found valgrind to be incredibly helpful in tracking down memory leaks.
valgrind --tool=memcheck --leak-check=full pidgin 2> /tmp/pidgin_valgrind_log.txt
More information about the Devel