leak

There is also the one caused by players and not sd2 spawned npcs: http://paste2.org/p/234378 **edit 2009-05-26 10:45:46 ERROR:GetInstance: object Playername(1234567), typeId 4, in world 0, should be in map 572,1581 but that's not loaded yet.

Do those changes affect the no.1 crashing reason, the famous GetInstance() bug, anyhow?

mangos: 7836 0.12 branch sd2: 1080 udb: 365 patches: anticheat, mtmaps #0 Player::IsAffectedBySpellmod (this=0x7f669cf5ec50, spellInfo=0x7f675ea49e88, mod=0xc000007f669d5ecc, spell=0x0) at ../../../src/game/Player.cpp:15811 http://paste2.org/p/225194 Another new one...

Is the part with the missing thread fixed?

I thought about that too, but running a server with over 1000 people online the pure amount of data made me hesitate. Since most of those log messages are of repetetive nature anyways i thought: Why not put those log messages into the db just like the mangos strings and call/log them just by an ID? Ofc not the deep core stuff but the whole game mechanics logs could use it i guess. This would also be a good step towards localisation of the mangos core (language patterns) just my 2 cents

Right, usually sd2 kills the server right away Thanks for fixing. *duck and gone*

mangos: 7836 0.12 branch sd2: 1080 udb: 365 patches: anticheat, mtmaps Freeze: #0 FreezeDetectorRunnable::run (this=0x7fb445bfaa20) at ../../../src/mangosd/Master.cpp:110 curtime = <value optimized out> http://paste2.org/p/216460 Tell me if i'm wrong but could the sd2 script in thread 15 be responsible for this freeze? @waza If you post freezes, you might wanna post the full crashlog. I doubt the pure debug output from the freeze checker thread is of any use.

mangos: 7836 0.12 branch sd2: 1080 udb: 365 patches: anticheat, mtmaps * 1 process 28245 Object::GetUInt32Value (this=0x400000001a1ab6f7, index=3) at ../../../src/game/Object.h:161 #1 0x000000000078de0a in Guild::_CanStoreItem_InTab (this=0x7fd9f9881390, tab=<value optimized out>, dest=@0x44928f80, count=@0x44928e54, merge=true, pSrcItem=0x7fd9650cff30, skip_slot=255 'ÿ') at ../../../src/game/Object.h:137 pItem2 = (class Item *) 0x400000001a1ab6f7 j = <value optimized out> http://paste2.org/p/215271 I think this bug will have its one year anniversary pretty soon..

mangos: 7836 0.12 branch sd2: 1080 udb: 365 patches: anticheat, mtmaps * 1 process 26117 Unit::InitCharmInfo (this=0x0, charm=0x0) at ../../../src/game/Unit.cpp:9978 http://paste2.org/p/214386 There is also the last log message from the server log, but no idea if it is related: 2009-05-18 00:20:02 ERROR:CastSpell: unknown spell id 0 by caster: creature (Entry: 20455) I tested the Terror Totem, but even while it is scripted by acid it doesn't do anything for me. Both casting the totem or the spell used by the totem doesn't crash the server for me.

mangos: 7836 0.12 branch sd2: 1080 udb: 365 patches: anticheat, mtmaps #0 0x00007f6ba5c9eee6 in std::_Rb_tree_rebalance_for_erase () from /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/libstdc++.so.6 No symbol table info available. #1 0x00000000006fb4de in Unit::RemoveAura (this=0x8f52b20, i=@0x4460fe30, mode=AURA_REMOVE_BY_DEFAULT) at /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/include/g++-v4/bits/stl_tree.h:1318 Aur = (class Aura *) 0x386e290 AurSpellInfo = (const SpellEntry *) 0x7f6b9d5fe0bc statue = <value optimized out> caster_channeled = <value optimized out> http://paste2.org/p/214367

mangos: 7836 0.12 branch sd2: 1080 udb: 365 patches: anticheat, mtmaps #2 0x00007f2b1dbb749f in __assert_fail () from /lib/libc.so.6 No symbol table info available. #3 0x00000000005b042e in MotionMaster::UpdateMotion (this=0x7f2a6a7529f0, diff=172) at ../../../src/game/MotionMaster.cpp:81 __PRETTY_FUNCTION__ = "void MotionMaster::UpdateMotion(uint32)" http://paste2.org/p/213689 Never seen this one before. Could it be from recent commits?

