-
Notifications
You must be signed in to change notification settings - Fork 42
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Application totally frozen with large number of sources #716
Comments
@redshiftzero @kushaldas I saw this this evening. The UI was completely unresponsive, but in the background the client was busy downloading and decrypting submissions, until after a few hundred downloads a request timed out, it lost the connection to the proxy, and couldn't reconnect. In In I'm still looking into why I couldn't reconnect immediately after the timeout, when I should not have had more than one connection opened up to that point, and why I had these processes hanging around. My working theory is that they weren't getting cleaned up because when a request timed out, I was not calling It looks like the only way to recover if we get into this situation is to reboot |
interesting... so it seems like there are multiple issues, since the UI should not be non-responsive if the client is merrily downloading/decrypting (we must be running some blocking actions in the main event loop). I'll also note for posterity that I saw this non-responsive behavior / hanging forever not using qrexec i.e. making direct HTTP requests to the server container. we might need to workaround QubesOS/qubes-issues#5343 with a sleep after each network job |
Right now I was testing with 200 sources in the local docker container. Even after the network calls finished many minutes ago, the UI is still in frozen state, CPU at 100% and memory usage is 3.5GB and increasing. I will go down to 20-50 sources and try to profile first. Other wise, this state we can not even profile it properly. |
The UI is becoming unresponsive even when it is downloading submissions in a different thread. |
The number of times SourceWidget.init is getting called too much times. We can also cache in image loading (load_svg) call. This is for only 90 sources. Also the system was running out of open file descriptors. The major thing to note is the memory usage, for that 90 sources the total memory usage reached 1.5GB+ |
theory: it looks like |
@redshiftzero you win the internet for today. I've been trying out, fighting with and harrumphing at Python profiling tools that don't core dump when used with PyQt. ;-) This looks like a good theory to start with. I've just commented out the One solution would be to do inline-updates for the UI on the SourceList (much like we've done for the conversation view in the UI). |
@ntoll yes, just commenting out that |
I can confirm even with 1000 sources, the client is working fine. Though I did not look at the client for some time after logging in. |
I just noticed this testing the
get_sources
endpoint speed server-side: after successfully fetching data from that endpoint, for large numbers of sources, the application is totally frozen.STR
NUM_SOURCES=200 make dev
Expected behavior
Actual behavior
The text was updated successfully, but these errors were encountered: