g2p-studio leaks memory when used repeatedly

[joanise]

To reproduce, set block_size = 400 in g2p/tests/test_studio.py and observe the chromium process grow in memory and (usually) crash after a while as we try to process all the test cases. Set headless=False to observe the browser while this is happening.

After 100 cases, the process uses about 1GB of RAM and often dies soon after, so something is happening in the app in the browser that makes it unstable after it's been used to process many different queries in many different language pairs. The crash does not always happen at the same time, though.

Tested on Windows the python run_studio.py at the g2p root in one windows and ./test_studio.py in another. Also tested in CI with the test-studio job in studio-release-tests.yml which uses gunicorn to serve the app. The server does not seems affected, though, the problem is clearly the browser.

[joanise]

I had one instance of the test suite succeed with a block size of 400 with the latest tweaked version of the test suite, and it was taking 3.6GB by the time all 399 test cases were done. Watching the process go, the browser memory requirements do seem to be very close to linear in the number of test cases run.

[roedoejet]

Looks like there are general memory leak problems with web sockets :( https://github.com/websockets/ws/issues/804

I would guess that the problem is there or in HandsOnTable - the rest of the app is too basic to really have much of a memory leak problem I would guess

[joanise]

In that link, there is talk that disabling permessage-deflate helps. Could that apply to us?