[Opensim-users] bin/OpenSim.db-journal file begin written and deleted many times

Dahlia Trimble dahliatrimble at gmail.com
Tue Apr 29 11:10:57 UTC 2014


That long shut down has really nothing to do with the translate scene
command and everything to do with using Sqlite on a high object-density
region where a lot of objects had changed. Sqlite has been extremely slow
as long as I've used OpenSim, so I don't believe it's a new issue. I'm not
sure of the meaning of the journal file but it's name suggests it may be
doing some transaction journaling which can be deleted after a transaction
is complete. I'm also not that familiar with the database layers in OpenSim
but I'd think that if it was using transactions it would be a good thing as
they can protect database integrity in the case of a crash or other failure
during an update.

I use Sqlite for some high-prim regions and it's horribly slow. I just use
the "backup" command while the region is still running so it can persist
while the region is in use. Either that, or I tell it to shutdown and then
go out for a walk or something.


On Tue, Apr 29, 2014 at 3:33 AM, Ai Austin <ai.ai.austin at gmail.com> wrote:

> Gwyneth wrote:
>
>> What version are you using, Ai? I have seen a fluctuation of viewer-side
>> FPS on an apparently 'empty' region, usually a signal that there is some
>> 'invisible' back-end processing at the simulator level, but haven't been
>> able to track it down to anything yet. Selecting a lot of prims and
>> linking
>> them together now takes quite a lot of time (sometimes even a minute or
>> so!). This is on 0.8.0 Dev 722f030. I suspected some delays while writing
>> to the database, and having some sort of database journal being written to
>> a lot of times would certainly account for that!
>>
>
> I was using the OSGrid latest add-on region release from a few days ago
> (r/24670) Gwyneth.
>
> Dahlia wrote:
>
>> Translate scene should complete quite quickly, all it does is move the
>> objects in the scene. What you are probably seeing is the changes being
>> saved to the database, an entirely different process. If you are using
>> Sqlite for your region database than storing changes to the scene will
>> always be quite slow. It would likely take just as long for loading an oar
>> with the same number of objects and saving them to the database. If you
>> need faster region storage, try using one of the other database options
>> such as mysql.#
>>
>
>
> That's right Dahlia.  The translate scene on 600 or so objects was
> essentially instant and I was able to move the avatar about (using ODE
> temporarily until Robert's r/24672 commit is in the OSGrid release) in the
> new negative Z underwater area fine.  It was indeed as I did the
> shutdown... and I did assume it was the persisting to data base part.. that
> took nearly 30 minutes.  It was SQLite for the add on regions we have for
> experiments.. not our MySQL usual data base.  But still.. constantly
> creating and deleting the db-journal file (perhaps once per DB write?) MUST
> make this persisting process slower than needed?  I also thought I better
> make sure the persisting process completed even though it as taking ages or
> else there may have been only a partial translation.  If I had not had the
> opensim\bin window open I would have thought the OpenSim.exe console was
> jammed and stopped wit with the X on the console window... I assume that
> would NOT have been good, so it could be a source fo problems if persisting
> objects takes so long.  A better indication of progress might be to put a
> dot out every 50 or 100 objects persisted on the console to remind the user
> the region OpenSim.exe still need time to complete.
>
>
>
>
>
> _______________________________________________
> Opensim-users mailing list
> Opensim-users at opensimulator.org
> http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-users/attachments/20140429/dde89874/attachment.html>


More information about the Opensim-users mailing list