search

statianzo / Fleck

C# Websocket Implementation
MIT License
2.28k stars 583 forks source link

Memory leak #249

Open RandomKeys opened 5 years ago

RandomKeys commented 5 years ago

I've been using Fleck as a websocket server for some time and some times I've found a high memory usage and by doing some tests I've seen that the OnMessage branch does not completely disallocate some resources. To reproduce the condition I created an empty application with a WebSocketServer instance and sent messages every 10 minutes through client.html (which I found in the Fleck examples folder)

flecktest

To demonstrate the memory leak I made several snapshots

statianzo commented 5 years ago

Nice work. Any pointers to which object types are leaking?

RandomKeys commented 5 years ago

After message this objects always remains in memory: "ThreadPoolWorkQueue+WorkStealingQueue" and "HandleCollector+HandleType"

In the heap I also find an untyped "ArrayList" that increases

jmh76 commented 5 years ago

This open issue concerned me so I looked into it. Sent a message every 500ms from a Javascript timer. Took snapshots every 10 minutes, total run time 60 minutes.

Results from the Visual Studio memory usage performance profiler were a little unclear/inconsistent, but overall showed no significant memory leak. It was obvious with the ANTS memory profiler that there is no memory leak.

So either this has been fixed, or it was never an issue.

statianzo commented 5 years ago

Thanks for the review @jmh76! I'll close this and will reopen if someone finds otherwise.

RandomKeys commented 5 years ago

In 60 minutes the problem is not visible. If you try for 1 month every 300ms you lose about 450/500 mb of ram. For professional uses, a watchdog application is required :-\

jmh76 commented 5 years ago

I ran with ANTS overnight, client message every 100ms. I took a baseline snapshot at 5 minutes and another at 18 hours. Should be long enough to see similar results, especially with more frequent messages. 450MB per month is ~620KB per hour, or ~11MB for 18 hours.

After 18 hours the only additional .NET objects were 30 System.Threading.Thread instances totaling 1.5KB, all on the finalizer queue. Unmanaged memory was steady, actually went down a bit from 8.547MB to 8.309MB.

There was an increase in "unused memory allocated to .NET" from 2.176MB to 4.562MB. More than nothing, but much less than @RandomKeys got, and with no attributed object references. Probably due to frequent allocation/release of thread and data objects...

notgiven688 commented 5 years ago

@jmh76 try to disconnect and reconnect the client every 100ms. Does anything change?