Author Topic: Gather output of mud_status(1)  (Read 2613 times)

Offline FallenTree

  • BFF
  • ***
  • Posts: 482
    • View Profile
Gather output of mud_status(1)
« on: September 06, 2013, 12:31:04 PM »
Hi,

I want to gather some data the output of mud_status(1) ,  just execute this in your mud's busiest moment and past the output here:

you can simply do "eval write(mud_status(1));"

This efun prints out some statistics of various aspect of the driver that I'm optimizing. (FluffOS 2.x also works)

Cheers.

Offline wodan

  • BFF
  • ***
  • Posts: 434
  • Drink and code, you know you want to!
    • View Profile
Re: Gather output of mud_status(1)
« Reply #1 on: September 06, 2013, 02:57:56 PM »
enjoy, some numbers will have wrapped

"Open-file-test succeeded.
current working directory: /home/atuin/lib

add_message statistics
------------------------------
Calls to add_message: 25822882   Packets: 17220288   Average packet size: -123.344498

Function cache information
-------------------------------
% cache hits:         74.32
call_others:     4233179030
cache hits:      3146018061
cache size:           65536
slots used:       311258561
% slots used:     474942.87
collisions:       775902408
% collisions:         18.33

Object name hash table status:
------------------------------
Average hash chain length:             3.31
Average search length:                 1.06
Internal lookups (succeeded):    5927713 (5927713)
External lookups (succeeded):    1430449947 (1367299778)

Heart beat information:
-----------------------
Number of objects with heart beat: 919, starts: 107609
Percentage of HB calls completed last time: 100.00

All strings:
-------------------------    Strings    Bytes
All strings:          8541417 196199272 + 213382616 overhead
Total asked for         231000118 -659910111
Space actually required/total string bytes 3%
Searches: 581126119    Average search length:  0.778

Call out information:
---------------------
Number of allocated call outs:     5800,   324800 bytes
Current length: 2630

Offline wodan

  • BFF
  • ***
  • Posts: 434
  • Drink and code, you know you want to!
    • View Profile
Re: Gather output of mud_status(1)
« Reply #2 on: September 06, 2013, 02:59:48 PM »
that wasn't quite the busiest moment, but I don't think it changes all that much

Offline FallenTree

  • BFF
  • ***
  • Posts: 482
    • View Profile
Re: Gather output of mud_status(1)
« Reply #3 on: September 06, 2013, 03:06:13 PM »
your apply cache size is quite small!  I guess you are using #define APPLY_CACHE_BITS 16  , you should consider more bits if possible.

i have a patch to reduce the collisions too,  it would reduce cpu a lot, we will see once 3.0-alpha7.4 is finished.

Offline wodan

  • BFF
  • ***
  • Posts: 434
  • Drink and code, you know you want to!
    • View Profile
Re: Gather output of mud_status(1)
« Reply #4 on: September 06, 2013, 04:13:48 PM »
it's small because when it was big some interaction between shadows and the apply cache would crash us, I could never find the cause for those, however the apply cache code has changed in 3.0 and it may have been related to the set_jump problems, so we could try a bigger cache again when 3.0 is out

Offline FallenTree

  • BFF
  • ***
  • Posts: 482
    • View Profile
