Memory leak?

edited August 2011 in Photon Server
Hi guys,

I'm running a server that's basically LiteLobby, and every morning when I check out it's memory usage it's grown from <70 to 500+ MB.

I really haven't done that much to the code, and it's not got a lot of people using it (maybe 2-3 people log in every 12 hours).

So yeah, I was just wondering if you knew anything, had any suggestions etc.

Thanks,

NPSF3000

Comments

  • The garbage collector might be a bit lazy. Did you check the heap size counters of the .net garbage collector?
    Which server version do you run?
  • That did cross my mind, but other than implementing GC.Collect() I don't know how to test it.

    So how do I set, view, test etc. 'heap size counters'? Just point me in the right direction.

    According to the release_history_photon I'm on 2.6.0 - with the 100 free user license.
  • look at these performance counters with perfmon:
    http://msdn.microsoft.com/en-us/library/x2tyfybc.aspx
  • Somewhat frustrating experience to find these damn counters, but here's the result:

    http://dl.dropbox.com/u/20722643/QuickS ... unters.png

    While I do know the very basics of the GC... I'm not an expert, so I'll wait for your opinion :)
  • # Bytes in all Heaps: 783 MB
    Gen 2 Heap Size: 647 MB
    Large Object Heap Size: 136 MB

    So we know now there is a lot of data in gen 2. What we need to find out now is if it's there because the GC is lazy or because there are references to all these objects.

    The best tool for memory profiling is probably the ants memory profiler: http://www.red-gate.com/products/dotnet ... -profiler/.
    A free alternative is the CLR profiler: http://www.microsoft.com/download/en/de ... x?id=16273.
    These tools will tell you what objects are in memory and which classes hold their references.

    Instead of profiling you could also add a new operation that calls GC.Collect for gen2 that you can execute with a unit test for example. If you run it and the gen2 memory is not released we know that there really is a memory leak. And you might even be able to fix it yourself since you have the Lite source code.

    I know, that's a lot to ask and we will definitely take a look once we get photon 3.0 out there... so far though most memory leak suspicions were false alarms.
  • Thanks for that, I'll look into it.

    I'm no-were near blaming you, and the work will be good practice because I'm sure I'll be creating actual leaks down the track :)
  • Just restated application and attached MS profile.

    Of the 92MB's used 13 show up in profile (I ran the 100 test clients once), I'm assuming the rest are your C++.

    Leave it running overnight and see what it says.

    Note: Start Application failed to work so I had to attach to process... that means I'm not profiling allocations and calls.
  • Wild guess but could this be related to this case UDP Peers Growing?
  • Could be, but right now I've got 0 UDP peers connected :)

    When will photon 3 be out? I'm currently 'rapidly prototyping' and since I've only got one VPS (and need to start testing newer versions) it might be easier to just ignore it until V3 comes out.

    Edit; With that train of thought the source for the current server probably no longer exists.
  • There is a good chance to see 3.0 next week.
  • Then while this is a fascinating exercise... I'll ignore it for now.

    Should be a fairly easy migration?
  • Well, if you know how, yes.
    I guess we should write down the steps to make it easier for everyone.
Sign In or Register to comment.