maybe it helps when you optize your mysql: <br><br><a href="http://www.debianhelp.co.uk/mysqlperformance.htm">http://www.debianhelp.co.uk/mysqlperformance.htm</a><div><br dir="ltr">Op zaterdag 7 april 2012 schreef Gudule Lapointe (<a href="mailto:gudule@spekuloos.be">gudule@spekuloos.be</a>) het volgende:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Thank you very much Justin for this detailed information.<div><br></div><div>Actually, the monitoring I made since a couple of days allowed me to eliminate a range of possible causes (including network, disk, machine overload, etc). My conclusion to focus on mysql performance is far more than an assumption, even if I didn't detailed my tests here.</div>
<div><br></div><div>The monitoring tools I have for mysql told me a range of causes of performance loose, including the index. But no precise indication on which database, with tables or which queries.</div><div><br></div>
<div>The explanations you gave confirm me that the size of the grid (and the database) should not be a problem -- in normal operating conditions.</div><div>So I am happy not to have to enter in the adventure to split databases right now.</div>
<div><br></div><div>I'll check now if something like db/index corruption is in the air (anyway, a db optimization shouldn't hurt). And still investigating on other possible causes.</div><div><br></div><div><br></div>
<div>--</div><div><div><span style="text-indent:0px;letter-spacing:normal;font-variant:normal;text-align:-webkit-auto;font-style:normal;font-weight:normal;line-height:normal;border-collapse:separate;text-transform:none;font-size:medium;white-space:normal;font-family:Helvetica;word-spacing:0px"><span style="text-indent:0px;letter-spacing:normal;font-variant:normal;text-align:-webkit-auto;font-style:normal;font-weight:normal;line-height:normal;border-collapse:separate;text-transform:none;font-size:medium;white-space:normal;font-family:Helvetica;word-spacing:0px"><div style="word-wrap:break-word">
<span style="text-indent:0px;letter-spacing:normal;font-variant:normal;text-align:-webkit-auto;font-style:normal;font-weight:normal;line-height:normal;border-collapse:separate;text-transform:none;font-size:medium;white-space:normal;font-family:Helvetica;word-spacing:0px"><div style="word-wrap:break-word">
<span style="text-indent:0px;letter-spacing:normal;font-variant:normal;text-align:-webkit-auto;font-style:normal;font-weight:normal;line-height:normal;border-collapse:separate;text-transform:none;font-size:medium;white-space:normal;font-family:Helvetica;word-spacing:0px"><div style="word-wrap:break-word">
<span style="text-indent:0px;letter-spacing:normal;font-variant:normal;text-align:-webkit-auto;font-style:normal;font-weight:normal;line-height:normal;border-collapse:separate;text-transform:none;font-size:medium;white-space:normal;font-family:Helvetica;word-spacing:0px"><div style="word-wrap:break-word">
<span style="text-indent:0px;letter-spacing:normal;font-variant:normal;text-align:-webkit-auto;font-style:normal;font-weight:normal;line-height:normal;border-collapse:separate;text-transform:none;font-size:medium;white-space:normal;font-family:Helvetica;word-spacing:0px"><div style="word-wrap:break-word">
<div><a href="http://www.speculoos.net/" target="_blank">http://www.speculoos.net/</a></div><div><a>secondlife://speculoos.net:8002/</a></div><div>Speculoos, the belgian cookie-flavored metaverse</div></div></span></div></span></div>
</span></div></span></div></span></span>
</div>
<br><div><div>Le 7 avr. 2012 à 03:10, Justin Clark-Casey a écrit :</div><br><blockquote type="cite"><div>On 06/04/12 18:53, Gudule Lapointe wrote:<br><blockquote type="cite">I experience lot of timeout problems. I checked every side of the installation, and I suspect the database to be the<br>
</blockquote><blockquote type="cite">bottleneck.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">The main question is: how can I clean up the database? Detail description below…<br></blockquote>
<blockquote type="cite">Any advice on any part of the problem is welcome.<br></blockquote><br>From the data below I'm quite surprised you're having problems - this is not a particularly large grid. I strongly recommend actually measuring performance where you can and finding the actual bottleneck, rather than assuming that certain things are issues. You might find that the issue is not actually OpenSimulator related (e.g. a network issue, machine overloaded for other reasons, etc). In particular, I don't think 2.3Gb is all that large for an asset database.<br>
<br>Unfortunately, I'm not aware of tools to measure things such as inventory service response, though in principle they would not be all that hard to write.<br><br>pCampbot [1] can do some simulator testing where many libomv clients are logged onto a simulator at once, though some of its actions are currently highly unrealistic (e.g. logging in 20 bots simultaneously).<br>
<br>I've written up some grid performance discussion and possible solutions at [1]. However, this only covers the issues I've personally seen. In general, scaling a grid is very hard and largely a step into an evolving unknown. It's also the hardest area to work in since diaganosing issues is very time consuming (and not always something I have the time to help with, unfortunately, not least because it's an area I'm still learning about). But again, I don't think your grid numbers are actually high enough to encounter the more complex issues.<br>
<br>More comments below.<br><br><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Current setup comes from an initial test installation, and changed a lot before going to prod (versions changes, server<br>
</blockquote><blockquote type="cite">changes, oar save and load, etc).<br></blockquote><blockquote type="cite">However it has been working quite fine for more than 3 months, since latest big change.<br></blockquote><blockquote type="cite">
<br></blockquote><blockquote type="cite">- version: 0.7.3-post-fixes<br></blockquote><blockquote type="cite">- robust server, with 7 simulators, for a total of 56 regions<br></blockquote><blockquote type="cite">- From these region, I would say 15 à 20 are really active, others are placeholders, without content.<br>
</blockquote><blockquote type="cite">- About 20 registered users. Usually 3 or 4 concurrent users<br></blockquote><blockquote type="cite">- Each region has it's own mysql database, and robust uses a single one.<br></blockquote>
<blockquote type="cite"><br></blockquote><blockquote type="cite">Since around 5 days, I get continuous timeout, access to inventory or assets errors and sometimes region crashes.<br></blockquote><blockquote type="cite"><br>
</blockquote><blockquote type="cite">Though they were no recent change on the set up when the problems began. Hence my suspicions on the database.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">
(CPU, memory and disk usage don't show any overload)<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Regions database are fairly light (~20MB)<br></blockquote><blockquote type="cite">Robust database is huge: 2.6 GB<br>
</blockquote><blockquote type="cite">I am not sure such a big database is common for setup like ours.<br></blockquote><br>This is not a very unusual size and I don't think that it's a problem to be honest.<br><br>
<blockquote type="cite"><br></blockquote><blockquote type="cite">So it looks obvious that I should clean up the database, which may contain a lot of outdated items.<br></blockquote><blockquote type="cite">Fair enough. How can I do?<br>
</blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">I would like to know<br></blockquote><blockquote type="cite">- which tables I can empty without losses, at all<br></blockquote><br>Nothing that would make any significant difference compared to deleting/deduplicating assets. There are some (a) suggestion for asset dedupe at [1]. Asset deletion is a hard problem, though I think there might be some future stuff that can be done by deleting/retiring assets that haven't been accessed for a very, very long time.<br>
<br><blockquote type="cite">- which tables I can empty after having made a successful oar save of my regions<br></blockquote><br>You could empty the region database, naturally. I'm assuming you're not storing all region and service data in a single database. Even then there is a list of region tables on the wiki.<br>
<br></div></blockquote></div><br></div></div></blockquote></div><span></span><br><br>-- <br>Groningen en Hannover Opensims:
<span style="color:rgb(50,61,86);font-family:'Trebuchet MS',Helvetia,Tahoma,Verdana,Arial,sans-serif;font-size:16px;text-align:left;background-color:rgb(255,255,255)">secondlife://meverhagen.nl:8002:Hannover ZW/ </span><br>