600 on a 8 core machine ( i guess the hyperthreaded cores are visible to mono as real cores, at least in nmon they are reported as such ) is quite a lot of threads. This morning I went big and configured 1000, but I'm not really sure which approach to go... <br>
<br>seeing the stats:<br><br><font size="1"><span style="font-family:courier new,monospace">Region (Close Encounter) # show threads</span><br style="font-family:courier new,monospace"><span style="font-family:courier new,monospace">9 threads are being tracked:</span><br style="font-family:courier new,monospace">
<span style="font-family:courier new,monospace"> ID NAME LAST UPDATE (MS) LIFETIME (MS) PRIORITY STATE</span><br style="font-family:courier new,monospace">
<span style="font-family:courier new,monospace"> 8 PollServiceWorkerThread0 137 27996479 Lowest WaitSleepJoin</span><br style="font-family:courier new,monospace">
<span style="font-family:courier new,monospace"> 9 PollServiceWorkerThread1 27996478 27996478 Lowest WaitSleepJoin</span><br style="font-family:courier new,monospace">
<span style="font-family:courier new,monospace"> 10 PollServiceWorkerThread2 27996478 27996478 Lowest WaitSleepJoin</span><br style="font-family:courier new,monospace">
<span style="font-family:courier new,monospace"> 11 PollServiceWatcherThread 137 27996478 Lowest WaitSleepJoin</span><br style="font-family:courier new,monospace">
<span style="font-family:courier new,monospace"> 15 MapItemRequestThread (Close Encounter) 383 27992497 Lowest Background, WaitSleepJoin</span><br style="font-family:courier new,monospace">
<span style="font-family:courier new,monospace"> 18 Incoming Packets (Close Encounter) 19 27979915 Lowest WaitSleepJoin</span><br style="font-family:courier new,monospace">
<span style="font-family:courier new,monospace"> 19 Outgoing Packets (Close Encounter) 0 27979915 Lowest WaitSleepJoin</span><br style="font-family:courier new,monospace">
<span style="font-family:courier new,monospace"> 20 Heartbeat (Close Encounter) 55 27979914 Lowest WaitSleepJoin</span><br style="font-family:courier new,monospace">
<span style="font-family:courier new,monospace"> 34 AsyncLSLCmdHandlerThread 33 27964827 Lowest Background, WaitSleepJoin</span><br style="font-family:courier new,monospace">
<br style="font-family:courier new,monospace"><span style="font-family:courier new,monospace">*** ThreadPool threads ***</span><br style="font-family:courier new,monospace"><span style="font-family:courier new,monospace">workers: 0 (500); ports: 0 (1000)</span><br style="font-family:courier new,monospace">
<br style="font-family:courier new,monospace"></font>the ThreadPool shows worker/port threads 1500 so on a 8 CPU Machine 200 MONO_THREADS_PER_CPU should be sufficient if i interpret those numbers correctly guessing the numbers in brackets are the max of the Pools. Therefore 1000 is possibly too much, Will be interesting to see if i still run into problems with 300 Threads per CPU.<br>
<br><br><br><br><div class="gmail_quote">Am 9. März 2012 08:14 schrieb Dahlia Trimble <span dir="ltr"><<a href="mailto:dahliatrimble@gmail.com">dahliatrimble@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Sorry I don't really know much about it. In my case it was an application that used the http server dll from OpenSim and served probably 40-60 simultaneous requests. Mono was defaulting to 25 threads per cpu but I changed it to 75 and I stopped having download problems. This was on a 4-core machine.<div>
<br></div><div>I would guess if you are using 150 and seeing problems that a good place to start might be somewhere around 450-600 and see what happens.</div><div class="HOEnZb"><div class="h5"><div><br><div class="gmail_quote">
On Thu, Mar 8, 2012 at 9:44 PM, Akira Sonoda <span dir="ltr"><<a href="mailto:akira.sonoda.1@gmail.com" target="_blank">akira.sonoda.1@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ooopps... my MONO_THREADS_PER_CPU=150 are obviously not enough. 2000 as stated in the article is quite a lot ... what are your settings? do you go with the 2000?<br>
<br><br><div class="gmail_quote">Am 9. März 2012 00:07 schrieb Dahlia Trimble <span dir="ltr"><<a href="mailto:dahliatrimble@gmail.com" target="_blank">dahliatrimble@gmail.com</a>></span>:<div><div><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Are you using Mono? I've seen poor performance of the http server used in OpenSimulator when insufficient threads are available. Manipulating the environment variable MONO_THREADS_PER_CPU has worked for me when I've encountered this problem before. Take a look at <a href="http://www.mono-project.com/Article:ThreadPool_Deadlocks" target="_blank">http://www.mono-project.com/Article:ThreadPool_Deadlocks</a> for some background on this problem.<div>
<br></div><div>As far as network performance tools go I'd probably just search the web for "network performance tool" and pick whatever works for you.<br><br><div class="gmail_quote"><div><div>On Thu, Mar 8, 2012 at 2:28 PM, Akira Sonoda <span dir="ltr"><<a href="mailto:akira.sonoda.1@gmail.com" target="_blank">akira.sonoda.1@gmail.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>Hi Dahlia,<br><br><div class="gmail_quote">Am 5. März 2012 01:14 schrieb Dahlia Trimble <span dir="ltr"><<a href="mailto:dahliatrimble@gmail.com" target="_blank">dahliatrimble@gmail.com</a>></span>:<div>
<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
A couple thoughts, not sure if it's your problem or not.<div><br></div><div>I would probably check to make sure the cache is set up properly and the file system it's on has plenty of space. Also make sure the disk isnt being thrashed by other processes and that the disk is healthy and not fragmented. There's probably some system utilities that can show disk I/O activity and disk health.</div>
</blockquote></div><div><br>There is plenty of free space on the disk. <br> </div><div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>
</div><div>You may also have network congestion problems that could slow retrieval from the asset servers or slow sending of assets to other clients.<br>
</div></blockquote></div><div><br>How can i figure them out?<br><br></div></div>I've made a other report from the party from Wednesday on "Pyramid@osgrid". <br><br><a href="https://docs.google.com/open?id=0B301xueh1kxdVmVZZ18tbi1TdzZ2cGlRaFhDTlo4UQ" target="_blank">https://docs.google.com/open?id=0B301xueh1kxdVmVZZ18tbi1TdzZ2cGlRaFhDTlo4UQ</a><br>
<br>The server where "Pyramid" is located is similar to my server. The major difference is the mono version. There was a time when i had high quite high network load but is this network congestion?<br><br>Status right now: we survive.<br>
<br><br>
<br></div></div><div>_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de" target="_blank">Opensim-dev@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
<br></div></blockquote></div><br></div>
<br>_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de" target="_blank">Opensim-dev@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
<br></blockquote></div></div></div><br>
<br>_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de" target="_blank">Opensim-dev@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
<br></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
Opensim-dev mailing list<br>
<a href="mailto:Opensim-dev@lists.berlios.de">Opensim-dev@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-dev" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><br>
<br></blockquote></div><br>