Jump to content

Issues appearing on high uptime


Recommended Posts

2) Instance binding IDs for players go crazy

At some point the instance id saving system doesn't really work anymore. The reset time in the /raidinfo window simply doesn't show up anymore and .instance listbinds shows that the ID of the instance remains until year 2038.

On the running server my test char got an ID for 2038 to reset. When i started that same db on my local mangos the ID was placed to 2nd Oct 6:00 so i believe it is not a db issue. (The timestamp in instance_reset is fine too)

Is someone experiencing similar issues?

Also noticed those SQL errors

SQL: INSERT INTO group_instance SELECT guid, instance, permanent FROM character_instance WHERE guid = '1217639'
SQL ERROR: Duplicate entry '1217639-1451' for key 1

Point 2 confirmed

http://getmangos.eu/community/viewtopic.php?id=9793

(might give it a bump)

Link to comment
Share on other sites

  • 39 years later...

Hey guys,

i'm encountering a few troubles that only seem to appear on high uptime. In my case i consider high uptime 50h+ with 900ppl online.

Currently running pretty much the lastest 0.12 branch rev (923e00df) with sd2 1410 (with backport patch to 0.12). I'm also running full vmaps for a while now without lags.

Issues:

1) Memory leaks caused by vmaps

I observed a constant memory growth when mangos is running for longer periods. At some point mangos consumed about 8GB of the servers memory. I never noticed when i only had partial vmaps enabled, so i believe there is some issue and this issue is aggravated by vmaps on world contintens.

If i'm not all wrong vmaps also still cause endless loops which get the server killed. I'm running a patch to prevent that, maybe those memleaks are also related to those endless loops.

It would be nice to know if someone is still working on vmaps.

2) Instance binding IDs for players go crazy

At some point the instance id saving system doesn't really work anymore. The reset time in the /raidinfo window simply doesn't show up anymore and .instance listbinds shows that the ID of the instance remains until year 2038.

On the running server my test char got an ID for 2038 to reset. When i started that same db on my local mangos the ID was placed to 2nd Oct 6:00 so i believe it is not a db issue. (The timestamp in instance_reset is fine too)

Is someone experiencing similar issues?

3) Lootable gameobjects become inaccessible

After a while GOs like mining nodes or herbs always show up empty and the problem here is they stay that way.

First i thought it was some sort of exploit and i actually found something. (Roughly: If two people trying to open a GO at the same time it becomes completely inaccessible afterwards, even for GM .respawn, i can give more detail on this if required). However, arrai came up with a fix (here) but he said himself that this wasn't a proper way and there is most likely a bigger problem in the loot system.

I've been running this patch for a while now but it looks like he was right and there is a bigger issue because mining nodes, etc. still become unlootable on high mangos uptime.

Thanks for reading.

Link to comment
Share on other sites

Our testserver once had an uptime of 140 days (not kidding, got a screenie of it even - almost no users on though). Memory useage stayed very much the same - even with full vmaps. So for option 1, it might be, but I would guess it's related to player interaction. Perhaps grid unloading is of some influence?

Points 2 and 3 are confirmed here as well. For point 2, I notice a lot of SQL errors for the instance primary key constraint. I guess changing the update into a replace would fix it, but since I have no idea how this will affect game mechanics I have so far not bothered to do so.

Link to comment
Share on other sites

I'm running the server with grid unload 0 but no idea how that affects vmaps.

Also noticed those SQL errors

SQL: INSERT INTO group_instance SELECT guid, instance, permanent FROM character_instance WHERE guid = '1217639'
SQL ERROR: Duplicate entry '1217639-1451' for key 1

Link to comment
Share on other sites

I can confirm all points which got described by Leak, the memory usage is increasing with Vmaps after a few days uptime. For me it gets to 5GB after 2-3 days~ Also instances make problems like mixed up cooldowns and the gameobject bug existed already in WoWD. I like to call it "realistic resource bug" :P

Link to comment
Share on other sites

3) Lootable gameobjects become inaccessible

After a while GOs like mining nodes or herbs always show up empty and the problem here is they stay that way.

First i thought it was some sort of exploit and i actually found something. (Roughly: If two people trying to open a GO at the same time it becomes completely inaccessible afterwards, even for GM .respawn, i can give more detail on this if required). However, arrai came up with a fix (here) but he said himself that this wasn't a proper way and there is most likely a bigger problem in the loot system.

I've been running this patch for a while now but it looks like he was right and there is a bigger issue because mining nodes, etc. still become unlootable on high mangos uptime.

in GameObject::Update

place this

       case GO_ACTIVATED:
       {
           switch(GetGoType())
           {
               case GAMEOBJECT_TYPE_DOOR:
               case GAMEOBJECT_TYPE_BUTTON:
                   if (GetGOInfo()->GetAutoCloseTime() && (m_cooldownTime < time(NULL)))
                       ResetDoorOrButton();
                   break;
_
               case GAMEOBJECT_TYPE_CHEST:
                   if (!isSpawned())
                       SetLootState(GO_JUST_DEACTIVATED);
_
                   break;
               default: break;
           }
           break;
       }

Link to comment
Share on other sites

  • 2 weeks later...

I've been running the patch for 2) (see above) for a while now and it seems that it fixes the problem at least for instances likes Zul'Aman and Zul'Gurub, yet for heroic instances it got worse. Now heroics don't even reset after a server restart. In the table instance_reset those heroic instances have all the same strange resettime of 5549918400 which is hardly a timestamp for this century..

Also in the instance table there are plenty of entries that have resettime 0 (instance id 556 AuchindounDemon with difficulty 1 for example, i suppose that's heroic?). I wonder what that is all about.

Something about the whole instance ID system is seriously flawed. I don't run an 3.x server so far, can anyone give an impression on how the behavior with instance resetting is there?

@zhenya

Do you have any source for this patch?

Link to comment
Share on other sites

Today ID reset went fine for all instances, at least ingame that is.

Checking the DB i found 3 maps having 5551387200 as reset time again, this time Zul'Gurub, Zul'Aman and AQ20 were affected. Yet ingame all instance reset times were fine, so the issue would only have appeared on a server crash when the false db values will be reloaded.

I still have no idea why ingame cycle works fine and db gets filled with wrong values.

Link to comment
Share on other sites

Today ID reset went fine for all instances, at least ingame that is.

Checking the DB i found 3 maps having 5551387200 as reset time again, this time Zul'Gurub, Zul'Aman and AQ20 were affected. Yet ingame all instance reset times were fine, so the issue would only have appeared on a server crash when the false db values will be reloaded.

I still have no idea why ingame cycle works fine and db gets filled with wrong values.

maybe there's an error in the insert-query and it doesn't take the correct number ? (i don't have the sources here, so i can't check it myself)

Link to comment
Share on other sites

  • 1 month later...
Guest
This topic is now closed to further replies.
 Share

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. Privacy Policy Terms of Use