시스템이 OOM-killer에 도달할 때까지 캐시/공유 메모리가 계속 증가하는 상황을 디버깅하고 있습니다.
눈에 띄는 효과 없이 sysctl.conf에 shmax 및 shmall을 설정했습니다. shmax/shmall이 제대로 작동하려면 더 많은 기능을 활성화해야 합니까? 아니면 시스템의 일부가 이 제한을 초과할 수 있으며 이를 얼마나 강력하게 시행할 수 있습니까? 버그가 있는 사용자 공간 애플리케이션이나 커널/드라이버의 버그로 인해 발생할 수 있습니까? 우리가 디버깅한 애플리케이션은 그래픽과 비디오 디코딩을 사용합니다. 운전자가 최대 한도를 초과할 수 있나요?
kernel.shmmax = 2147483648
kernel.shmall = 524288
Linux 커널은 5.15.71(Yocto Meta-Intel의)입니다. 우리 시스템에는 4GB의 RAM이 있고 스왑이 없습니다(스왑을 활성화하려고 시도했지만 시스템 안정성에 도움이 되지 않았습니다). 우리는 Wayland/weston을 사용하지만 systemd는 사용하지 않습니다. sysctl.conf에 값을 설정하고 재부팅하여 적용합니다. 우리는 ipcs를 통해서도 이 값을 확인했습니다. 공유 메모리를 최대 2GB로 설정해 보았습니다.
ipcs -l
------ Shared Memory Limits --------
max number of segments = 4096
max seg size (kbytes) = 2097152
max total shared memory (kbytes) = 2097152
min seg size (bytes) = 1
다음은 OOM에 도달하기 몇 분 전의 free, meminfo, smem 등의 일부 샘플 출력입니다.
free -w
total used free shared buffers cache available
Mem: 3844036 479428 263444 2711864 11324 3089840 585716
Swap: 0 0 0
#### cat /proc/meminfo
MemTotal: 3844036 kB
MemFree: 262680 kB
MemAvailable: 584940 kB
Buffers: 11324 kB
Cached: 3055620 kB
SwapCached: 0 kB
Active: 98764 kB
Inactive: 645792 kB
Active(anon): 732 kB
Inactive(anon): 394288 kB
Active(file): 98032 kB
Inactive(file): 251504 kB
Unevictable: 2708620 kB
Mlocked: 100 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 12 kB
Writeback: 0 kB
AnonPages: 386388 kB
Mapped: 162732 kB
Shmem: 2711864 kB
KReclaimable: 34208 kB
Slab: 68656 kB
SReclaimable: 34208 kB
SUnreclaim: 34448 kB
KernelStack: 4640 kB
PageTables: 5904 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 1922016 kB
Committed_AS: 4068728 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 15104 kB
VmallocChunk: 0 kB
Percpu: 1040 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
Hugetlb: 0 kB
DirectMap4k: 72236 kB
DirectMap2M: 3938304 kB
DirectMap1G: 2097152 kB
#### smem
PID User Command Swap USS PSS RSS
…..
1306 weston /usr/libexec/wpe-webkit-1.1 0 27192 51419 98928
1379 weston /usr/libexec/wpe-webkit-1.1 0 190268 214958 266040
Area Used Cache Noncache
firmware/hardware 0 0 0
kernel image 0 0 0
kernel dynamic memory 3030848 2938432 92416
userspace memory 555656 162732 392924
free memory 257532 257532 0
Map PIDs AVGPSS PSS
……
/usr/lib/libcrypto.so.3 20 527 10544
/usr/lib/dri/iris_dri.so 5 2196 10982
/usr/lib/dri/iHD_drv_video.so 1 20356 20356
/usr/lib/libWPEWebKit-1.1.so.0.2.6 5 14539 72697
[heap] 45 2060 92700
<anonymous> 45 5970 268688
편집: tmpfs에 대한 df 정보를 추가했습니다. df를 사용하여 표시된 tmpfs 마운트에서는 비정상적인 크기 증가가 표시되지 않습니다.
/# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/root 9.8G 1.9G 7.4G 21% /
devtmpfs 1.9G 2.1M 1.9G 1% /dev
tmpfs 1.9G 636K 1.9G 1% /run
tmpfs 751M 5.8M 745M 1% /var/volatile
tmpfs 40K 0 40K 0% /mnt/.psplash
답변1
SHMAX 및 SHMALL은 기타 품목의 크기를 제한하지 않습니다.임시 파일 시스템.
tmpfs는 전적으로 페이지 캐시와 스왑에 존재하므로 모든 tmpfs 페이지는 /proc/meminfo에서는 "Shmem"으로, free(1)에서는 "Shared"로 표시됩니다.
df이 유틸리티를 사용하면 시스템에 실제로 마운트된 파일 시스템 수를 확인 하고 궁극적으로 size=해당 마운트 작업의 매개변수를 통해 가능한 최대 크기를 제한할 수 있습니다.
물론, 애플리케이션이 이러한 종류의 파일 시스템을 사용하고 사용 가능한 스왑 공간이 없는 경우 애플리케이션은 장치에 남아 있는 공간을 찾을 수 없기 때문에 처리를 차단하거나 중지할 가능성이 높습니다.