Plasmashell操作にメモリリークがありますが、/proc/$pid/mapsをダンプしても犯人は明らかになりません。

Plasmashell操作にメモリリークがありますが、/proc/$pid/mapsをダンプしても犯人は明らかになりません。

私のopenSuse Leap 15.4システムで実行されているプラ​​ズマシェル操作にメモリリークがあります。定期的にプラズマシェルpidの/proc/$pid/mapをダンプし、2つのログの違いを取得します。

< 7fa3b795c000-7fa3b79d4000 rw-s 00000000 00:01 15204415                   /SYSV00000000 (deleted)
---
> 7fa3b7950000-7fa3b79c8000 rw-s 00000000 00:01 15302703                   /SYSV00000000 (deleted)

サイズが 15204415 から 15302703 に増加し、これはシステム RAM がゆっくりと消費されていることを示しています。

インターネットで/SYSV00000000を探しましたが、共有メモリの内容でした。

これをより具体的に理解し、メモリリークを正確に見つける方法は何ですか?

現在、Plasmaデスクトップの詳細は次のとおりです。

Operating System: openSUSE Leap 15.4
KDE Plasma Version: 5.24.4
KDE Frameworks Version: 5.90.0
Qt Version: 5.15.2
Kernel Version: 5.14.21-150400.24.28-default (64-bit)
Graphics Platform: X11
Processors: 6 × Intel® Xeon® CPU E5-1650 v2 @ 3.50GHz
Memory: 31.3 GiB of RAM
Graphics Processor: llvmpipe

どうやって進めますか?

唯一の解決策は、setid()コマンドを使用して実行中のタスクをpid 1に接続し、Plasma5セッションからログアウトして新しいセッションとして再度ログインすることです。これは、システムRAMが消費されたときにこのプロセスが無限に繰り返されるのを避けるためです。 。

ベストアンサー1

James:私の問題に対する答えを見つけました。問題の原因は、KDEデスクトップのスライドショーオプションでした。このオプションをオフにすると、メモリリークが停止しました。実際には/proc/self/maps領域で定期的にデータをダンプして比較してみましたが、スライドショーを閉じた後はログファイルの比較で問題がなくなりました。お客様の質問に関して、「htop」を使用して、プラズマシェル操作に使用されるシステムメモリの割合を確認しました。私はこれがシステムRAMであると仮定します。しかし、問題はとにかく解決されました。

おすすめ記事