[Opensim-dev] AssetServer Observations and Suggestions

[cmickeyb at gmail.com]

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.

--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
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20090209/b6fe9bbe/attachment-0001.html>