在 Debian 12 上
无法防止终端 Python 程序导致桌面崩溃
grub command
GRUB_CMDLINE_LINUX="quiet splash memmap=15G$10G"
sudo update-grub
写了这些脚本
#!/bin/bash
# Set XDG_SESSION_ID to 1 (default session ID)
export XDG_SESSION_ID=1
# Identify the XFCE session PID under the current user
XFCE_PID=$(ps -eo pid,cmd | grep xfce4-session | grep -v grep | awk '{print $1}')
if [ -z "$XFCE_PID" ]; then
echo "XFCE session not found. Exiting script."
exit 1
fi
echo "XFCE session found. PID: $XFCE_PID"
# Define the cgroup name and the resource limits
CGROUP_NAME="xfce_group"
CPU_SHARES="512" # Relative weight
MEM_LIMIT="3758096384" # 3.5GB in bytes
# Path to the cgroup v2 hierarchy
CGROUP_PATH="/sys/fs/cgroup/$CGROUP_NAME"
# Ensure the script is running with sudo
if [ "$EUID" -ne 0 ]; then
echo "Please run this script with sudo."
exit 1
fi
# Create the cgroup directory if it doesn't exist
if [ ! -d "$CGROUP_PATH" ]; then
mkdir -p "$CGROUP_PATH"
fi
# Add the XFCE session to the cgroup
echo $XFCE_PID > "$CGROUP_PATH/cgroup.procs"
# Apply CPU and memory limits
echo $CPU_SHARES > "$CGROUP_PATH/cpu.weight"
echo $MEM_LIMIT > "$CGROUP_PATH/memory.max"
echo "XFCE cgroup configuration applied successfully."
当 Python 程序占用所有内存时,它仍然会导致 xfce 运行缓慢,甚至无法使用
zramctl
NAME ALGORITHM DISKSIZE DATA COMPR TOTAL STREAMS MOUNTPOINT
/dev/zram0 lzo-rle 5.3G 4.7G 989.4M 1.1G 16 [SWAP]
(rubix) top@top:/sda1$ sudo swapon --show
NAME TYPE SIZE USED PRIO
/dev/sdb1 partition 476.9G 2.9G -2
/dev/zram0 partition 5.3G 4.7G 32767
/sda1/swapfile file 256G 0B -3
total used free shared buff/cache available
Mem: 13979036 10602360 2273768 117388 1524640 3376676
Swap: 774131700 7935264 766196436
1950 mkdir /sys/fs/cgroup/unified/xfce_group
1951 mkdir /sys/fs/cgroup/unified/
1952 sudo mkdir /sys/fs/cgroup/unified/
1953 sudo mkdir /sys/fs/cgroup/unified/xfce_group
1954 echo '512' > /sys/fs/cgroup/unified/xfce_group/cpu.weight
1955 echo '3758096384' > /sys/fs/cgroup/unified/xfce_group/memory.max
<user> 1950 mkdir /sys/fs/cgroup/unified/xfce_group
1951 mkdir /sys/fs/cgroup/unified/
1952 sudo mkdir /sys/fs/cgroup/unified/
1953 sudo mkdir /sys/fs/cgroup/unified/xfce_group
1954 echo '512' > /sys/fs/cgroup/unified/xfce_group/cpu.weight
1955 echo '3758096384' > /sys/fs/cgroup/unified/xfce_group/memory.max
<username> ALL=(ALL) NOPASSWD: /usr/local/bin/xfce_cgroup.sh
答案1
cgroups
不为程序分配、保留或保证内存。
cgroups
(控制组)用于限制应用程序的资源消耗。设置memory.max
设置 cgroup 中程序的内存使用上限,以防止它们使用超过指定内存。如果程序试图分配超过限制的内存,则会被 OOM-killer 终止。
为了防止 Python 程序导致桌面崩溃,你需要应用cgroups
对 Python 程序应用内存限制,以防止其分配过多内存。
不建议在具有 13 GB RAM 的系统上分配 738 GB 的交换空间。
答案2
保留 Debian 12 内存...以防止内存不足错误?
这不是解决问题的方法。
您说的是内存不足错误还是 OOMKiller?
如果程序无法分配足够的内存来运行,那么要么购买更多内存,要么重写程序/使用其他程序。
对于 OOMKiller 来说,情况要复杂一些。如果你浏览互联网,你会看到很多人谈论使用 oom_adj 来处理 OOM 情况。这也不是解决问题的方法。
OOMKiller 事件的发生是因为内核承诺给应用程序的内存比系统可用的内存多。这是设计使然。通常,程序不会使用它们要求的所有内存。有时内核会出错。
解决问题的方法有三种:
用内存来解决问题,直到问题消失。这不是最可靠的方法,但通常可以作为快速修复。你显然在这个问题上做得过火了,没能解决问题。
调整所有可执行文件的内存使用量,使其保持在预期范围内。对于工作站(相对于服务器主机)来说,这实际上不是一个实用的解决方案。
告诉内核不要过度使用太多内存。将过度使用模型设置为静态限制 (vm.overcommit_memory=2),然后以绝对或相对方式指定过度使用的数量 (vm.overcommit_kbytes 或 vm.overcommit_ratio)
答案3
Linux 上的内存预留可能会出现问题,因为它可能导致内存使用效率低下,并可能妨碍系统处理动态内存需求的能力。当内存被预留时,它实际上被锁定用于特定进程或目的,这可能会阻止系统根据不断变化的需求有效地重新分配内存。如果预留的内存没有被指定进程充分利用,或者其他进程可以从中受益,这可能会导致资源浪费。此外,过度预留可能会导致内存争用问题和性能下降,因为系统会尝试管理冲突的内存请求。因此,通常建议允许 Linux 内核根据系统需求动态管理内存,而不是静态预留内存。