Is there some kind of problem with Assett server?

Got a report that people cannot Up Load data.

Yes there's a huge problem with the asset server. We have no limit to the number of items we can individually dump into it and expect it to perpetually store and index for us. It becomes an increasingly huge problem every hour of every day.

But Heaven forbid that some reasonable limit be imposed and a couple of dozen people stop playing the game.

I forget how many things I have in my inventory; 7k comes to mind, partly from laziness, partly as my inventory goes back to when inventory management was even more crude than it is now.

If my understanding is corrrect, if I were to delete everything in my inventory and empty my trash, the asset server would never ever dispose of those things even if the only pointer to the UUID of object X was in my inventory.

Am I mistaken?

That's a good question.

Thanks for asking the question, it got answered.

However, I find one part of the answer somewhat puzzling:which seems to result in a process that could never complete or would take an astronomical time to complete.

For example, given a texture UUID of XY and an object containing a script:

...
string x = "X";
string y = "Y";
llSetTexture(x + y, ALL_SIDES);
...

it seems very hard to determine that XY is referenced. If this example is too simple, try something more complex than "+" for generating the UUID, for example reading a UUID from a notecard.

I'd like to believe that the Linden answer is correct, but it seems to me that as described either no UUID could ever be known to be unreferenced (thus no garbage to collect) or that some "SuperFoos" would eventually lose their textures.

Well - X+Y generates a vlid UUID, which is called for in applying said texture to a prim - making the asset the UUID references "active" again, on that prim.

If I am understanding you, if and only if and when that script is run. My point was that a "SuperFoo" in someone's inventory that wasn't running would be rather difficult to statically analyze and determine that UUID XY might be needed in the future (i.e. had a "live" but "dormant" reference).

Isn't there always?

Hmmm...how much memory DOES an average inventory take up on the asset server?

I have a bit over 10k worth of items, but 4k (almost 5 now) are textures used in building.

I imagine the textures and sounds (though I don't really have a lot of those) take up the most storage (guessing this sing those type of files do on my own PC)

But with 1 terrabyte HDs on the market (and I imagine more if you have money for a buisness like LL), is this the size of the data really a problem?

I honestly can see LL allowing every resident unlimited storage if that storage accounted to anything. 200,000+ residents would add up fast if anything big. Even 1Mb of storagage each here would case a problem. If the storage is more like 250Kb then I don't think it's a big deal.

As my inventory loads from the assest server in about 2-4 seconds when I log in, I have to believe the acctual size of the files are fairly small. Even with my cable modem, 2-4 seconds is not a lot of time for data transfer.

Food for thought.

~Jessy "Mmmm....donuts......."

Hi Jessica

When the asset server starts to show signs of struggling. It wont be caused by limited storage space. It'll be due to the server not being able to find our item fast enough.

If I give you a list of ten items and asked you to find the item named 'Sheep' in that list. You'd be able to find it quite quickly. But if I gave you a list of one billion items and asked you to find my sheep then it could take you days to find it.

In that time the sheep could've been ate by a wolf (A gray one). Or my needs may have passed.

... with white edging?

You got it!

Not enough of those in Wales eh?

The grid monkey has gone into deep-think, all problems should soon be fixed.

Databases don't have that problem that often, as indexing is good and finds individual items very quickly. Binary search for example is O(log n), and would only need to examine 21 items from the billion to find the right one. You get somewhat different problems.

Databases are fast when things are cached, but that doesn't work so well when you have terabytes of data and not enough RAM to cache enough of it. That results in lots of disk activity, which is very slow.

Another problem is concurrency: Both massive reads and massive writes are relatively easy to handle, but a workload with lots of reads and lots of writes can be quite tricky due to locks, which often lock more than strictly necessary.

SL presents the additional problem of requiring very fast responses. In many applications waiting half a second wouldn't even be noticed, here it's unacceptable.

That's right!

We're all very impatient shepherds here. We want our sheep and we want them now. But our fields have space to hold billions of them, so it can take a while to find the right one.

Anybody seen Dolly?

I can't believe you people all have 10,000 items in your inventory. I've peaked at 3,200 in my 2.6 years here, and I think it's too much. Probably half of it could be pitched, but I'm a packrat and very sentimental.

You are understanding me, and I suppose you are correct - there is some risk that an asset might be purged under those conditions.

I agree with you in principle, and could probably pare my "stuff that I really want" down to about 500 items however...

When you've got a huge inventory, most of the items are far from self descriptive (even when not called "Object" so plowing through the list means hours of rezzing. Moreover, there is no indication of whether item P cost you L$5k or L$2 or whether or not it is still available for sale should you decide that you really did want it. When you add the sentimentality factor (gee, this was given to me on day one by Viola) and the lack of any incentive to prune the inventory you wind up with a big mess.

One could certainly argue that if I can't name a thing then I'm probably not going to make much use of it, but there are things that represent days worth of work that I'd be loathe to trash blindly. There are also folders of hundreds of assets randomly dropped on me by generous people that I never even got a chance to look at so to me they essentially junk but I couldn't even tell you what those folders are called nor could I know from the name if it was one such gift.

Better inventory tools and some sort of incentive for mucking through huge inventories would probably work wonders.

Is it possible that, rather than scanning every script for indirect references, the asset server instead stores the date and time an item was last referenced and purges those that have not been referenced in a given period of time?

An entry from monday on the PlayNoEvil blog sums it up nicely:

"It could be that the focus on virtual real estate may ultimately be fatal
for Second Life. By lacking strong in-game logging and controls for
virtual assets and scripts, the real costs to operate the game are not
reflected in its business model AND security weaknesses are allowed
to fester."

http://www.playnoevil.com/serendipity/index.php?/archives/399-Linden-Labs-Second-Life-MMO-Virtual-World-Attacked-Again-3-Times-in-One-Month.html

Thanks for the link. Why does it remind me of this old thread?

I'm starting to feel bad about the 28,000 items in my inventory. O.O

Musuko.

Inventory (Fetched 16,794 Items...)

Would moving everything into boxes help? ;p

There is indeed a problem.

Someone loaded an extra letter T on the end, there.

It also got followed up. At least those odd objects, photos and such that we create, never give to anyone, and never use do actually get deleted from the database. And eventually, anything not being referenced does as well.

I'm not sure there is any better way to do it; have to think on that one.