17GB written to disk after 24h runtime (idle)
larsonmars opened this issue · comments
Bug Description
Threema-web (elektron app) does a lot of writing to disk. After 24h runtime it has witten ~17GB written to disk, when I have only sent 2 messages total (and received none). This strains SSDs unnecessarily.
Steps to Reproduce (for bugs)
- Open Threema web.
- Leave it running a day
- Inspect IO footprint
Potential Solution
This is probably due to the underlaying Chromium browser engine, where this is a known problem. I am unware of a fix currently.
Because a completely new solution for threema web is planned, this probably will not to be fixed in the current version, but I think it is worth to keep an eye on for the new desktop solution.
Currently, a workaround would be not to use the app in the first place, but another browser (e.g., fiorefox disabling cache and session store interval)
Your Environment
- Threema Web version: 1.1.0.0
- Computer operating system and version: Windows 10
Threema Desktop 1.0 should store almost nothing on disk. Can you point to the known problem with Chromium (perhaps on their issue tracker) you've mentioned?
If you search for "chromium writes ssd" you can find various entries from users (e.g., here at tomshardware).
There is also a long standing (2013) issue at their tracker here
Actually, every 'common' browser has a tendency to do lots of IO, even when being idle. I have found this in Chromium, Firefox and Edge. In Firefox it can be mitigated a bit by disabling cache (no problem as long as your connection is good) and increasing the session store interval (you may not be able to reopen all your last tabs on an unexpected crash).
I have not yet found a mitigation for Chromium, but also not really searched for one as I use it for development only.
However, I am not 100% sure that this is the actual reason. It is just that I expected (as you confirmed) that Threema Desktop has no reason to write anything to disk.
Okay, thanks for those pointers. Chromium does a ton of IPC and that may be caught as I/O. There are a couple of pointers in the referred issue on how to only catch disk writes which you may want to try.
Well I did not find anything about IPC (also note I did not use task manager, but process explorer, though maybe that does not make a difference with this).
However, you may be right that I did a wrong conclusion. Sorry for that! It appears that process explorer's documentation is lacking in terms of that column. At least I didn't find anything useful. Unfortunately, I do not know of sth. like iotop for Windows.
Anyway, thinking of the issue it occured to me that it could in fact have been Network IO. I did not even consider this, as I just had it running idle, not receiving/sending messages, whereas I had these cache/disk write problems with browsers in the past (verified not through task manager/process explorer, but through SMART monitoring of SSD wear).
So, could it be that the app does in fact a lot of (still unexplained) IO through the network? I had another issue when I tested the desktop app, which I wanted to report separately (after further investigation). Maybe those are linked after all:
When having the desktop app run idle, I noticed quite some battery drain from my smartphone (after I had done the test) and found threema (the mobile android app) to be the cause according to the Android-internal stats. Could there be a situation where desktop app and android app exchange a lot of data for a long time? Both devices have been in the same WLAN.
However, you may be right that I did a wrong conclusion. Sorry for that! It appears that process explorer's documentation is lacking in terms of that column. At least I didn't find anything useful. Unfortunately, I do not know of sth. like iotop for Windows.
The Chromium team gave some hints there, e.g. here.
My preferred way to capture all disk traffic from Chrome is to use sysinternals' procmon. If you configure this with a filter to record just "Process Name" is "chrome.exe" and "Operation" is "WriteFile" then it will capture just the essential information. You can then save this as a .pml file and share it with us.
I'd suggest to try that approach to poke less in the dark. 🙂
So, could it be that the app does in fact a lot of (still unexplained) IO through the network?
Unless you've uploaded/downloaded something close to a couple of GiB of data of media via Threema, e.g. videos and files, it's almost definitely IPC I/O what you're seeing there, i.e. Chromium talking to itself.
Since you're running Threema on Android, it uses P2P techniques and therefore a lot of keep-alive which explains battery drain. If you're searching this topic in the issue tracker, you'll find more information. Definitely not 17 GiB of keep-alive though, perhaps a low double-digit amount of MiBs if you're running it idle for 24h.
Could there be a situation where desktop app and android app exchange a lot of data for a long time?
Unlikely but bugs are always possible. You can see non what's happening on-the-wire in Threema Web/Desktop by looking at the console output / the log (see Troubleshooting). And when in doubt, tracing the network with Wireshark is an option, too.