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.

linux

gcc 4.X (for openmp support)

add -fomp to compile flags

link mangos-worldd with gomp library

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..