이 문제를 디버깅하는 방법은 모르겠지만 많은 디스크 읽기/쓰기가 필요한 작업(대형 postgres 테이블 업데이트 등)을 수행하는 경우 주기적으로 실제 읽기 및 쓰기가 0으로 떨어지는 것을 확인했습니다. dm_crypt가 iotop에 있는 동안 IO 사용량은 99.9%로 표시됩니다.
게다가 여러 kworker 스레드가 생성되면 전체 DE가 자주 정지됩니다. 마우스는 계속 작동하고 이동할 수 있지만 약 30~60초 동안 다른 창은 응답하지 않습니다.
CPU는 항상 낮은 사용률을 유지하며 iotop에 표시된 여러 kworker 스레드와 동시에 정지가 발생합니다.
이는 정지 중 syslog 출력입니다.
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.
postgres 데이터베이스는 OS와 다른 디스크에 저장되므로 내 DE가 작성하는 동안 정지되어서는 안 됩니까? 이 문제를 추가로 디버깅하고 문제의 원인을 알아낼 수 있는 방법에 대한 제안 사항이 있는 사람이 있습니까?
인기 있는 운영 체제 20.04
5.4.0-7634-일반
답변1
이 문제를 해결하려면 vm.dirty_ratio 및 vm.dirty_Background_ratio를 편집해야 했습니다. 문제는 디스크가 처리할 수 있는 것보다 더 빠르게 디스크에 쓰고 있고 캐시가 가득 찰 때마다 시스템이 정지된다는 것입니다.