Tessa Wycliffe
Uniquely Similar
Join date: 24 Oct 2007
Posts: 5
|
03-16-2008 03:39
It used to be that a crash in Second Life for Windows would simply crash the client and nothing more. Well, except leave memory holes, but they could be handled by a reboot. But a viewer crash, which always consistently happens within minutes after I start the viewer these days, now takes my whole computer down with it. Meaning, it triggers something in hardware (some CPU instruction, probably) and shuts the whole system completely off, just as if I'd pulled the plug.
There's no way to send in logs on these ones; the SL viewer doesn't even know it's crashed so there are no logs generated.
Now, before you say that it must be something else, believe me, I've tested this quite extensively, and I know it's not. I know my way around computers, from PCs to cluster farms and mainframes. There have been no changes to my system except for upgrading the SL viewer each time it came out. All other software runs as expected. It's only the SL viewer that consistently crashes the system.
And it's not a hardware problem; benchmark and stress tests bear this out.
On my Linux system, crashes have followed the same kind of uphill curve, only I don't (yet) get hardware crashes. A viewer crash still merely kills the processes for the viewer and voice software. But whereas before, a crash would come along maybe once or twice per four hour session, they now come all of the time. The viewer consistently crashes within a minute after a start-up and login, regardless if I move around or not.
This of course makes it impossible to use SL at all at this point.
I have a sneaking suspicion that LL is in way too far over its head and doesn't know how (or has the resources to) scale the system for the existing level of simultaneous logins. And as SL continues to grow, it's only going to get worse. Some may leave and that may stave off the big crash for a while, but it'll catch up soon if LL doesn't pull a rabbit out of its hat and do something radical to fix the system, beyond applying bandages, duct tape and paper clips.
|
Haravikk Mistral
Registered User
Join date: 8 Oct 2005
Posts: 2,482
|
03-16-2008 04:53
From: Tessa Wycliffe I have a sneaking suspicion that LL is in way too far over its head and doesn't know how (or has the resources to) scale the system for the existing level of simultaneous logins. And as SL continues to grow, it's only going to get worse. Some may leave and that may stave off the big crash for a while, but it'll catch up soon if LL doesn't pull a rabbit out of its hat and do something radical to fix the system, beyond applying bandages, duct tape and paper clips. I'm afraid I can't help much with your problem, my thought would be bad RAM, I've had that before, knew that was the problem, and yet hardware tests couldn't detect it (if they had then they probably would have crashed too). However, for your comments regarding the system, my impression of LL's back-end structure is that it has suffered a lot from bad decisions in the past. It was never really designed to handle the numbers it's handling now as big chunks of it were never designed to be distributed across multiple machines (resulting in single points of failure/bottlenecks, e.g. - the asset server). Although it seems they're making progress on making more and more of their stuff distributed, but some things are hanging on that they really need to get a move on with replacing. Things like the XML-RPC server needs a different system entirely to replace it, as it's becoming a single point of failure for a lot of web-services that interact with SL. The asset servers as well seem to have a very hard time still, really they should just be putting much bigger hard-drives into simulator machines so that they can cache all assets within them, so that the asset servers are queried as little as possible.
_____________________
Computer (Mac Pro): 2 x Quad Core 3.2ghz Xeon 10gb DDR2 800mhz FB-DIMMS 4 x 750gb, 32mb cache hard-drives (RAID-0/striped) NVidia GeForce 8800GT (512mb)
|
Tessa Wycliffe
Uniquely Similar
Join date: 24 Oct 2007
Posts: 5
|
03-16-2008 09:14
From: Haravikk Mistral I'm afraid I can't help much with your problem, my thought would be bad RAM, I've had that before, knew that was the problem, and yet hardware tests couldn't detect it (if they had then they probably would have crashed too). Before I go any further, I just want to point out that I would rather find my hardware at fault because then it would be pretty easy to fix. And I realize that I'm guilty of vastly oversimplifying things, concentrating solely on the client here. I do actually believe that the problem is tied to a few different problem areas, client and server side. That said, I did swap RAM, the CPU and the graphics card out multiple times and in different combinations and brands and models on both separate systems (Windows and Linux) just to cover most of the inevitabilities (it pays to have a husband in the hardware business with ready access to open stock), and that just wasn't it for me. From: Haravikk Mistral However, for your comments regarding the system, my impression of LL's back-end structure is that it has suffered a lot from bad decisions in the past. It was never really designed to handle the numbers it's handling now as big chunks of it were never designed to be distributed across multiple machines (resulting in single points of failure/bottlenecks, e.g. - the asset server). I believe lots of systems "out there" were never originally designed for the numbers they invariably got, but on the other hand, many were designed to scale well from the outset, and if they weren't, they were simply junked and replaced, as long as adequate funding was available and you could convince your investors and/or bosses that a swap-out was necessary long before its need became inevitable and apparent to users. As far as assets and other items go, I think LL would have been better off to store them client side. I understand why they didn't do it that way in the first place, but those issues could have been handled and resolved with a bit of forethought ... in my opinion, of course.
|