InWorldz

Where your Dreams are our Vision!

It is currently Sat Jun 23, 2018 2:22 am | All times are UTC - 6 hours
 Page 11 of 12 [ 116 posts ]  Go to page Previous  1 ... 8, 9, 10, 11, 12  Next
Author Message
 Post subject: Re: InWorldz 0.9.19 R5825 Server Upgrades
PostPosted: Fri Dec 18, 2015 10:18 am 
User avatar

Joined: Sun May 30, 2010 12:06 pm
Posts: 3379
Location: Netherlands
Taken the liberty to go over Judy's list of locations, and relog from there, just out of curiosity:

Sanctuary bay:

[07:20] InWorldz: Teleport completed from Creative Hearts (193,50,23)
@ 7:22 logged out
@ 7:23 logged back into last location: Succesful

Next: Kittywake Flows
[07:24] InWorldz: Teleport completed from Sanctuary Bay (135,70,23)
@ 7:25 logged out
@ 7:26 logged back into last location: Succesful

next: Tupaia Bay
[07:27] InWorldz: Teleport completed from Kittywake Flows (106,94,21)
@ 7:28 logged out
@ 7:29 logged back into last location: Succesful

These are all 3 locations that were not allowing Judy to log back into.
All these are done with InWorldz 2 viewer.


Whatever the reason, it affects some residents constantly, and others sporadicly.



_________________
Image
Mesh prefab builder with a preferences towards Gothic Architecture.
Offline
 Profile  
 
 Post subject: Re: InWorldz 0.9.19 R5825 Server Upgrades
PostPosted: Fri Dec 18, 2015 2:13 pm 
User avatar

Joined: Mon Jun 07, 2010 7:07 pm
Posts: 7936
Location: Nova Scotia, Canada
LaryaBlackheart wrote:
Jim Tarber wrote:
LaryaBlackheart wrote:
I do want to mention that I have begun crashing like crazy under certain conditions ... specifically ... it's based on right-clicking the screen ... this is not 100% true at all times ... but at least once or twice a day now since the update. To be certain I will not crash during "un-attaching" things I have to find the attachment in my inventory and take it off from there, rather than trying to do so on my avatar.
Which viewer is this? Is the viewer actually crashing as far as you can tell, or is it a disconnect from the server? If the viewer is crashing, when you right-click vs use the Inventory window, that is certainly a viewer-side issue unrelated to the update. You should report it in the IW3 thread if it is that viewer. I'm also checking on this with viewer folks because it sounds familiar to me. Something to do with drawing the wireframe used when right-click highlighting an object.
Breathe, Jim LOL ... it's not v3 ... specifically (though I haven't checked other viewers) .. I noted it after the latest grid update using v 2.2.15
Lol, I was just asking which viewer the crashing was happening in (because it's clearly a viewer problem). Sorry if I missed you saying it was 2.2.15 earlier, but now that is clear to me.
LaryaBlackheart wrote:
ETA: it's been ongoing since the newest rollout ... and it's happening to my partner sporadically as well - with the same specifics.
Any connection between server updates and viewer crashes is coincidental or indirect. Unfortunately if it's only happening in IW2 and not crashing in IW3 then that's the main reason we created IW3, because of the ongoing and sometimes frequent crashes in IW2 that we could not fix. Depending on the regions your in, and the other avatars entering a region, both IW2 and Firestorm are often crashtastic.


Offline
 Profile  
 
 Post subject: Re: InWorldz 0.9.19 R5825 Server Upgrades
PostPosted: Fri Dec 18, 2015 2:26 pm 
User avatar

Joined: Mon Jun 07, 2010 7:07 pm
Posts: 7936
Location: Nova Scotia, Canada
AstoriaL wrote:
Jim Tarber wrote:
AstoriaL wrote:
This time I logged out and in on a different region, with the same outfit, and rezzed with normal speed. No bots are out on this region. Mare Volcani is the currently problematic one. It's very likely that nobody has visited it since I left there about 1/2 hour ago. 6 bots are still there and have been all along.
Was the new region one of the Event regions? It may have a non-default increased caching configuration in order to lessen the negative effects of slow asset fetches.
No, it was one of the regions on my other 2x2 block. And why would there be a slow asset fetch on a newly loaded outfit that was fully rezzed when I logged out only hours before? Why would it even need to be fetched? I did not clear cache between logins (or go anywhere else, this is a dedicated viewer for my avatar/IW).
Aren't you asking why the server response to a viewer fetch is slow? I'm not sure why the viewer would request something again if you think it should already be cached, but if it's cached at the viewer end, the servers aren't involved at all. We're starting with a question of why one server seems slower than another. If you're talking about something the viewer would have cached, that is why the first one is slower than the other, especially if you haven't cleared cache. The other reason is something totally unrelated to cached viewer content, like the usual region-specific performance issues we we investigate with support tickets, like if that specific machine has a problem (e.g. a buddy region has a problem and is constantly restarting, using a lot of CPU or memory, or some other VM-specific problem).

AstoriaL wrote:
Jim Tarber wrote:
If you think this is purely a performance issue in a region, it probably calls for a region/performance support ticket. It sounds like you suspect it has something to do with the bots? If they are moving and colliding it might, but I think that is unlikely.
4 of them are skating on tours, very occasionally they collide. But neither of the issues I reported have happened before this week and the bots have been skating there for a month. The other two are just hanging out on pose stands.
So it's probably not the bots, and probably not something specific to that region, but rather a general performance concern (like the asset fetch times we don't have a workaround in place for yet, or the kinds of machine issues I mentioned above).
AstoriaL wrote:
Jim Tarber wrote:
I have had no success with submitting tickets for issues like these. Reluctant to do so again. It's possible that something new in the server code has exposed an issue that the conditions of this region are in the proper state to discover what it is. One difference I am sure of is there are several bots on this region where the issue happened several times in a row, and none on the region where the issue didn't happen.
It seems presumptuous to think it's related to a server update if it's not happening on other updated regions. And bots are probably just one of the many differences between that region and others. It's very difficult to form actual conclusions here without an investigation that involves at least A-B-A-B region tests that show a problem in A but not B and then again in A and again not in B. (An A-B test has a sample size of 1 and provides little info. If you think it's something that should be in cache, the other test is to do A-B, clear cache, B-A, then see if it's still not a problem in B but is a problem in A.)


