libpurple in server

[Mark Doliner]

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

-Mark