Re: Gather output of mud_status(1)
« Reply #5 on: September 06, 2013, 04:18:51 PM »
well, it could be result of any memory corruption actually.   all my current muds uses very little shadowing, it would be nice to test more on that area.  (have you tried following http://fluffos.github.io/bug.html Valgrind section?)

Offline wodan

  • BFF
  • ***
  • Posts: 434
  • Drink and code, you know you want to!
    • View Profile
Re: Gather output of mud_status(1)
« Reply #6 on: September 06, 2013, 04:19:48 PM »
on a slightly related note

we noticed the other day that
int i = memory_info();
evaluate((:1:));
return  memory_info()-i

actually returns negative numbers so memory_info() will be systematically too low (also because it doesn't track all allocations)

despite that it's just gone negative (32 bit wrap) on discworld, should make it a 64 bit counter, perhaps it already is in 3.0


Offline FallenTree

  • BFF
  • ***
  • Posts: 482
    • View Profile
Re: Gather output of mud_status(1)
« Reply #7 on: September 06, 2013, 04:22:26 PM »
File a bug!

Offline wodan

  • BFF
  • ***
  • Posts: 434
  • Drink and code, you know you want to!
    • View Profile
Re: Gather output of mud_status(1)
« Reply #8 on: September 06, 2013, 04:23:52 PM »
well, it could be result of any memory corruption actually.   all my current muds uses very little shadowing, it would be nice to test more on that area.  (have you tried following http://fluffos.github.io/bug.html Valgrind section?)

I do try to run with valgrind sometimes, but within 10 minutes everything slows to a crawl and nothing useful comes out anymore, while those crashes would typically happen after about 1 or 2 hours. I have fixed things that showed up, but it never seemed related to those particular crashes (it did find some other ones which were already fixed).

Offline FallenTree

  • BFF
  • ***
  • Posts: 482
    • View Profile
Re: Gather output of mud_status(1)
« Reply #9 on: September 06, 2013, 04:31:33 PM »
That could potentially solved by running under AddressSanitizer  .  which could be faster.  But still, it's hard to track down this kind of problem.

Offline FallenTree

  • BFF
  • ***
  • Posts: 482
    • View Profile
Re: Gather output of mud_status(1)
« Reply #10 on: September 10, 2013, 10:00:30 PM »
Any one else get a output?

Here's one from one of the biggest chinese mud running the improved version of 3.0alpha7.4

new release reduced about 20% cpu for them , Note the increased apply cache size and hit rate,  this release is going to be awesome :-D

eval write(mud_status(1))
"Open-file-test succeeded.
current working directory: /home/lonely/nitan

add_message statistics
------------------------------
Calls to add_message: 251556121   Packets: 67805760   Average packet size: -10.591489

Hash table of living objects:
-----------------------------
8495 living named objects, average search length: 3.96

Function cache information
-------------------------------
% cache hits:         91.64
call_others:     1637197483
cache hits:      1500396611
cache size:         4194304
slots used:          516098
% slots used:         12.30
collisions:       136284774
% collisions:          8.32

Object name hash table status:
------------------------------
Average hash chain length:            31.80
Average search length:                 1.08
Internal lookups (succeeded):    7646202 (7646202)
External lookups (succeeded):    1478627194 (1476265806)

Heart beat information:
-----------------------
Number of objects with heart beat: 2613, starts: 57083
Percentage of HB calls completed last time: 100.00

All strings:
-------------------------        Strings    Bytes
All strings:                     1541320 26049787 + 37057216 overhead
Total asked for                 77866107 568157863
Space actually required/total string bytes 3%
Searches: 1493746196    Average search length:  1.296

Call out information:
---------------------
Number of allocated call outs:     1687,    94472 bytes.
Current handle map bucket: 3739
Current handle map load_factor: 0.451190
Current object map bucket: 126271
Current object map load_factor: 0.134457
Number of garbage entry in object map: 15291
"

Offline Stavros

  • Acquaintance
  • *
  • Posts: 36
    • View Profile
Re: Gather output of mud_status(1)
« Reply #11 on: October 03, 2013, 04:54:46 PM »
This is with 1 day and 18 hours of uptime. It's not from the busiest time of the day, but it's not the lightest either. Running FluffOS 2.24 at the moment.

Code: [Select]
eval write(mud_status(1))
Open-file-test succeeded.
current working directory: /home/swmud/lib

add_message statistics
------------------------------
Calls to add_message: 800989   Packets: 204494   Average packet size: 314.636464

Hash table of living objects:
-----------------------------
3707 living named objects, average search length: 2.67

Function cache information
-------------------------------
% cache hits:         99.76
call_others:      188596436
cache hits:       188140877
cache size:         1048576
slots used:          343595
% slots used:         32.77
collisions:          111964
% collisions:          0.06

Object name hash table status:
------------------------------
Average hash chain length:             4.63
Average search length:                 1.03
Internal lookups (succeeded):    20669 (20669)
External lookups (succeeded):    4156737 (4132803)

Heart beat information:
-----------------------
Number of objects with heart beat: 133, starts: 76461
Percentage of HB calls completed last time: 100.00

All strings:
-------------------------        Strings    Bytes
All strings:                      230869  7389101 + 3759440 overhead
Total asked for                 -45455421 -391386500
Space actually required/total string bytes -2%
Searches: 65448630    Average search length:  1.575

Call out information:
---------------------
Number of allocated call outs:      580,    16240 bytes
Current length: 351