Offline
 Profile  
 
 Post subject: Re: InWorldz 0.9.19 R5825 Server Upgrades
PostPosted: Fri Dec 18, 2015 5:08 pm 
User avatar

Joined: Thu Sep 09, 2010 2:22 pm
Posts: 1755
Location: Pacific NW
Jim Tarber wrote:
Aren't you asking why the server response to a viewer fetch is slow? I'm not sure why the viewer would request something again if you think it should already be cached, but if it's cached at the viewer end, the servers aren't involved at all.

I logged into one region several times and experienced huge delays loading the same outfit I continued to wear. I did not experience such delays prior to the server rollout.

Since then, I have been logging in to a different region, again wearing the same outfit, and have not experienced a single delay.
Quote:
We're starting with a question of why one server seems slower than another. ...the usual region-specific performance issues we we investigate with support tickets, like if that specific machine has a problem (e.g. a buddy region has a problem and is constantly restarting, using a lot of CPU or memory, or some other VM-specific problem).

Since my regions are 2x2s, what "buddies" will they have that are not mine?

Jim Tarber wrote:
...So it's probably not the bots, and probably not something specific to that region, but rather a general performance concern (like the asset fetch times we don't have a workaround in place for yet, or the kinds of machine issues I mentioned above).

Why is it "probably not bots"? Wasn't there bot code changed in the last release? And if it isn't the bots, doesn't anyone want to find out why there are giant hangs in processing? (the frozen in place issue that you keep telling me is the Calling Card bug, except I do not have that bug).

Jim Tarber wrote:
AstoriaL wrote:
I have had no success with submitting tickets for issues like these. Reluctant to do so again. It's possible that something new in the server code has exposed an issue that the conditions of this region are in the proper state to discover what it is. One difference I am sure of is there are several bots on this region where the issue happened several times in a row, and none on the region where the issue didn't happen.
It seems presumptuous to think it's related to a server update if it's not happening on other updated regions.

It seems presumptuous to aggressively assert that it is not something related to your change and additionally delaying with making that response for several days, presumably while not bothering to look at the server, so that now whatever conditions were in place when I made the report might not be able to be examined.

