[Mono-dev] Memory usage on Mono remoting

pablosantosluac at terra.es pablosantosluac at terra.es
Wed Jul 15 07:29:07 EDT 2009

Hi Gonzalo,

First, thanks for the detailed answers.

>> Considering Boehm GC seems to have really hard times releasing memory
>> and we're delivering GBs of data... it could be.
> Delivering GBs of data and having hundreds of connections should not be
> a problem. Years ago, when testing iFolder under those conditions
> everything worked just fine. But it was mod-mono-server/apache.
Dick is actually checking this. I hope it's not the issue.
>> I'm not 100% sure, but it seems reusing buffers could be a very good idea.
> Xsp does it too and it's much better than allocating 32kB for every
> request every time.
>> Also, you mentioned in a previous email that the TcpChannel should be
>> changed so it uses Asynch sockets. I've seen you use AsyncCallBack on XSP.
>> My question is: I guess AsynchCallback will use a thread underneath,
>> won't it? If so: what's the advantage over launching threads to accept
>> calls?
> Your guess is wrong. Those asynchronous calls from Socket are treated as
> if they were a WorkItem for a ThreadPool, only that when they are made,
> the socket is added to an epoll fd (if you're on linux with support for
> epoll). And when there's an event in the socket, there's a dedicated IO
> threadpool to take care of reading/writing data and invoking the
> callbacks. The advantages: if you have 10k connections, you don't need
> 10k threads, threads are reused (no creation overhead), ...
Ok, of course. Well, when I said "launching a thread" I really meant
"launching a thread on a thread pool".

Well, I'll try to use the ansync sockets then, but I guess to get the
best out of them I'll need not only to use them during accept, but also
read data asynchronously, right?

BTW, I already replaced the built-in remoting threadpool by the
System.Threading one.

>> You mentioned it is better to use the default ThreadPool instead of the
>> internal one in the TcpChannel, why is it going to be better?
> Coupled with asynchronous I/O, it will make better use of the resources
> available. There's no need to create 100 threads for 100 client or
> having 1 threadpool thread blocking on a socket asynchronous
> operation,... Also, if you're thinking of reusing buffers, this helps
> too, as the number of buffers will be bound to the maximum number of
> threads in the threadpool, ...
Good, so, whenever I wait for a read or a write using async, the thread
should be able to work on another request?

I think this is the way it's implemented on Windows, but I can tell you
it is still created a huge number of threads, almost 1-1 with clients
under the most overloaded scenarios.



> -Gonzalo

More information about the Mono-devel-list mailing list