系统在启动7z后几分钟就完全没有响应了--如何解决这个问题？

Question

我以前从未遇到过这种情况，但大多数时候我都会小心地将一个nice ionice -c3放在要执行的命令的前面。但这一次，nice和ionice的使用只是推迟了效果。

无论哪种方式，我都使用Ubuntu20.04作为我的主要系统，即作为一台台式计算机。它是完全补丁和最新的，运行5.4内核(即没有其他可用的)。我正在使用Cinnamon运行它(是的，它是Ubuntu正确的，而不是Mint左右)，但是当我上次重新安装它时，系统必须通过服务器ISO安装，因为没有一个桌面ISO成功启动。我之所以提到这件事，是因为我不确定这是否会影响到这件事。

当我启动7z来压缩一个大小为几十个GiB的文件时，系统就完全没有响应了。无法切换到文本控制台，无法通过SSH连接，也无法移动鼠标.

从这种情况中恢复过来的唯一方法是对系统进行能量循环(在我的例子中，我长时间按下电源键)。

现在，我读到了一些关于Linux调度器的内容(在此之后我没有积极地修改它)，并且看到CFS (完全公平调度程序)是默认的调度程序，因为有些版本已经返回。然而，很明显，它是饥饿的所有其他进程，以一个程序启动好的ionice -c3 .一点也不公平。

systemd日志只显示文件系统驱动程序未能为驻留VM的进程编写文件系统驱动程序(VM同时运行)。

如何进一步诊断并最终修复此问题，从而使我打算用作桌面的系统不会完全失去响应？

注:我宁愿OOM杀手介入并狙击一些进程，而不是系统变得完全没有反应。但据我所知OOM杀手并不介意。

这个系统有64 GiB的内存，没有交换文件是活动的(我可以忍受一些程序因为内存不足而失败的情况)。

# sysctl -A | grep -v _domain | grep '\.sched'
kernel.sched_autogroup_enabled = 1
kernel.sched_cfs_bandwidth_slice_us = 5000
kernel.sched_child_runs_first = 0
kernel.sched_itmt_enabled = 1
kernel.sched_latency_ns = 24000000
kernel.sched_migration_cost_ns = 500000
kernel.sched_min_granularity_ns = 3000000
kernel.sched_nr_migrate = 32
kernel.sched_rr_timeslice_ms = 100
kernel.sched_rt_period_us = 1000000
kernel.sched_rt_runtime_us = 950000
kernel.sched_schedstats = 0
kernel.sched_tunable_scaling = 1
kernel.sched_util_clamp_max = 1024
kernel.sched_util_clamp_min = 1024
kernel.sched_wakeup_granularity_ns = 4000000

..。还有(UUID编辑) ..。

# cat /proc/cmdline
BOOT_IMAGE=/vmlinuz-5.4.0-73-generic root=UUID=xxx ro quiet loglevel=3 vga=current nosplash udev.log_priority=3 rd.systemd.show_status=auto rd.udev.log_priority=3 plymouth.enable=0

(后者是为了表明我没有告诉它使用不同的调度程序)

总体配置(稍微修改一下)：

# inxi -b -C -G -m
System:    Host: XXX Kernel: 5.4.0-73-generic x86_64 bits: 64 Desktop: Cinnamon 4.4.8
           Distro: Ubuntu 20.04.2 LTS (Focal Fossa)
Machine:   Type: Desktop System: Dell product: Precision 5820 Tower X-Series v: N/A serial: XXX
           Mobo: Dell model: 02M8NY v: A01 serial: /XXX/XXX/ UEFI: Dell v: 2.8.0 date: 01/15/2021
Memory:    RAM: total: 62.52 GiB used: 3.56 GiB (5.7%)
           Array-1: capacity: 3 TiB note: check slots: 8 EC: None
           Device-1: DIMM3 size: 16 GiB speed: 2666 MT/s
           Device-2: DIMM7 size: No Module Installed
           Device-3: DIMM1 size: 16 GiB speed: 2666 MT/s
           Device-4: DIMM5 size: No Module Installed
           Device-5: DIMM4 size: 16 GiB speed: 2666 MT/s
           Device-6: DIMM8 size: No Module Installed
           Device-7: DIMM2 size: 16 GiB speed: 2666 MT/s
           Device-8: DIMM6 size: No Module Installed
CPU:       Topology: 10-Core model: Intel Core i9-9820X bits: 64 type: MT MCP L2 cache: 16.5 MiB
           Speed: 1200 MHz min/max: 1200/4200 MHz Core speeds (MHz): 1: 1200 2: 1200 3: 1200 4: 1200 5: 1200 6: 1200 7: 1201
           8: 1201 9: 1201 10: 1201 11: 1200 12: 1200 13: 1201 14: 1200 15: 1200 16: 1200 17: 1200 18: 1200 19: 1200 20: 1200
Graphics:  Device-1: Advanced Micro Devices [AMD/ATI] Ellesmere [Radeon Pro WX 7100] driver: amdgpu v: 5.6.20.20.45
           Display: server: X.Org 1.20.9 driver: amdgpu unloaded: modesetting
           resolution: 1920x1080~60Hz, 1920x1080~60Hz, 1920x1080~60Hz
           OpenGL: renderer: AMD Radeon Pro WX 7100 Graphics v: 4.6.14756 Core Profile Context FireGL 20.45

Answer 1

如果系统锁定并变得完全没有响应，听起来您可能会耗尽内存。

在OOM杀手中启用更积极的选项可能有助于系统恢复，但无助于7z完成。

您可以使用cgroup来限制RSS，也可以使用ulimit来限制7z可以使用的内存，这可能会阻止锁定。仔细调整cgroup中的内存参数，可能会使7z在提高系统其余部分的性能的同时，使其运转良好。

添加交换空间可能允许将其他程序从内存中推送出去，从而为7z的运行释放更多的空间。

增加太多的交换空间可能会用重击代替OOM锁定，这只是稍微好一点而已。减少交换空间可能会让OOM杀手杀死任务而不是重击。

显然，如果7z内存不足，增加更多ram将是最有帮助的。