The last time I tried to report something like this in a ticket (when I was being sent to a "nearby region" on login last month, even though the region I was trying to log into was online) the response was that they were able to get to the region/login/logout. Then the ticket was closed. That sounds a lot like the problem some people are having now, it's unfortunate that nobody wanted to look at the server logs.

Ah, luck. I just went and logged directly into Mare Volcani wearing the same costume I was wearing and with which I have logged in instantly every time with on other regions (all of which had no bots on them) since I made this report, and it still has the 2 minute delay with restoring all my attachments. I then teleported to Mare Sireni which is on the same 2x2 block, logged out and back in, and experienced 0 delay with loading my attachments. There are no bots on that region. If you choose to examine the info I have provided, then it would seem to still be available.

[edited to add: When only one factor has changed in a situation (the server rollout in this case) and nothing else has changed, and an issue suddenly starts happening, of course I am going to "presume" that the thing that changed is suspect as the cause. I am not trying to particularly "blame" anything for whatever is happening-- since I do not have the ability to access the data that would provide that info I am left to only guess. I am pointing out that it is going on and that data might be available to point to a fix for one or more issues and improve the grid.]



_________________
One could write a history of science in reverse by assembling the solemn pronouncements of highest authority about what could not be done and could never happen. ~ Robert A. Heinlein
Offline
 Profile  
 
 Post subject: Re: InWorldz 0.9.19 R5825 Server Upgrades
PostPosted: Fri Dec 18, 2015 9:05 pm 
User avatar

Joined: Mon Jun 07, 2010 7:07 pm
Posts: 7936
Location: Nova Scotia, Canada
AstoriaL wrote:
I logged into one region several times and experienced huge delays loading the same outfit I continued to wear. I did not experience such delays prior to the server rollout.

Since then, I have been logging in to a different region, again wearing the same outfit, and have not experienced a single delay.
The reason I mentioned the A-B-A-B and A-B-B-A tests were to know if that is consistent/significant or not. Have you repeated whatever you are doing in the different region, back in the first to see if it is reproducibly slow in one region vs another? If you test in A B A B, and get slow fast slow fast, that's a fairly solid test that identifies a region-specific problem, or at least two classes of performance that may extend to other regions

AstoriaL wrote:
Since my regions are 2x2s, what "buddies" will they have that are not mine?
The regions on any given machine are somewhat random (the order of the adds and/or other regions being removed). Before it was a 2x2, your region was not alone on that machine, so there are others after 2x2 conversion. We need to check all of the regions on a machine for issues (especially CPU and memory usage and high updates/loops) when a performance issue is reported that appears to be region-specific. More often than not, it is a VM(machine)-specific issue in a totally unrelated region that happens to be noticed by someone who monitors their own regions more closely than the one with the problem. This is what support does, but once discovered, development also likes to know of these cases so that we check if there's something more we can do to make them more automated or to prevent it from happening if it was something caused by a script, for example.

AstoriaL wrote:
AstoriaL wrote:
4 of them are skating on tours, very occasionally they collide. But neither of the issues I reported have happened before this week and the bots have been skating there for a month. The other two are just hanging out on pose stands.
...
Why is it "probably not bots"?
I was agreeing with you. Unless they were colliding a lot, we haven't seem much trouble with bots lately. There was no reason to suspect them after you reported the above, and no issues before the update, so I was agreeing with you that if they seemed okay to you, then they were probably okay.
AstoriaL wrote:
Wasn't there bot code changed in the last release?
No. I don't really know why you would think there was.

AstoriaL wrote:
And if it isn't the bots, doesn't anyone want to find out why there are giant hangs in processing? (the frozen in place issue that you keep telling me is the Calling Card bug, except I do not have that bug).
I don't think I've mentioned it again once you checked your Calling Cards folder and reported it wasn't a problem in your case. I ruled that out at that point. In terms of investigating a possible region problem, yes, that is what Support does so get a ticket in on it. Development is very very tied up with multiple releases and upcoming holidays that we do not want to impact on the users with releases or bugs that have been identified so far.

