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
