궁금한 점이 있습니다. 6GB 스왑은 어디에 사용되나요? 내 커널 버전은 4.15.9-300.fc27.x86_64
.
이것은 약간의 충돌 후에 발생했습니다. dmesg
gnome-shell 프로세스(gdm에 속함)와 나중에 일부 firefox 프로세스(libxul.so의 Chrome_~dThread)에서 세그폴트가 발생했음을 보여줍니다. coredumpctl -r
현재 시작 시 다른 충돌이 표시되지 않습니다.
free
1.그리고df -t tmpfs
# free -h
total used free shared buff/cache available
Mem: 7.7G 1.2G 290M 5.4G 6.1G 761M
Swap: 7.8G 6.0G 1.8G
# swapoff -a
swapoff: /dev/dm-1: swapoff failed: Cannot allocate memory
# df -h -t tmpfs
Filesystem Size Used Avail Use% Mounted on
tmpfs 3.9G 17M 3.9G 1% /dev/shm
tmpfs 3.9G 1.9M 3.9G 1% /run
tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup
tmpfs 3.9G 40K 3.9G 1% /tmp
tmpfs 786M 20K 786M 1% /run/user/1000
또한 추가 tmpfs가 있는지 각 프로세스의 마운트 네임스페이스를 수동으로 확인했습니다. 마운트된 다른 tmpfs는 없습니다(또는 동일하므로 17M만 있고 다른 마운트 네임스페이스는 10개 미만입니다).
2.ipcs
# ipcs --human
------ Message Queues --------
key msqid owner perms size messages
------ Shared Memory Segments --------
key shmid owner perms size nattch status
0x00000000 20643840 alan-sysop 600 512K 2 dest
0x00000000 22970369 alan-sysop 600 36K 2 dest
0x00000000 20774914 alan-sysop 600 512K 2 dest
0x00000000 20905987 alan-sysop 600 3.7M 2 dest
0x00000000 23461892 alan-sysop 600 2M 2 dest
0x00000000 20873221 alan-sysop 600 3.7M 2 dest
0x00000000 22511622 alan-sysop 600 2M 2 dest
0x00000000 28278791 alan-sysop 600 60K 2 dest
0x00000000 23003144 alan-sysop 600 36K 2 dest
0x00000000 27394057 alan-sysop 600 60K 2 dest
0x00000000 29622282 alan-sysop 600 156K 2 dest
0x00000000 27426828 alan-sysop 600 60K 2 dest
0x00000000 28246029 alan-sysop 600 60K 2 dest
0x00000000 29655054 alan-sysop 600 156K 2 dest
0x00000000 29687823 alan-sysop 600 512K 2 dest
------ Semaphore Arrays --------
key semid owner perms nsems
0x002fa327 98304 root 600 2
3. 프로세스 메모리
이것스크립트를 이용한 프로세스별 교환프로세스 메모리는 스왑 영역 중 54MB만 차지한다고 합니다.
PID=1 swapped 2292 KB (systemd)
PID=605 swapped 4564 KB (systemd-udevd)
PID=791 swapped 324 KB (auditd)
PID=793 swapped 148 KB (audispd)
PID=797 swapped 232 KB (sedispatch)
PID=816 swapped 120 KB (mcelog)
PID=824 swapped 1544 KB (ModemManager)
PID=826 swapped 152 KB (rngd)
PID=827 swapped 300 KB (avahi-daemon)
PID=829 swapped 1688 KB (abrtd)
PID=830 swapped 836 KB (systemd-logind)
PID=831 swapped 432 KB (dbus-daemon)
PID=843 swapped 368 KB (chronyd)
PID=848 swapped 312 KB (avahi-daemon)
PID=854 swapped 476 KB (gssproxy)
PID=871 swapped 1140 KB (abrt-dump-journ)
PID=872 swapped 1280 KB (abrt-dump-journ)
PID=873 swapped 1236 KB (abrt-dump-journ)
PID=874 swapped 14196 KB (firewalld)
PID=911 swapped 592 KB (mbim-proxy)
PID=926 swapped 1356 KB (NetworkManager)
PID=943 swapped 17936 KB (libvirtd)
PID=953 swapped 200 KB (atd)
PID=955 swapped 560 KB (crond)
PID=1267 swapped 284 KB (dnsmasq)
PID=1268 swapped 316 KB (dnsmasq)
PID=10397 swapped 160 KB (gpg-agent)
PID=14862 swapped 552 KB (systemd-journal)
PID=18131 swapped 28 KB (login)
PID=18145 swapped 384 KB (bash)
Overall swap used: 54008 KB
지금까지 나는 의도하지 않은 프로그램이
umount -l
전체 tmpfs를 사용하지 않는다고 가정했습니다. 나는 숨겨진 tmpfs가 열려 있는 사람을 위해 /proc/*/fd를 가져오려고 시도하지 않았습니다.memfd
거인을 만들어서 켜는 사람도 없을 거라고 추측하고 있는 것 같아요 ...ㅋㅋㅋ 왜 그런 걸 의심하겠어요... 흐느껴요.
프로세스에 첨부된 memfd 이름은 제가 보기에는 아무런 문제가 없는 것 같습니다.
# ls -l /proc/*/fd/* 2>/dev/null|grep /memfd:
lrwx------. 1 alan-sysop alan-sysop 64 Mar 18 22:52 /proc/20889/fd/37 -> /memfd:xshmfence (deleted)
lrwx------. 1 alan-sysop alan-sysop 64 Mar 18 22:52 /proc/20889/fd/53 -> /memfd:xshmfence (deleted)
lrwx------. 1 alan-sysop alan-sysop 64 Mar 18 22:52 /proc/20889/fd/54 -> /memfd:xshmfence (deleted)
lrwx------. 1 alan-sysop alan-sysop 64 Mar 18 22:52 /proc/20889/fd/55 -> /memfd:xshmfence (deleted)
lrwx------. 1 alan-sysop alan-sysop 64 Mar 18 22:52 /proc/20889/fd/57 -> /memfd:xshmfence (deleted)
lrwx------. 1 alan-sysop alan-sysop 64 Mar 18 22:52 /proc/20889/fd/60 -> /memfd:xshmfence (deleted)
lrwx------. 1 alan-sysop alan-sysop 64 Mar 18 22:52 /proc/21004/fd/6 -> /memfd:pulseaudio (deleted)
Xorg
이러한 memfd는 다음과 같은 이유로 무해해 보입니다. 프로세스 20889 는 6GB의 스왑 공간보다 오래된 현재 프로세스입니다 . 다시 말하지만, 프로세스 21004는 실제로 내 pulseaudio 프로세스이며 해당 프로세스는 6GB 스왑 공간이 설정된 이후에 생성되었습니다.
이론적으로 제가 걱정하는 것들은 불확정 상태에 있을 수도 있고 유닉스 소켓 메시지에 첨부되어 전혀 읽히지 않을 수도 있습니다.
편집 1
중지 systemd-logind
(기본 Xorg는 죽어서 응답함)하고 Xorg를 다시 시작한 후 전체 6GB 스왑 영역이 지워지는 것을 확인했습니다.
다시 로그인을 시작해야 한다는 사실을 잊어버렸습니다. lennart가 logind가 버스를 통해 활성화되어서는 안 된다고 말했지만, logind는 즉시 다시 시작됩니다. 이는 journalctl -b
삭제된 메시지 없이 syslog에서 가져온 것입니다.
Mar 18 23:14:12 alan-laptop systemd[1]: Stopped Login Service.
Mar 18 23:14:12 alan-laptop dbus-daemon[831]: [system] Activating via systemd: service name='org.freedesktop.login1' unit='dbus-org.freedesktop.login1
Mar 18 23:14:12 alan-laptop systemd[1]: Starting Login Service...
이는 로그인 후 몇 번의 충돌을 겪는 반복과 관련이 있습니다. 이는 이 버전의 logind에서 예상됩니다(내 문제 보고서에 따라 이를 수정하기 위한 PR이 업스트림에 병합되었습니다).
따라서 이것이 개별 원인을 완전히 분리하는 것은 아닙니다. 실제로 fds logind를 종료하기 전에 무엇을 보유하고 있는지 확인해야 합니다.
질문
위 확인에서 가능한 Exchange 사용자를 놓쳤습니까? (EDIT1 이전의 비파괴적).
위에 나열된 가능한 사용자에 대한 사용 보고서를 얻을 수 있는 더 좋은 방법이 있습니까? 즉, 제가 인지하지 못한 일부 버그를 수정하는 대안이 있습니까? 아니면 이런 일이 다시 발생하면 실행하기 더 쉽고 빠르게 결과를 얻을 수 있는 방법이 있을까요?
"숨겨진" tmpfs가 열려 있는(분리된 tmpfs와 비교하여) fd를 확인하는 좋은 스크립트가 있는 사람이 있습니까 umount -l
?
memfd의 메모리 사용량을 확인하는 좋은 방법이 있는 사람이 있습니까?
memfd에 읽지 않은 unix 소켓 메시지가 많이 있는지 확인하는 방법이 있습니까? (이 천재들은 유닉스 소켓을 전달하도록 명시적으로 설계된 memfd를 구현할 때 이 점을 고려했습니까?)
편집 2: 그래픽 장치(DRM)의 파일 설명자가 스왑 가능한 메모리에 대한 참조를 보유할 수 있다는 제 추측이 맞나요? 참고 logind
해당 파일 설명자를 저장하십시오.
답변1
편집 1systemd-logind를 중지하고(네이티브 Xorg가 죽어 응답함) Xorg를 다시 시작한 후 전체 6GB 스왑 공간이 지워지는 것을 확인했습니다.
두 번째 이후에는 이것이 systemd-logind의 버그임을 확인할 수 있습니다. logind
보유하고 있는 DRM fd의 복사본을 닫아야 하지만 PID1에 저장된 복사본은 닫을 수 없습니다("원활한" 재시작 로그인 지원을 위해).
$ sudo lsof /dev/dri/card0 | grep systemd
[sudo] password for alan-sysop:
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
Output information may be incomplete.
systemd 1 root 16u CHR 226,0 0t0 14690 /dev/dri/card0
systemd 1 root 87u CHR 226,0 0t0 14690 /dev/dri/card0
systemd 1 root 101u CHR 226,0 0t0 14690 /dev/dri/card0
systemd 1 root 106u CHR 226,0 0t0 14690 /dev/dri/card0
systemd 1 root 110u CHR 226,0 0t0 14690 /dev/dri/card0
systemd-l 860 root 21u CHR 226,0 0t0 14690 /dev/dri/card0
systemd-l 860 root 25u CHR 226,0 0t0 14690 /dev/dri/card0
이것은 알려진 버그와 매우 흡사합니다.이것은 systemd v238에서 수정되었을 것입니다..
실제로 logind는 GNOME에 로그인하고 로그아웃할 때마다 이런 방식으로 DRM fd를 유출하는 것 같습니다. 아마도 이 버그는 디스플레이 서버가 비정상적으로 종료될 때만 명백해지기 때문에 DRM FD에 연결된 버퍼를 할당 해제할 기회가 없습니다.
편집 2: 그래픽 장치(DRM)의 파일 설명자가 스왑 가능한 메모리에 대한 참조를 보유할 수 있다는 제 추측이 맞나요? logind는 이러한 파일 설명자를 저장합니다.
대답: 그렇습니다.
필립
SHMEM 파일 노드는 교체 가능한 버퍼 개체에 대한 백업 저장소 역할을 합니다.
--https://www.kernel.org/doc/html/v4.15/gpu/drm-mm.html
내가 아는 한, 여기의 "SHMEM 파일 노드"는 tmpfs 파일/memfd와 정확히 동일하게 작동합니다. 위의 인용문은 "GEM 버퍼 객체"에 관한 것입니다...
mmap 시스템 호출은 자체 파일 핸들이 없기 때문에 GEM 객체를 매핑하는 데 직접 사용할 수 없습니다. 현재 GEM 개체를 사용자 공간에 매핑하기 위한 두 가지 대안이 공존합니다. 두 번째 방법은 DRM 파일 핸들에 대한 mmap 시스템 호출을 사용합니다.
--https://01.org/linuxgraphics/gfx-docs/drm/drm-memory-management.html#id-1.3.4.6.6.8
결론적으로:파일 핸들을 닫는 것과 관련이 있으므로 누군가는 로그인의 현재 코드를 실제로 다시 확인해야 합니다. :)
부록: memfd를 제외하는 방법
memfd의 메모리 사용량을 확인하는 좋은 방법이 있는 사람이 있습니까?
stat --dereference
memfd의 메모리 사용량은 또는 du -D
의 매직 심볼릭 링크를 사용하여 읽을 수 있습니다 /proc/$PID
. 파일 설명자 또는 fd/$FD
잊어버린 map_files/...
메모리 매핑 개체입니다.
이에 대한 훌륭한 시설은 없지만 최소한 가장 큰 단일 FD 또는 지도 파일을 검색할 수는 있습니다. (아래 예시는 추가 증거가 아니며 6GB 스왑 사용량이 사라진 후에 촬영되었습니다.)
$ sudo du -aLh /proc/*/map_files/ /proc/*/fd/ | sort -h | tail -n 10
du: cannot access '/proc/self/fd/3': No such file or directory
du: cannot access '/proc/thread-self/fd/3': No such file or directory
108M /proc/10397/map_files/7f1e141b4000-7f1e1ad84000
111M /proc/14862/map_files/
112M /proc/10397/map_files/
113M /proc/18324/map_files/7efdda2fb000-7efddaafb000
121M /proc/18324/map_files/7efdea2fb000-7efdeaafb000
129M /proc/18324/map_files/7efdc82fb000-7efdc8afb000
129M /proc/18324/map_files/7efdd42fb000-7efdd4afb000
129M /proc/18324/map_files/7efde52fb000-7efde5afb000
221M /proc/26350/map_files/
3.9G /proc/18324/map_files/
$ ps -x -q 18324
PID TTY STAT TIME COMMAND
18324 pts/1 S+ 0:00 journalctl -b -f
$ ps -x -q 26350
PID TTY STAT TIME COMMAND
26350 ? Sl 4:35 /usr/lib64/firefox/firefox
$ sudo ls -l /proc/18324/map_files/7efde52fb000-7efde5afb000
lr--------. 1 root root 64 Mar 19 00:32 /proc/18324/map_files/7efde52fb000-7efde5afb000
-> /var/log/journal/f211872a957d411a9315fd911006ef03/user-1001@c3f024d4b01f4531b9b69e0876e42af8-00000000002e2acf-00055bbea4d9059d.journal