AstoriaL wrote:
Jim Tarber wrote:
AstoriaL wrote:
I have had no success with submitting tickets for issues like these. Reluctant to do so again. It's possible that something new in the server code has exposed an issue that the conditions of this region are in the proper state to discover what it is. One difference I am sure of is there are several bots on this region where the issue happened several times in a row, and none on the region where the issue didn't happen.
It seems presumptuous to think it's related to a server update if it's not happening on other updated regions.
It seems presumptuous to aggressively assert that it is not something related to your change and additionally delaying with making that response for several days, presumably while not bothering to look at the server, so that now whatever conditions were in place when I made the report might not be able to be examined.
Sorry if that sounded harsh in some way; I'm just reporting the facts. When you say "your change", what are you referring to? If it was the update, why wouldn't the update affect all regions? Or at least what is the basis for assuming that it's something an update when it seems to be a performance issue, in one single region? My point was that I think it's a bit to fast to jump to a conclusion that there is some kind of code change here affecting one region and not others without some evidence of that, or something that actually fits with one of the code changes that might only affect certain regions.

I've been working with the code and doing this professionally here for five years, and three decades before InWorldz. I have learned the key to finding the cause of a problem is to not make assumptions about the cause of a problem. You can go with your spider sense initially, but if it doesn't pan out very quickly, abandon all assumptions and try to identify the specific facts.

