You are not logged in.
Over the past couple days I'd notice periodic system slowdowns (sometimes every 2-5 minutes, lasting 10 seconds or so) where, for instance, videos would stutter and even typing into browsers would start to lag. This happens with multiple browsers. At the same time, I've been noticing that Xorg CPU usage would often climb during these short periods. I monitor processes that use the most CPU in conky, and in the past, Xorg would rarely show up at the top of the list, but during these slowdowns, it would typically show up at the top of the list with 25% usage. It usually happens when I have a browser open, but at least once I noticed the spike even when I had nothing open.
Any ideas how to troubleshoot this?
I didn't see any errors after running journalctl and the only other thing I thought to look at was the Xorg log, which does show messages like this repeated (though I don't know if it's related):
[ 11411.059] (EE) client bug: timer event29 debounce: scheduled expiry is in the past (-15ms), your system is too slow
[ 11413.197] (EE) client bug: timer event29 debounce short: scheduled expiry is in the past (-2ms), your system is too slow
[ 11414.095] (EE) client bug: timer event29 debounce: scheduled expiry is in the past (-13ms), your system is too slow
These are repeated multiple times, but not quite as often as there are slowdowns.
Any idea how to trouble shoot this? I googled the error message and tried searching the arch forums, but these terms usually show up with some other error (e.g., "libinput bug" instead of "client bug").
I'm using i3wm on a Core i5 with an nvidia 1060 and the proprietary drivers.
Last edited by slamhound (2020-07-25 00:25:08)
Offline
The debouncer errors are rather a symptom - the system isn't fast enough to process the input events.
X11 CPU load typically relates to some client banging the shit out of the server. Since this is a persistent issue, just start removing clients from the equation. Conky and i3bar are good contenders (some, maybe custom, script running wild)
Offline
Thanks, it does seem like it's probably i3bar, but maybe in interaction with something else? I turned off i3bar and didn't notice any problems, but did get the xorg log error one time in the seven or eight hours since I made the switch (as opposed to multiple times per hour when i3bar was on). I did recently switch back to i3bar from polybar, but never considered that that would be the problem, partly because i3bar never gave me a problem before and partly because the symptoms were subtle enough that it took me a while to recognize that they were happening. I'll mark this as solved, but just curious if you have any ideas why i3bar would start causing that problem when it hadn't in the past? Or any ideas about other things to check out that may have interacted with i3bar to cause this (especially since I did get the error once after turning off i3bar)?
Offline
One of the status_command's?
Offline
I've been experiencing a similar problem, and from what I can tell, it's definitely related to i3bar. It doesn't particularly seem to matter what the status_command is, the Xorg process will consume progressively more CPU until i3 is restarted. I'm not using a compositor.
I have had this problem with all of the following as my status_command:
i3blocks
goblocks
i3status
py3status
Configuration files:
i3blocks.conf
goblocks.yml
i3status.conf (which is also the same configuration file used for py3status)
For some reason this happens slightly less often (every few hours instead of every few minutes) on the linux-lts kernel (5.4) as opposed to linux (5.5).
glxinfo:
$ glxinfo | grep render
direct rendering: Yes
OpenGL renderer string: GeForce GTX 1660/PCIe/SSE2
GL_ARB_conditional_render_inverted, GL_ARB_conservative_depth,
GL_NVX_conditional_render, GL_NVX_gpu_memory_info, GL_NVX_nvenc_interop,
GL_NV_compute_shader_derivatives, GL_NV_conditional_render,
GL_NV_path_rendering, GL_NV_path_rendering_shared_edge,
GL_NV_stereo_view_rendering, GL_NV_texgen_reflection,
GL_ARB_compute_variable_group_size, GL_ARB_conditional_render_inverted,
GL_NVX_conditional_render, GL_NVX_gpu_memory_info, GL_NVX_nvenc_interop,
GL_NV_compute_shader_derivatives, GL_NV_conditional_render,
GL_NV_path_rendering, GL_NV_path_rendering_shared_edge,
GL_NV_stereo_view_rendering, GL_NV_texgen_reflection,
GL_EXT_multisample_compatibility, GL_EXT_multisampled_render_to_texture,
GL_EXT_multisampled_render_to_texture2,
GL_EXT_raster_multisample, GL_EXT_render_snorm, GL_EXT_robustness,
GL_NV_conditional_render, GL_NV_conservative_raster,
GL_NV_packed_float_linear, GL_NV_path_rendering,
GL_NV_path_rendering_shared_edge, GL_NV_pixel_buffer_object,
GL_NV_shadow_samplers_cube, GL_NV_stereo_view_rendering,
GL_OES_element_index_uint, GL_OES_fbo_render_mipmap,
GL_OVR_multiview_multisampled_render_to_texture
I'm using Fish shell if that helps at all, but switching my login shell to BASH or ZSH has not helped the problem at all.
That's about all that I have been able to figure out on my own.
Offline
I've switched to using polybar and spawning it as an exec statement from my i3 config instead of using the bar block. This seems to resolve the problem entirely, XORG never breaks 7% CPU usage at its peak. Seems to be an i3bar bug.
Offline
Seems to be an i3bar bug.
Please don't call anything a bug until you can prove it. It's much more likely to be caused by your own setup, in this case whatever configuration you're feeding i3bar.
Offline