Hi,
I just compiled the latest SVN head, and once again monotorrent works
perfectly (well, as perfectly as to be expected ;) ). No more crazy memory
usage, which means it was a mono bug after all. I just wish i knew what
exactly had gone wrong inside mono. For the amount of time i spent trying to
figure out what it was, i feel cheated that someone else fixed it before i
could ;)
Anyway, thanks for the help joe, i couldn't have gotten as far as i did
without you.
Alan.
On 3/31/07, Alan McGovern [EMAIL PROTECTED] wrote:
Ok, i did a quick bit of testing on my code.
Firstly, the 54 instances of SocketAsyncResult do make sense. Typically
there will *always* be a pending BeginReceive on every socket i have opened.
Therefore 54 instances of SocketAsyncResult would correspond to 54 open
connections, which is pretty standard stuff.
Every call to socket.BeginXXX or socket.EndXXX goes through a
TCPConnection class, so i added a count there so i could see how many calls
to each BeginXXX and EndXXX method i actually make. The results were pretty
much as expected. There was always a difference between BeginReceive and
EndReceive pretty much equal to the number of sockets i have open. The
difference between BeginSend and EndSend was always close enough to zero,
which would also make sense as most messages i'm sending would only be a few
bytes in size. The difference between the BeginConnects and EndConnects is
always 5. This is right as i've set it so i only connect to at most 5 people
at any one instant.
So i can rule out a bug in my code that's causing millions of BeginXXX's
without corresponding EndXXX's. There'd typically be between 80 and 120
Begin/EndReceive calls a second, which isn't that much really. A similar
amount for Begin/EndSend.
On 3/31/07, Alan McGovern [EMAIL PROTECTED] wrote:
Hi,
That leaves me with the question of how the hell a SocketAsyncResult is
10 megs in size! The size of the largest single object in my entire code is
a 16kB byte[] buffer. If each SocketAsyncResult is 10 megabytes in size, i
have to question the internal workings of mono, as i know from profiling my
own code does *not* create objects anywhere near that size.
I'm going to do a bit of profiling to count how many socket BeginXXX
calls are made from my own code as compared to the EndXXX calls to see how
they match up.
Is there any way of finding out what exactly is inside those
SocketAsyncResults that is 10 megs in size? I can verify that the exact same
code running under Mono 1.2 and earlier does *not* exhibit the same
behavior, everything works fine. I only came across this bug after updating
my mono installation to 1.2.3. This is why i think it's a mono bug,
however i can't reproduce the problem in the form of an NUnit test.
Thanks again,
Alan.
On 3/30/07, Joe Shaw [EMAIL PROTECTED] wrote:
Hi again,
On 3/30/07, Joe Shaw [EMAIL PROTECTED] wrote:
That huge object array, in turn, is referenced by
System.Collections.Queue - System.Net.Socket.Socket , specifically
the
readQ member. So basically it means that the readQ member in
System.Net.Socket.Socket is a huge Queue, which internally has an
object array, which apparently has millions of SocketAsyncResult
objects inside. So how those are being allocated?
These objects are created a lot[...]
I got a little ahead of myself here: I'm obviously looking at the code
for System.Net.Sockets.Socket here.
I don't know much about the Socket class and how the async IO
works, but it boils down to the fact that BeginReceive() is being
called probably millions of times, but it doesn't look like
Complete()
is being called enough (or possibly at all) to balance the load.
I actually noticed something else:
The object array in question has an average size of 10.6 megs, but it
only holds 56 references to SocketAsyncResult at the time of this
snapshot. So this seems to indicate to me that the enqueues and
dequeues do ultimately match up, but that the allocation pattern is
bad and probably not interspersed. That is,
enqueue, enqueue, dequeue, dequeue, enqueue, enqueue, etc.
would mean that an array could be as small as 2 items and still work
for N items, assuming a 1:1 match.. But if the pattern is instead,
enqueue, enqueue, enqueue, enqueue, dequeue, dequeue, etc.
then it would have to be at least N. Now pretend N is a million. :)
Joe
___
Mono-devel-list mailing list
Mono-devel-list@lists.ximian.com
http://lists.ximian.com/mailman/listinfo/mono-devel-list