Jim Tarber wrote:
Ah, luck. I just went and logged directly into Mare Volcani wearing the same costume I was wearing and with which I have logged in instantly every time with on other regions (all of which had no bots on them) since I made this report, and it still has the 2 minute delay with restoring all my attachments. I then teleported to Mare Sireni which is on the same 2x2 block, logged out and back in, and experienced 0 delay with loading my attachments. There are no bots on that region. If you choose to examine the info I have provided, then it would seem to still be available.
That's the test where you should then teleport back to Mare Volcani, relog and see if the 2-minute delay is back. At least an A-B-A test. When the good one follows the poor one, it's difficult to know if a completely unrelated problem was just resolved by the completion of the A (Mare Volcani) test finally finishing. For example (and I'm not suggesting this is the case), if you had some kind of DNS problem or a utility that auto-flushed the DNS cache or any number of probably hundreds of network things, and relogging in Mare Volcani forced a refresh that took 2 minutes, then relogging in Mare Sireni might benefit from the previous login in Volcani. You would then need to repeat the A->B relog test with a B->A order (and fairly quickly after the A-B test) to know if it's definitely an issue with A or the other unforeseen possibilities. I will check the logs from about 3pm IW time to see if there is any errors or timeouts. I suspect that what I may find there is some long asset fetches that just didn't happen on Mare Sireni. We won't know why, but that wouldn't be related to the server code or the updates. Mostly because I am not aware of any changes that would have symptoms anything like this, so there's little evidence that it is related to a code change, especially a performance issue. We have several known performance-related problems, the general asset fetch delays, and now the post-login calling cards delay. As a result, those two are going to be checked first when someone reports a post-login delay, as they (by far) are going to be the most likely causes of delays. If this is specifically a script delay, that's a bit different (rules out the calling card issue since that is viewer-end).

AstoriaL wrote:
[edited to add: When only one factor has changed in a situation (the server rollout in this case)
Do you know which rollout it was that you are referring to? The most recent R5825 to fix the online status caching problem (on December 15)? Or the initial 0.9.19 R5810 update (December 1)? Also a R5816 update to fix a deadlock case went out December 4, and the fix for region environment settings being discarded after a change was in R5820 on December 9.

AstoriaL wrote:
[edited to add: When only one factor has changed in a situation (the server rollout in this case) and nothing else has changed, and an issue suddenly starts happening, of course I am going to "presume" that the thing that changed is suspect as the cause.
I've been doing this for 35 years and one thing I can definitely say (and there aren't many things I can definitely say) is that much more than the update changed; that is one of many changes (most of them environmental or network). I'm suggesting that not you, not I, can diagnose this or should spend much time speculating on the cause of this report until at least a basic support investigation to check the regions has been done. If it is reported as a performance issue, and you get a response back that says they can teleport there, by all means raise heck to support over that. (You're reporting a performance issue, not a down region.) But the usual behavior for abnormal region performance is for them to do sanity checking of the whole machine, and check the consoles for anything repeating, on all of the regions on that machine (not just your 2x2 regions), and if that turns up nothing, it's then escalated to a support mystery for some digging to see if any particular object in the region is triggering a region problem (usually to Elenia because she is good at finding those things), and if the region seems fine and yet this problem remains, we may have to do things like grab stack traces to see where the server is spending most of its time, and other developer diagnostic techniques.

Having a long ongoing support discussion in the release thread is counter-productive. I couldn't even remember what the original symptoms reported were; I think it's your message about script dropouts way back here. (Is that the same "dropout" problem?) And were those the scripts detecting dropouts part of the bots that you mentioned earlier? Or scripts in a different object? But then it turned to attachments rezzing after a relog, so I'm not sure if these are the same issues or separate ones; a bit of a moving target of what the performance issue is. When I was replying to your previous message, I didn't know it was script dropouts you were reporting (actually still not sure). This is why it's good to get it organized and investigated separately. If you want a region performance issue investigated, it starts with a support ticket, to check the machine, and as specific symptoms as you have. For example, if there's another region with a CPU problem on that machine (this is the most common performance-related region issue seen), support might be able to resolve it quickly without us speculating. I don't know (and I'm not going to assume anything, or if I do, I'll assume that it is likely the same thing we find when others have reported these same symptoms in the past).

Let's get the process started. In the meantime, since you repeated the A-B test and got the same results at a specific time, I'll check the log for that time to see if there's anything obvious, because it's costing more time to try to get you to report it than it would take to check personally.


Offline
 Profile  
 
 Post subject: Re: InWorldz 0.9.19 R5825 Server Upgrades
PostPosted: Fri Dec 18, 2015 9:53 pm 
User avatar

Joined: Thu Sep 09, 2010 2:22 pm
Posts: 1755
Location: Pacific NW
Jim every single time I have logged in at Mare Volcani since just before I reported the issue, my attachments take 2 minutes to rez. Several logins.

Every time I log in anywhere else including the other region I logged in on right afterwards on the same 2x2, I take 0 minutes for them to rez.

Also several logins. Same viewer same outfit same everything.

I don't know how I can be more plain. I don't feel inclined to do more testing again and again and again when it seems rather clear that you would rather write these long posts than actually just look at the region log. It is quite mystifying. I have avoided going to that region since I logged on last so that there wouldn't be any data there to confuse the logs, and I am rather fond of it because that is where I skate.

If you're not interested in getting any debugging info from there just say so and we can both stop wasting our time.

[edited to make the timeframe more clear, bolded]

[edited again to add: this issue is not earlier ones, it only started happening after the last emergency rollout]



_________________
One could write a history of science in reverse by assembling the solemn pronouncements of highest authority about what could not be done and could never happen. ~ Robert A. Heinlein
Offline
 Profile  
 
 Post subject: Re: InWorldz 0.9.19 R5825 Server Upgrades
PostPosted: Sat Dec 19, 2015 1:46 am 
User avatar

Joined: Mon Jun 07, 2010 7:07 pm
Posts: 7936
Location: Nova Scotia, Canada
Oh my. I said (twice) in my previous message that I was going to check the logs (now complete). Normally we wouldn't be running a support escalation in the forum, but you seem quite insistent on that. So okay, where to start...

Either I missed it, or you didn't actually bother to answer my questions, like which change you were referring to, which rollout you felt was a problem, why you thought there was a bot change, etc. I also asked about whether the problem was a delay/dropout in scripts, or if it was a delay in rezzing, or some other delay such as seeing the bots upon login. I'm getting mixed messages; one of the messages indicated script dropouts, your latest two say "my attachments take 2 minutes to rez". Does that mean (as it sounds) that it takes 2 minutes before you see the attachments in the viewer? Or 2 minutes before a startup message comes out indicating a script in an attachment has been loaded?

I'd still like to know the answer which of those last two possibilities it is, because if it is a delay in scripts becoming active on login into a region, I believe I now know why that is. If it is some other symptom such as the delay in the attachments or bots rezzing, or something else, I don't know the answer to that one yet. I asked these questions because I was trying to work with the information you were reporting here, even though what we really needed was for support to take a look at the machine.

Jim Tarber wrote:
Let's get the process started. In the meantime, since you repeated the A-B test and got the same results at a specific time, I'll check the log for that time to see if there's anything obvious, because it's costing more time to try to get you to report it than it would take to check personally.
AstoriaL wrote:
If you're not interested in getting any debugging info from there just say so and we can both stop wasting our time.
I was interested in finding the actual cause. I was not interested in debugging something that we had no evidence needed debugging, and needed a basic support checkup first. I had no interest in shirking my responsibilities to do someone else's job. I have taken time to answer your many questions from your repeated posts in detail, but if you are going to use my detailed responses as some kind of problem, then we have a problem. You're now accusing me of not being interested because I'm focused on the development side rather than doing someone else's job. You insist it is not a machine issue, without us checking that first, and that it must be a code change causing the delays. (After investigation, it seems to be a machine issue, not a code change.)

I told you what you need to do to get the process going, but you refuse. So I already (in the previous message) reluctantly agreed to bypass the process and that I would checking the logs for clues myself, which also means doing the same initial support inspection of the machine status that I felt was the most important first step. I agreed to check the logs in that message twice, but you seem to have ignored that in your latest post. Now that I've checked the machine (and the logs), let's get to the actual facts:

That normal support review shows that the machine has some possible problems to be concerned about. The increase to 2x2s seems to have put a memory strain on the machine. It is still within engineering targets for memory usage but two of the buddy regions (not the ones in your 2x2) are doing thousands of page faults per second. I believe that is slowing down the compiles. It may be causing other slowdowns on your initial entry into that VM (machine), and I felt other slowdowns on the system desktop as soon as I connected to that machine.

So it wasn't processor usage in buddies as I suspected it might be; it was one of the other things I mentioned it might be: memory usage in the region buddies, and page faults that may result from the memory usage in two of the buddies. But it's not particularly high memory use; I think the key symptom on the machine is that those two buddy processes are triggering a lot of page faults. We'd need to investigate that (if you file a support ticket to get it started, since resolving the page faults may or may not resolve the specific issue you are reporting with attachments).

So I believe the problems on two of the buddy regions is impacting your login to the 2x2. At this point, there is no reason at all to believe that the machine problems are related to the server update in any way.

Then the critical info that I think was left out is that you are prepping the test by crossing into a neighbor region that you will then relog in. Crossing over transfers compiled versions of all the attachment scripts. This is all in-memory and when you relog, those scripts are already compiled and cached, in-memory, on the target login region, so they are loaded much faster than just a login to that region.

If you tried the test in the other order, the B-A test, it may or may not result in the roles being reversed; that would have pointed to caching. But once the scripts are cached, the test is tainted so you can't really just do it one way and then the other. Also, the page faults of the buddy regions was not constant, so it's not a simple test.

This is an example of why there is no such thing as a controlled test, even with an ABAB or ABBA test, after restarting both regions, and getting consistent differences between A's and B's. Even then, there's no way to control all the variables. First, as I mentioned caching taints it. Also, neither of us have any way of knowing if a user on one of the buddy regions was testing some rogue script with a nasty bug that rezzed too many physical objects all over the place (accidental griefing), or hosting a special holiday event, or naval battle that was generating high load, or something of that nature, during one test but not the next (or vice versa).

So I know there's some kind of problem on two of the buddy regions, but I don't know what triggered that or when it became a problem. It may have been triggered by the region restarts that accompanied one (or all) of the rollouts. Often we do find problems triggered by the restarts, and although the actually code changes / upgrades have no bearing on the problem, it looks like the rollout "caused" something. We get reports every update that the rollout "broke" something, but we have to collect the facts and check the machines and then investigate and more than 9 times out of 10, if the it was triggered then, it was the restarts, not the code change that triggered an issue on a region. The first step in that process is identifying which region or regions may have a problem on the machine. In this case, it seems to be a problem in regions other than yours.

Jim Tarber wrote:
I will check the logs from about 3pm IW time to see if there is any errors or timeouts.
The logs showed everything pretty much normal, except that there are about 50 scripts in the attachments when you log in and it's taking almost 2 minutes to compile them. (I suspect this slow compile is a result of the two buddy regions with the high page fault activity.) This is why I asked if the symptom is messages from attached scripts, or the visibility of the attachment itself.

On a crossing there is no recompile, it's all in memory, and on a relog we also have a compile cache. That's a fairly recent change; if you come back fast enough, you'll not only get the precompiled version, you'll also get the in-memory cached copy of the script (super fast). I think this is consistent with your observed behavior.

AstoriaL wrote:
[edited to add: When only one factor has changed in a situation (the server rollout in this case) and nothing else has changed, and an issue suddenly starts happening, of course I am going to "presume" that the thing that changed is suspect as the cause.
The only thing that changed in the code that was relevant here is that the one of the new script caching performance improvements may have hid the problem on any region you crossed into. So it could make the performance on the second region much faster, and less affected by the buddy region problem possibly even hiding the machine-wide problem there. Specifically this change:
Jim Tarber wrote:
- Added an unloaded script cache to the Phlox loader, to prevent disk thrashing when scripts are rapidly loaded and unloaded during rez/derez, e.g. temporary objects.
This would also help to lessen the negative effects of buddy regions causing the same disk thrashing, since it would avoid needing to go to the disk for compiles or even to load the compiled script code. It applies the same performance improvement that we've put in crossings to also be applied on a relog after a crossing.

I'm sorry if I sound annoyed, but I have my own responsibilities and being hijacked to do someone else's job and more or less forced to explain why that is the case in the forums here is the absolute least efficient use of my limited time. We have procedures in place to avoid these problems and if you are unsatisfied with them you should contact the founders asking for a process change, not trying to monopolize development time or tell developers how to do their jobs. It's only because I care about what you and others think that I let this thread continue to get derailed over what should be a normal support escalation of a performance issue. If you are unhappy with the previous handling of a support ticket, bring that up with the founders rather than attempt to bypass the process, which is in place for a reason, in spite of our small size.


Last edited by Jim Tarber on Sat Dec 19, 2015 2:17 am, edited 3 times in total.

Offline
 Profile  
 
 Post subject: Re: InWorldz 0.9.19 R5825 Server Upgrades
PostPosted: Sat Dec 19, 2015 1:54 am 
User avatar

Joined: Mon Jun 07, 2010 7:07 pm
Posts: 7936
Location: Nova Scotia, Canada
AstoriaL wrote:
[edited again to add: this issue is not earlier ones, it only started happening after the last emergency rollout]
The only change in that was:
Quote:
- [R5825] This update fixes problems with user connection caching which could find stale connection info, which caused the last login location / online presence problems referred to in update 4 at the top of this message.
The online presence/last login fix, to restore the User server code to the way it was in November. The caching of connection info in 0.9.19 (Dec 1) was a little overzealous, and it needs to do a refresh on each login there at the central Login server.

This change in the most recent update does not affect the region code at all. This is why I was looking for another actual reason that would explain the symptoms you were seeing.


Offline
 Profile  
 
 Post subject: Re: InWorldz 0.9.19 R5825 Server Upgrades
PostPosted: Sat Dec 19, 2015 2:46 am 
User avatar

Joined: Thu Oct 20, 2011 3:41 am
Posts: 2392
Judy Dressler wrote:
Was this : viewtopic.php?p=200971#p200971
of any help?

Apparently my tests results, and post above it, raised no interest. At least feedback to acknowledge remaining issue.

As I said before "Last location" login issue is not solved for those who have it (every time). The fix did not fix it.

Will then live with it. Pretty annoying if you crash during an event and find yourself back at home at last login and have to tp back to event.


Offline
 Profile  
 
 Post subject: Re: InWorldz 0.9.19 R5825 Server Upgrades
PostPosted: Sat Dec 19, 2015 2:53 am 
User avatar

Joined: Thu Sep 09, 2010 2:22 pm
Posts: 1755
Location: Pacific NW
Jim Tarber wrote:
This is why I was looking for another actual reason that would explain the symptoms you were seeing.

A thought occurred to me tonight - perhaps there is something that is not being accomplished/refreshed by the rollout restarts, that a regular restart sets right. I didn't try restarting the region to make the issue go away because I thought debugging might be wanted.

I'm sorry but I don't have any more time to read the lengthy expositions of your latest posts. I will leave the region as is for a while because I don't have time to be there anyway, and will try restarting it Monday to see if that resolves the issues. Feel free to look at it if you want. Thanks.



_________________
One could write a history of science in reverse by assembling the solemn pronouncements of highest authority about what could not be done and could never happen. ~ Robert A. Heinlein
Offline
 Profile  
 
Display posts from previous:  Sort by  
 Page 11 of 12 [ 116 posts ]  Go to page Previous  1 ... 8, 9, 10, 11, 12  Next


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  

Site Navigation