Excessive RAM Usage

[mr-sp0ck]

The app has a tendency to manifest overly excessive RAM usage (sometimes up to 100%), whenever a (FineVPN) tunnel expires.

Commonsense could assume that, this particular behavior, is attributed to the verbose Connection logging, due to the aforementioned anomaly.

[brendanosborne]

Can you clarify the following:

whenever a (FineVPN) tunnel expires.

What Log setting are you using?

[mr-sp0ck]

Connection Status (default)

[brendanosborne]

When you opened the issue was there a template with troubleshooting steps? It lays out some information that helps to diagnose issues.

[mr-sp0ck]

I am currently using the App on Windows 10, with the FineVPN WireGuard configuration, for torrenting.

It is also possible that, such a devastating number of connections errors, at that point, could lead to aforementioned behavior.

[brendanosborne]

I can't help if you don't provide relevant data. If you would like assistance, please open an issue and fill in the template which asks for things like screenshots and testing on the standard Wireguard application. This is a free app, you'll need to put some effort in at your end.

[mr-sp0ck]

Ok. I will try to get a screenshot, in the next 20+ days, upon the next tunnel expiry.

[runner1409]

Connection Status Logs

it remains the same after enabling "Show All Logs" because logging is not updated.

After Disable/Enable on the Tunnel.

It just keeps using more and more RAM.


Takes less than 5 minutes to get to 16GB of ram. After 4-5GB the program can no longer be accessed. End Task is required.
SOLUTION: End Task, Run TunnlTo, Disable logging by going to settings, Show Connection Logs, Disable/Enable Tunnel.

[mr-sp0ck]

Actually, I get excessive RAM usage with 'Connection Status (default)' selected.

It only happens though, whenever my 30-day FineVPN WireGuard tunnel expires.

Commonsense can easily be applied then, to extrapolate that, this is more than likely due to the fact that, at this point, there is an overly excessive amount of verbose error logging taking place, due to infinite unsuccessful handshakes.

[runner1409]

That means that the logging itself is what's causing this issue, like the actual log entries, and it's not an issue with improper logging done by the "Show all logs" feature.

One thing I don't understand is why there are 6 edge instances running. the 2 at the top are the ones hogging all the ram, worse than chrome, so that means that this is about the way logging is done.

[mr-sp0ck]

Apps have a tendency to launch multiple instance of itself, for whatever reason(s):

• communicating with other processes
• linking with libraries,
• etc.

Obviously, the two instances hogging the RAM, are the ones that are immediately being used by the app.

Edge WebView2 is a framework, so all this is understandable. Think implementing features of a web browser, without using a whole web browser.

[mr-sp0ck]

With the app running normally, pay attention to the minimum number of instances of Edge WebView2, that it seems to invoke

[mr-sp0ck]

Also, pay attention to the fact that, it is the first three main instances of Edge WebView2 that seems to do all the work, hence, the main windows of TunnlTo, hence a logging fault.

[runner1409]

If you close the edge instances that use a lot of ram, the app will continue to function, but you won't get anything displayed on it.
So using edge for everything from rendering the app to logging is obviously what's causing this issue.
I've had it running since yesterday, without any problems. If handshakes do start to fail, then I will probably see an increase in ram usage.

Possible dev solution is to keep everything running with edge EXCEPT the logging itself, as well as the logging display and switch that to something more basic?
Possibly add some settings for logs to be capped at xMB, daily logs, keep logs for x days, keep max x entries in the log.

[mr-sp0ck]

I mentioned that precise solution in another Feature Request #149 , which is, adding the option to display connection errors only, but the dev's reply implied that, it is technically impossible, being that Wiresock is being run as an external process.

The memory hogging issue seems to arise from the fact that, Edge WebView2 is more HTML-based, rather than text-based (right-click the log window and 'Save as').

Your other suggestions make 100% sense BTW.

Also, another logical dev move, would be to suspend logging, as long as the handshake is unsuccessful, and indicate as such, until normal resumption.

[brendanosborne]

This should now be resolved in version 1.0.7 where I have implemented a log limit that can be adjusted in settings.