質問

質問

質問があります。 6GBスワップはどこで使用されますか?私のカーネルバージョンは4.15.9-300.fc27.x86_64

これはわずかな衝突の後に発生しました。 dmesggnome-shellプロセス(gdmに属する)と、後でいくつかのfirefoxプロセス(libxul.soのChrome_〜dThread)でセグメントが発生したことを示します。 coredumpctl -r現在の起動時に他の競合は表示されません。

free1.そして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

また、追加のtmpfがあるかどうかを各プロセスのマウント名前空間を手動で確認しました。他のマウントされた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

  1. これまで、私は意図しないプログラムが完全なumount -ltmpfsを使用しないと仮定していました。私は隠されたtmpfsが開いている人のために/ proc / * / fdをインポートしようとしませんでした。

  2. 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は、6 GBのスワップスペースより古い現在のプロセスです。繰り返しますが、プロセス21004は実際に私のpulseaudioプロセスであり、そのプロセスは6GBスワップスペースが設定された後に作成されました。

理論的には、私が心配しているものは不確定な状態にあるかもしれませんし、Unixソケットメッセージに添付されています。


編集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ソケットメッセージがたくさんあるかどうかを確認する方法はありますか? (これらの天才は、Unixソケットを渡すように明示的に設計されたmemfdを実装するときにこの点を考慮しましたか?)

編集2:グラフィックデバイス(DRM)のファイル記述子がスワップ可能なメモリへの参照を保持できるという推測は正しいですか?注logind対応するファイル記述子を保存してください。

答え1

編集1systemd-logindを停止し(ネイティブXorgが死んで応答する)、Xorgを再起動した後、6GBのスワップ領域全体が消去されることを確認しました。

2回目以降は、これが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オブジェクトをユーザースペースにマッピングするための2つの選択肢が共存しています。 2番目の方法では、DRMファイルハンドルに対するmmapシステムコールを使用します。

-https://01.org/linuxgraphics/gfx-docs/drm/drm-memory-management.html#id-1.3.4.6.6.8

結論として:ファイルハンドルを閉じることに関連しているので、誰かがログインの現在のコードを実際に再確認する必要があります。 :)


付録:memfdを除外する方法

memfdのメモリ使用量を確認する良い方法がある人はいますか?

stat --dereferencememfdのメモリ使用量は、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

関連情報