[Opensim-dev] AssetServer Observations and Suggestions
Justin Clark-Casey
jjustincc at googlemail.com
Mon Feb 9 14:19:55 UTC 2009
cmickeyb at gmail.com wrote:
> The short term solution is to use the "last access" field for each of
> the assets and archive ones that haven't been used recently . So long as
> inventory is in one place (that is, you aren't splitting inventory
> across servers) you should be able to do some "simple" mysql magic to
> update the last access on anything referenced in the inventory
> (basically update last access time for any asset in the inventory
> table). that combination should pick up most everything given that
> textures on prims are reloaded from the asset server every 24 hours,
> scripts need to be recompiled on server restart... etc.
One would need to carry out deep inspection of inventory contents (e.g. inspecting all the assets used by objects within
objects, etc.). The code for this could be extracted from the archiving module. However, doing such a sweep could take
a long time.
This still doesn't account for objects on regions. Although perhaps one could start storing assets that relate to
object on regions on that region itself. This might better allow reaping of the central asset server since you no
longer have to worry about assets used by objects within objects on a region.
A messier solution which I think has been said already is simply to remove any assets that haven't been accessed since
the access_time has been put in place. As long as you keep a backup of the db before the cleanup, you could still
retrieve and reinstate selected assets as necessary.
An even more radical solution would be to switch osgrid to a pure Hypergrid model. The osgrid UAI services could still
act as the home services for many people who don't want to run their own regions, but the responsibilty for maintaining
region-side assets would shift to other OpenSim instances (and some people would also use them for their home services
instead of osgrid).
>
> --mic
>
>
> On Feb 8, 2009 6:18pm, Charles Krinke <cfk at pacbell.net> wrote:
> > Dear Mike:
> >
> > What you say seems reasonable and I applaud you.
> >
> > On the related subject of mutability, I have a tough time imagining
> that each edit of the terrain of a region is useful. I would suggest
> that only the last "terrainImage" is useful and cannot imagine any
> reference to any obsolete terrainImage by any object anywhere.
> >
> > There are a significant number of items in OpenSim mysql databases
> such as the various edits of a script where we appear to be storing a
> new UUID for each edit. In a similar manner, I would think that such
> obsolete edits are not useful.
> >
> > So, half of the problem is a strategy to slow down the bloat of our
> assetServers with perhaps additional references to additional
> assetServers and half is to perhaps re-consider all the orphaned items
> we are leaving in our
> > mysql database and find a way to stop doing that.
> >
> > Charles
> >
> >
> > From: Mike Mazur mmazur at gmail.com>
> > To: opensim-dev at lists.berlios.de
> > Sent: Sunday, February 8, 2009 6:11:46 PM
> > Subject: Re: [Opensim-dev] AssetServer Observations and Suggestions
> >
> >
> > Hi,
> >
> > On Sun, 8 Feb 2009 10:13:45 -0800 (PST)
> > Charles Krinke cfk at pacbell.net> wrote:
> >
> > > We have been studying the assets table on OSGrid as it heads toward
> > > the "disk full" stage and I have a couple of observations and am
> > > heading towards a suggestion. Maybe this is already accounted for in
> > > the "Cable Beach" project, at which point, this will only indicate
> > > that I did not read all the exchanges carefully enough.
> > >
> > > It appears to me that we are storing on the MySQL data store at the
> > > assetServer on a grid every edit of every script, terrainImage and
> > > clothingItem amongst other things. So, my first observation is that
> > > we appear to be storing all the older, obsolete items that can no
> > > longer be accessed.
> >
> > This ever-expanding asset database is a consequence of how assets are
> > handled by
> > SL, the SL viewer and, since OpenSim was first developed
> > against the SL viewer, by OpenSim as well. The premise is that no asset
> > is mutable, because any asset may be referenced by its UUID. The
> > reference may exist in a script or on the back of a napkin. There are
> > more details (the way I understand them) in a previous email[1] I sent
> > to the list.
> >
> > Cable Beach will not solve this problem.
> >
> > > Now, to the beginnings of a suggestion. It seems to me that each
> > > avatar will have a "home" region. And that perhaps that is the place
> > > to store the items in an avatars inventory. Things like scripts,
> > > notecards, textures and the like.
> >
> > I'm not sure this is the right way forward. It requires that the user's
> > home region is up anytime they wish to use their avatar and access
> > their inventory. The user's home region becomes a single point of
> > failure.
> >
> > > At that point, the assetServer on a grid
> > could be used to store only
> > > pointers (or URL's) to each avatars inventory on his or her home
> > > region.
> >
> > This is a good start, except instead of pointing to the user's home
> > region, it could point to the user's own asset server. The asset server
> > could be provided by a grid (OSGrid), their own asset server (a Cable
> > Beach instance, perhaps), or some other third party that may provide
> > asset storage/access in the future (SL, Yahoo!, Google, AOL, etc).
> >
> > Thanks,
> > Mike
> >
> >
> > [1]
> > https://lists.berlios.de/pipermail/opensim-dev/2008-December/004053.html
> > _______________________________________________
> > Opensim-dev mailing list
> > Opensim-dev at lists.berlios.de
> > https://lists.berlios.de/mailman/listinfo/opensim-dev
> >
> >
> >
> >
> >
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev
--
justincc
Justin Clark-Casey
http://justincc.wordpress.com
More information about the Opensim-dev
mailing list