<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>Justin,<BR>
<BR>
overall, I think we might have a problem with our approach of 'dumping' data on the outgoing queues.<BR>
<BR>
With 'dumping', I mean, for example, responding to an asset request by creating and placing all the assets packets on the outgoing queue in one operation.<BR>
<BR>
If the asset operation is being aborted (for an array of perfectly reasonable reasons, AFAIK it's actually part of the protocol that the viewer can cancel a texture download, if it's no longer 'interesting', or if it wants another level of detail) the packets are still there, kind of orphaned, and definitively wasting bandwith.<BR>
<BR>
With 'sweeping' I mean making timer-paced sweeps to look for updates, then 'dump' them directly on the outgoing queues.<BR>
<BR>
If a queue becomes throttled, a second sweep will place another update on the queue, even if there's actually already one waiting to get thru. Again, wasting bandwith.<BR>
<BR>
I believe we need to move away from 'sweeping' and 'dumping', towards something more asynchronous and handshaking.<BR>
<BR>
I was toying with the idea of registering callbacks for acked/nacked packets; that would actually make it possible to choose to remove the packet from the queue or re-create the packet with new information.<BR>
<BR>
Also, A texture transfer could send like 10 initial packets, then wait for ack/nack to send new ones.<BR>
<BR>
/Stefan<BR><BR><BR><BR>
<HR id=stopSpelling>
<BR>
> Date: Fri, 22 Feb 2008 22:00:00 +0000<BR>> From: jjustincc@googlemail.com<BR>> To: opensim-dev@lists.berlios.de<BR>> Subject: [Opensim-dev] Profiler installed on osgrid plazas server and profiler dump now available<BR>> <BR>> This afternoon (with a bit of haxoring) I installed the mono heap-shot <BR>> profiler on the OSGrid plazas server in pursuit of current memory <BR>> leaks. heap-shot will take a dump while in operation when it receives a <BR>> signal. More details on it can be found here.<BR>> <BR>> http://www.mono-project.com/HeapShot<BR>> <BR>> Now that it's installed it's very easy to run, if anyone with access to <BR>> the plazas wants to take further dumps.<BR>> <BR>> I started the profile on Wright Plaza with just me on it. <BR>> Interestingly, that was enough to cause memory to continuously grow. <BR>> This was associated with continuous requests for the same assets (which <BR>> do not exist) on the console. This in itself, though bad, should not be <BR>> enough to cause the memory leak. I took several dumps, the smallest of <BR>> which (along with the log file) can be downloaded from<BR>> <BR>> http://opensimulator.org/dump/OpenSim-at-595mb-one-avatar-with-scripts-wright.zip<BR>> <BR>> On a very preliminary analysis of the dump, it looked like the major <BR>> problem is data building up in the outgoing texture packet queue. This <BR>> is why I created extra statistical information which prints out the <BR>> number of packets in the different queue types for each agent (which can <BR>> be seen by typing 'show stats' on the console). Hopefully this should <BR>> reveal whether this is really where the issue is (I'm not yet convinced <BR>> I'm interpreting the dump information correctly).<BR>> <BR>> I very probably won't have any time now to work on this until next week <BR>> - I thought I would make the data available for general interest and in <BR>> case anyone wanted to take a shot at it.<BR>> <BR>> --<BR>> justincc<BR>> _______________________________________________<BR>> Opensim-dev mailing list<BR>> Opensim-dev@lists.berlios.de<BR>> https://lists.berlios.de/mailman/listinfo/opensim-dev<BR><BR></body>
</html>