I'm not sure how to debug this, but I've noticed if I am performing a task that requires a large amount of disk reads/write (such as updating a large postgres table) that periodically actual reads and write will fall to 0 while dm_crypt shows 99.9% IO usage in iotop.
On top of this the whole DE will freeze every so often as multiple kworker threads are spawned. The mouse continues to work and can be moved, but no other window responds for around 30-60s.
The CPU is at low utilization the entire time and the freezes coincide with multiple kworker threads showing up in iotop.
Here's the syslog output for the period of the freeze
Oct 22 11:09:47 pop-os /usr/lib/gdm3/gdm-x-session[3348]: (EE) client bug: timer event5 debounce: scheduled expiry is in the past (-6ms), your system is too slow Oct 22 11:09:47 pop-os /usr/lib/gdm3/gdm-x-session[3348]: (EE) client bug: timer event5 debounce short: scheduled expiry is in the past (-19ms), your system is too slow Oct 22 11:10:12 pop-os gjs[184224]: JS ERROR: Gio.IOErrorEnum: Timeout was reached _proxyInvoker@resource:///org/gnome/gjs/modules/core/overrides/Gio.js:139:46 _makeProxyMethod/<@resource:///org/gnome/gjs/modules/core/overrides/Gio.js:164:30 makeAreaScreenshot@/home/anthony/.local/share/gnome-shell/extensions/[email protected]/auxhelper.js:78:33 main/<@/home/anthony/.local/share/gnome-shell/extensions/[email protected]/auxhelper.js:190:21 main@/home/anthony/.local/share/gnome-shell/extensions/[email protected]/auxhelper.js:204:30 @/home/anthony/.local/share/gnome-shell/extensions/[email protected]/auxhelper.js:216:3 Oct 22 11:10:36 pop-os gnome-shell[3610]: JS ERROR: Error: cmd: gjs /home/anthony/.local/share/gnome-shell/extensions/[email protected]/auxhelper.js --filename /tmp/gnome-shell-screenshot-ZPGAT0.png --area 3640,809,948,419 exitCode=256 callHelper/<@/home/anthony/.local/share/gnome-shell/extensions/[email protected]/selection.js:87:16 Oct 22 11:10:50 pop-os gnome-shell[3610]: ../clutter/clutter/clutter-actor.c:10558: The clutter_actor_set_allocation() function can only be called from within the implementation of the ClutterActor::allocate() virtual function. The postgres database is stored on a seperate disk from the OS, so there shouldn't be any reason that my DE should freeze when writing to it? Does anybody have any suggestions on how I can further debug this and figure out what's causing the problem?
pop-os 20.04
5.4.0-7634-generic
