splewis / get5

CS:GO Sourcemod plugin for competitive matches/scrims
GNU General Public License v3.0
558 stars 176 forks source link

Always handle GOTV memory leak problem, remove feature to toggle fix #921

Closed nickdnk closed 1 year ago

nickdnk commented 1 year ago

I do not like the get5_demo_postpone_stop option that I added. I think it's better to default to handling this gracefully instead of forcing users to "find out if it works or not".

This way, we always wait with stopping the demo recording until GOTV has broadcast, an add another 10 seconds of grace-period if there is a tv_delay (which causes the bug; flushing to disk does not freeze GOTV with no delay). With no delay or GOTV enabled, the recording still stops 15 seconds after the match ends, like it did before.

I have confirmed the freeze/memory leak bug also on my own server by playing a 10 minute game with 9 bots using:

tv_delay 120 tv_snapshotrate 128

This is the result when the demo is stopped:

Completed GOTV demo "2022-10-26_02-02-26_scrim_map1_de_dust2.dem", recording time 757.9
StopRecording: 7680 frames flushed in 3.48 seconds

During those 3.48 seconds, the server does not respond and presumably this is what also freezes GOTV. The memory consumption of the srcds process also goes up to around 2.5GB from around 700MB. sm_dump_handles gives a total SourceMod consumption of around 200MB before and after this operation, so it's definitely a bug in the game and not Get5, which seems to have been there for a long time: https://forums.alliedmods.net/archive/index.php/t-262232.html. We likely can't do anything about this. The memory consumption doesn't come down again, not by changing the map or doing tv_stop to entirely disable GOTV. It must be rebooted.

Also got rid of a constant that was only used in one place.

nickdnk commented 1 year ago

I've tried with tv_snapshotrate 32, 64 and 128 and the behavior is the same, although the memory leak size and demo flush time seems to increase as the snapshot rate goes up. On 128 it was almost 2GB leaked and 4-5 second flush but on 32 it was only about 1GB and around 1-2 seconds flush, so while there is a correlation on severity, the problem occurs with any snapshot rate. I don't think there is any good argument for retaining functionality to turn this stop-delay off.