After reading that the Intel C++ Compiler outperforms VC9 by a minimum of 5-6% (even more on floating point) i gave it a shot with mangos. Using VS2008 Prof gave me the following results: 12>Compiling with Intel(R) C++ 11.0.072 [iA-32]... (Intel C++ Environment) [...] ========== Build: 12 succeeded, 0 failed, 0 up-to-date, 0 skipped ========== ScriptDev2 seems to compile fine too, but there is a problem with the linker. Intel's xilink doesn't seem to get that it supposed to replace the script functions from mangos by those from sd2. 1>Linking... (Intel C++ Environment) 1>xilink: executing 'link' 1>boss_lethon.obj : error LNK2005: _DllMain@12 already defined in boss_emeriss.obj 1>boss_taerar.obj : error LNK2005: _DllMain@12 already defined in boss_emeriss.obj [...] 1> Creating library ..\\..\\..\\..\\bin\\win32_release/MaNGOSScript.lib and object ..\\..\\..\\..\\bin\\win32_release/MaNGOSScript.exp 1>..\\..\\..\\..\\bin\\win32_release/MaNGOSScript.dll : fatal error LNK1169: one or more multiply defined symbols found Instead of linking the .obj created by sd2 it links the stuff from mangos again and places it in the bin/ folder. Maybe someone has an idea how to fix that. On a more important note: Does anybody have a hint how to get automake to use the Intel Compiler on Linux? Maybe another build system is needed to accomplish that. Would appreciate someone dropping some knowledge about that Intel Compiler available here: http://software.intel.com/en-us/intel-compilers/ (31days of free evaluation) **edit Alright got sd2 working too Had to remove BOOL APIENTRY DllMain( HANDLE hModule, DWORD ul_reason_for_call, LPVOID lpReserved ) from precompiled.h, now it is compiling and working fine too.

My config pretty much looks the same: net_buffer_length = 1024K join_buffer_size = 2M sort_buffer_size = 2M read_buffer_size = 2M read_rnd_buffer_size = 2M table_cache = 500 max_allowed_packet = 4M max_connections = 50 key_buffer_size = 16M thread_cache = 256M thread_concurrency = 8 thread_cache_size = 1024 thread_stack = 128K max_heap_table_size = 32M tmp_table_size = 32M long_query_time = 5 innodb_buffer_pool_size = 4196M innodb_additional_mem_pool_size = 50M innodb_data_file_path = ibdata1:10M:autoextend innodb_log_file_size = 172M innodb_log_buffer_size = 7M innodb_log_files_in_group = 2 innodb_flush_method = O_DIRECT innodb_flush_log_at_trx_commit = 0 innodb_thread_concurrency = 8 innodb_file_per_table innodb_table_locks = 0 max_connections is useless since mangos needs only about 4. the "key_buffer" variable doesn't exist and it is for MyISAM anyways My innodb_buffer_pool_size might be a little too big since my last db cleanup but i never heard that could hurt.

I've seen my mysql doing around 2000 qps without any problem. During mangos runtime the db server is almost idle with ~250 qps. I'd really like to try a config from someone who claims to have 2k ppl online without noticeable lag.

20095 mangos 20 0 3365M 3086M 9204 S 0.0 38.8 0:22.05 1 | `- ./mangos-worldd 20114 mangos 20 0 3365M 3086M 9204 S 15.0 38.8 18:41.60 3 | `- ./mangos-worldd net 20113 mangos 20 0 3365M 3086M 9204 R 15.0 38.8 19:02.37 3 | `- ./mangos-worldd net 20112 mangos 20 0 3365M 3086M 9204 S 0.0 38.8 2:08.27 4 | `- ./mangos-worldd 20111 mangos 20 0 3365M 3086M 9204 S 0.0 38.8 0:00.07 3 | `- ./mangos-worldd 20110 mangos 20 0 3365M 3086M 9204 S 3.0 38.8 8:36.75 3 | `- ./mangos-worldd 1 20109 mangos 20 0 3365M 3086M 9204 S 5.0 38.8 8:38.27 4 | `- ./mangos-worldd 2 20108 mangos 20 0 3365M 3086M 9204 S 0.0 38.8 0:05.35 3 | `- ./mangos-worldd 20107 mangos 20 0 3365M 3086M 9204 S 4.0 38.8 8:35.49 4 | `- ./mangos-worldd 3 20106 mangos 20 0 3365M 3086M 9204 S 7.0 38.8 8:40.32 3 | `- ./mangos-worldd 4 20105 mangos 20 0 3365M 3086M 9204 S 7.0 38.8 8:38.72 1 | `- ./mangos-worldd 5 20104 mangos 20 0 3365M 3086M 9204 S 3.0 38.8 8:38.34 2 | `- ./mangos-worldd 6 20103 mangos 20 0 3365M 3086M 9204 S 2.0 38.8 2:36.87 3 | `- ./mangos-worldd 20102 mangos 20 0 3365M 3086M 9204 S 7.0 38.8 8:35.39 2 | `- ./mangos-worldd 7 20101 mangos 20 0 3365M 3086M 9204 R 71.0 38.8 1h19:04 1 | `- ./mangos-worldd main 20099 mangos 20 0 3365M 3086M 9204 S 0.0 38.8 0:07.50 3 | `- ./mangos-worldd 20098 mangos 20 0 3365M 3086M 9204 S 0.0 38.8 0:47.75 3 | `- ./mangos-worldd 20097 mangos 20 0 3365M 3086M 9204 S 0.0 38.8 0:18.69 2 | `- ./mangos-worldd A new shot of racz new mtmaps patch. Clearly there is missing one thread (set to 8) and offloading the work from the main thread behaves like derex patch. It moves the lag border from 700 to 1100 for me but that's it - the hardware is still not really under load.

