Up to Main Index Up to Journal for December, 2015
JOURNAL FOR FRIDAY 18TH DECEMBER, 2015
______________________________________________________________________________
SUBJECT: Odd runtime memory patterns
DATE: Fri 18 Dec 22:13:58 GMT 2015
Busy week, but still managed a WolfMUD Wednesday - and Thursday - evening
session. However most of it was spent running tests against the new networking
code. I seem to have fixed the memory/goroutine leaks. In doing so I found
something odd. First some results gathered from testing:
#Players Max Alloc Max Heap Objects
1 164Kb 1,165
2 187Kb 1,256
4 230Kb 1,480
8 303Kb 1,480
16 379Kb 2,103
32 477Kb 2,630
64 668Kb 3,587
128 1Mb 5,290
256 1Mb 8,432
512 1Mb 15,055
1,024 6Mb 27,859
2,048 13Mb 72,402
4,096 33Mb 123,283
8,192 944Mb 260,687
This table show the maximum memory allocated and maximum of heap objects as
reported by runtime.ReadMemStats. For the maximum allocated memory the values
in megabytes should be read as "between X and X+1" due to no fractional parts.
It should also be noted that I have not implemented any optimisations yet.
For each number of players the server was started and the number of players
launched. Players move around randomly for a minute and then quit. This is
repeated ten times with out restarting the server between consecutive runs for
the same number of players, however there was a delay of 15 seconds between
consecutive runs. Each run of ten runs were run multiple times with the server
restarted between runs of ten.
All of the runs seem reasonable until we have 8,192 players. At which point
memory usage explodes. I need to investigate but I suspect slice capacity is
being doubled and redoubled - over and over - as 8,191 players interact with
8,191 other players. This seems to be a feasible hypothesis as the maximum
number of heap objects is roughly doubled from the run with 4,096 players -
which we would expect.
There is also something weird happening after about 7,000 players have
connected. Suddenly there will be a huge pause as if everything has locked up
then everything continues as before and the 1,000+ players connect without
issue. Initially I thought the pause was due to excessive contention on the
BRL - big room lock. Now I think it's due to huge memory allocations.
Now I'm happier with the networking code I still need to sort out broadcasting
messages to multiple locations. I'll probably clean up and commit what I have
now then work on the messaging issues. Maybe have a look at the memory
ballooning after that as I want try basing inventories on single linked lists
instead of a slice.
--
Diddymus
Up to Main Index Up to Journal for December, 2015