PhotonSocketServer.exe's memory increase repidly

When using Loadbalancing, steps to reproduce:
1.Loadbalancing Start as application
2.One client join a room(it means connected gameserver and join a game)
3.Generate multiple unity gameobjects with PhotonView, make them instantiate, move and destroy, keep the number of active gameobjects above 30, and PhotonView synchronizes these changes.
4.Stay in step 3 for 5 minutes.In my case, PhotonSocketServer.exe's memory increase from 157MB to 260MB.

Because only one client in the room, so there is no other clients accept PhotonView synchronous message. So that, the network pressure is basically in the client's PhotonView synchronization message sending part. If the number of the active gameobject is reduced to less then 6, the memory will remain in a certain size soon.
The default sync frequency for PhotonView is 10 times per second.The size of a sync message, 30 PhotonViews, is about 5 times larger than 6 PhotonViews.

Larger message bodies, with more memory growth, are supposedly correct.But why hasn't the memory stabilized after 5 minutes?After 24 hours, memory doesn't come down, it's still 260MB. Why?
How does this memory growth relate to the number of clients, constant or proportional?Unfortunately, how can I solve, mitigate, or limit this memory growth if it's proportional?

Comments

  • hi, @ling0kill

    this memory will not come down, because of how deserialization works. we allocate memory stream for a thread. The stream has 1Mb size and it stays there till stop of photon. Because inside we use the thread pool, it involves many threads. Each of them gets such memory stream.

    there is no way to change this

    best,
    ilya
  • ling0kill
    ling0kill
    edited June 2018
    Hi, @chvetsov

    This makes sense, if deserialization is a heavy workload, it's right to be handled by the thread pool.

    But why a client send messages at a steady and fast rate, PhotonSocketServer's memory keeps increasing for 5 minutes.Does that, by your interpretation, mean that the number of threads is also increasing for 5 minutes?

    In actual testing, it is almost certain that the memory growth in this case is not directly related to the number of clients.

    Best.
    chvetsov said:

    hi, @ling0kill

    this memory will not come down, because of how deserialization works. we allocate memory stream for a thread. The stream has 1Mb size and it stays there till stop of photon. Because inside we use the thread pool, it involves many threads. Each of them gets such memory stream.

    there is no way to change this

    best,
    ilya

  • >But why a client send messages at a steady and fast rate, PhotonSocketServer's memory keeps increasing for 5 minutes.Does that, by your interpretation, mean that the number of threads is also increasing for 5 minutes?

    because initially, thread pool has around 100 threads. gradually one by one they are involved into deserialization work.

    best,
    ilya
  • chvetsov said:

    >But why a client send messages at a steady and fast rate, PhotonSocketServer's memory keeps increasing for 5 minutes.Does that, by your interpretation, mean that the number of threads is also increasing for 5 minutes?

    because initially, thread pool has around 100 threads. gradually one by one they are involved into deserialization work.

    best,
    ilya

    Well, it's too slow.

    Is deserialization implemented in C++?

    If a message is larger than 1MB, does the steam double in size, or does it allocate multiple threads to deserialize the message and then concatenate it?
  • >Well, it's too slow.
    of course, native implementation will work faster. but it is not too slow ;)

    >Is deserialization implemented in C++?
    no.

    we do not allow too big messages. clients are not allowed to send more than 32Kb, S2S 512Kb. So we are safe in that sense. If you will try to send more than limit above, you will get an error

    best,
    ilya
  • Thank you very much for your answer.I saw your reply after the Dragon Boat Festival, a traditional Chinese festival.

    Best.