I also tried 8 vs. 4 threads on quadcore - same results. At 1100 ppl the spell lag starts to get annoying no matter which mtmaps patch i use. The database server is mostly idle (load: 0.01 0.04 0.00) doing around 250 qps.

I was refering to this list, but since i believe ppl who deal with this kinda stuff should be able to read man pages - no damage done 17695 mangos 20 0 3703M 3447M 9300 S 0.0 43.3 0:21.30 1 | `- ./mangos-worldd 17710 mangos 20 0 3703M 3447M 9300 S 18.0 43.3 1h41:22 3 | `- ./mangos-worldd <-- net? 17709 mangos 20 0 3703M 3447M 9300 S 18.0 43.3 1h42:48 1 | `- ./mangos-worldd <-- net? 17708 mangos 20 0 3703M 3447M 9300 S 1.0 43.3 24:41.06 2 | `- ./mangos-worldd 17707 mangos 20 0 3703M 3447M 9300 S 0.0 43.3 0:00.57 3 | `- ./mangos-worldd 17706 mangos 20 0 3703M 3447M 9300 S 13.0 43.3 1h23:22 2 | `- ./mangos-worldd <--map? 17705 mangos 20 0 3703M 3447M 9300 S 0.0 43.3 0:31.15 3 | `- ./mangos-worldd 17704 mangos 20 0 3703M 3447M 9300 S 11.0 43.3 1h23:23 3 | `- ./mangos-worldd <--map? 17703 mangos 20 0 3703M 3447M 9300 R 2.0 43.3 22:46.08 4 | `- ./mangos-worldd 17702 mangos 20 0 3703M 3447M 9300 S 11.0 43.3 1h23:25 4 | `- ./mangos-worldd <--map? 17701 mangos 20 0 3703M 3447M 9300 R 83.0 43.3 7h55:32 1 | `- ./mangos-worldd <--main? 17699 mangos 20 0 3703M 3447M 9300 R 0.0 43.3 0:45.92 4 | `- ./mangos-worldd 17698 mangos 20 0 3703M 3447M 9300 S 0.0 43.3 3:50.42 1 | `- ./mangos-worldd 17697 mangos 20 0 3703M 3447M 9300 S 0.0 43.3 2:15.37 1 | `- ./mangos-worldd This htop shot was taken from 1150 users. I must say that i can't really see any different load spreading amongst the cores/threads, i also have the impression that the what i call "main" thread is going now even higher than with derex patch. Another "weird" thing that i can't find the 4th map thread i added - usually there always were 4 threads with similar load. Also i can feel the spell lag coming back at 1100 compared to the 100% smoothness on 550 players. (p.s. Don't get me wrong, despite the quite negative feedback of mine i'm always open for stuff like that since every other effort failed to kill the spell lag past 1100ppl has failed so far)

Yep, it works for mangos. 11h uptime with 550 users max atm. Gonna give some more info about performance behavior later. Little addition: On gentoo i had to recompile gcc with +openmp USE flag and to use the -fopenmp (not -fomp, that doesn't exist - see man gcc) flag on the configure command.

Those are the only errors i get on VC90 9>..\\..\\src\\game\\MapManager.cpp(253) : error C2057: expected constant expression 9>..\\..\\src\\game\\MapManager.cpp(253) : error C2466: cannot allocate an array of constant size 0 9>..\\..\\src\\game\\MapManager.cpp(253) : error C2133: 'update_queue' : unknown size Troublemaker Map* update_queue[i_maps.size()]; Since the changes in configure.ac are for linux only, is there something reqiured to make VS aware of omp? @IAmParadox How are the "touches" doing?

Just for backchecking: This "short" patch is supposed to be a full replacement for derex mtmaps patch?

As much as i like to see dev action on that part of the deal i also believe it might be on the wrong side. For me the mtmaps patch is mainly to move the incredible ingame lag that starts at 700 users to ~1100 users, nothing more. The general lag issue is not solved by it and the systems ressources are far from being used. Vmaps are also not fully responsible from my tests, disabling them just moves the "lag border" a bit and that's all. Something still prevents mangos/trinity to eat all the ressources it can get Some ppl claim it is all about the database but from what i've seen my 5.0.70 mysql manages about 2000 qps (delete from) without problems. I also tried the experimental high performance version of mysql (http://www.percona.com/docs/wiki/percona-xtradb:start) without getting any noticable improvements. Atm it is just entirely beyond my understanding how someone can get lagfree past 1100 users (on core4quad 2.4ghz / 8GB for reference).

Somewhere on forums there is a small fix for getting mtmaps to work on windows. If i'm not all wrong it is just the order of the includes being made. Well, search function...

Uhm yea.. playercount? From what i know even with the mtmaps patch multiple cores aren't really helping with mangos.

Till now they are nothing more than gossip..

Even mtmaps does not get enough load out of the main thread..