4

組み込みLinuxプラットフォームでQtアプリケーションを実行しています。システムには128MBのRAM、512MBのNAND、スワップなしがあります。アプリケーションは周辺機器にカスタムライブラリを使用し、残りはすべてQtおよびc /c++ライブラリです。アプリケーションはSQLITE3も使用します。

2〜3時間後、マシンの実行が非常に遅くなり、シェルコマンドの応答に10秒ほどかかります。最終的にマシンがハングし、最終的にOOM killerがアプリケーションを強制終了し、システムが通常の速度で動作を開始します。

topコマンドを使用したいくつかのシステムメモリの観察により、アプリケーションの実行中、システムの空きメモリが減少しているのに対し、スラブは増加し続けていることがわかりました。これらは、以下に示すトップのスナップです。アプリケーションの名前はxyzです。

アプリケーション開始時：

Mem total:126164 anon:3308 map:8436 free:32456
 slab:60936 buf:0 cache:27528 dirty:0 write:0
Swap total:0 free:0
  PID   VSZ VSZRW^  RSS (SHR) DIRTY (SHR) STACK COMMAND
  776 29080  9228  8036   528   968     0    84 ./xyz -qws
  781  3960   736  1976  1456   520     0    84 sshd: root@notty
  786  3676   680  1208   764   416     0    88 /usr/libexec/sftp-server
  770  3792   568  1948  1472   464     0    84 {sshd} sshd: root@pts/0
  766  3792   568   956   688   252     0    84 /usr/sbin/sshd
  388  1864   284   552   332   188     0    84 udevd --daemon
  789  2832   272   688   584    84     0    84 top
  774  2828   268   668   560    84     0    84 -sh
  709  2896   268   556   464    80     0    84 /usr/sbin/inetd
  747  2828   268   596   516    68     0    84 /sbin/getty -L ttymxc0 115200 vt100
  777  2824   264   444   368    68     0    84 tee out.log
  785  2824   264   484   416    68     0    84 sh -c /usr/libexec/sftp-server
    1  2824   264   556   488    64     0    84 init

その後しばらくして ：

    Mem total:126164 anon:3312 map:8440 free:9244
 slab:83976 buf:0 cache:27584 dirty:0 write:0
Swap total:0 free:0
  PID   VSZ VSZRW^  RSS (SHR) DIRTY (SHR) STACK COMMAND
  776 29080  9228  8044   528   972     0    84 ./xyz -qws
  781  3960   736  1976  1456   520     0    84 sshd: root@notty
  786  3676   680  1208   764   416     0    88 /usr/libexec/sftp-server
  770  3792   568  1948  1472   464     0    84 {sshd} sshd: root@pts/0
  766  3792   568   956   688   252     0    84 /usr/sbin/sshd
  388  1864   284   552   332   188     0    84 udevd --daemon
  789  2832   272   688   584    84     0    84 top
  774  2828   268   668   560    84     0    84 -sh
  709  2896   268   556   464    80     0    84 /usr/sbin/inetd
  747  2828   268   596   516    68     0    84 /sbin/getty -L ttymxc0 115200 vt100
  777  2824   264   444   368    68     0    84 tee out.log
  785  2824   264   484   416    68     0    84 sh -c /usr/libexec/sftp-server
    1  2824   264   556   488    64     0    84 init

おかしなことに、アプリケーション自体に関連するtopの出力に大きな変化は見られません。最終的にアプリケーションは強制終了され、その後のトップ出力：

    Mem total:126164 anon:2356 map:916 free:2368
 slab:117944 buf:0 cache:1580 dirty:0 write:0
Swap total:0 free:0
  PID   VSZ VSZRW^  RSS (SHR) DIRTY (SHR) STACK COMMAND
  781  3960   736   708   184   520     0    84 sshd: root@notty
  786  3724   728   736   172   484     0    88 /usr/libexec/sftp-server
  770  3792   568   648   188   460     0    84 {sshd} sshd: root@pts/0
  766  3792   568   252     0   252     0    84 /usr/sbin/sshd
  388  1864   284   188     0   188     0    84 udevd --daemon
  819  2832   272   676   348    84     0    84 top
  774  2828   268   512   324    96     0    84 -sh
  709  2896   268    80     0    80     0    84 /usr/sbin/inetd
  747  2828   268    68     0    68     0    84 /sbin/getty -L ttymxc0 115200 vt100
  785  2824   264    68     0    68     0    84 sh -c /usr/libexec/sftp-server
    1  2824   264    64     0    64     0    84 init

dmesgは次のことを示しています：

sh invoked oom-killer: gfp_mask=0xd0, order=2, oomkilladj=0
[<c002d4c4>] (unwind_backtrace+0x0/0xd4) from [<c0073ac0>]              (oom_kill_process+0x54/0x1b8)
[<c0073ac0>] (oom_kill_process+0x54/0x1b8) from [<c0073f14>] (__out_of_memory+0x154/0x178)
[<c0073f14>] (__out_of_memory+0x154/0x178) from [<c0073fa0>] (out_of_memory+0x68/0x9c)
[<c0073fa0>] (out_of_memory+0x68/0x9c) from [<c007649c>] (__alloc_pages_nodemask+0x3e0/0x4c8)
[<c007649c>] (__alloc_pages_nodemask+0x3e0/0x4c8) from [<c0076598>] (__get_free_pages+0x14/0x4c)
[<c0076598>] (__get_free_pages+0x14/0x4c) from [<c002f528>] (get_pgd_slow+0x14/0xdc)
[<c002f528>] (get_pgd_slow+0x14/0xdc) from [<c0043890>] (mm_init+0x84/0xc4)
[<c0043890>] (mm_init+0x84/0xc4) from [<c0097b94>] (bprm_mm_init+0x10/0x138)
[<c0097b94>] (bprm_mm_init+0x10/0x138) from [<c00980a8>] (do_execve+0xf4/0x2a8)
[<c00980a8>] (do_execve+0xf4/0x2a8) from [<c002afc4>] (sys_execve+0x38/0x5c)
[<c002afc4>] (sys_execve+0x38/0x5c) from [<c0027d20>] (ret_fast_syscall+0x0/0x2c)
Mem-info:
DMA per-cpu:
CPU    0: hi:    0, btch:   1 usd:   0
Normal per-cpu:
CPU    0: hi:   42, btch:   7 usd:   0
Active_anon:424 active_file:11 inactive_anon:428
 inactive_file:3 unevictable:0 dirty:0 writeback:0 unstable:0
 free:608 slab:29498 mapped:14 pagetables:59 bounce:0
DMA free:692kB min:268kB low:332kB high:400kB active_anon:0kB inactive_anon:0kB active_file:4kB inactive_file:0kB unevictable:0kB present:24384kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 103 103
Normal free:1740kB min:1168kB low:1460kB high:1752kB active_anon:1696kB inactive_anon:1712kB active_file:40kB inactive_file:12kB unevictable:0kB present:105664kB pages_scanned:0 all_unreclaimable? no
lowmem_reserve[]: 0 0 0
DMA: 3*4kB 3*8kB 5*16kB 2*32kB 4*64kB 2*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 692kB
Normal: 377*4kB 1*8kB 4*16kB 1*32kB 2*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 1740kB
30 total pagecache pages
0 pages in swap cache
Swap cache stats: add 0, delete 0, find 0/0
Free swap  = 0kB
Total swap = 0kB
32768 pages of RAM
687 free pages
1306 reserved pages
29498 slab pages
59 pages shared
0 pages swap cached
Out of memory: kill process 774 (sh) score 339 or a child
Killed process 776 (xyz)

したがって、メモリリークがあることは明らかです。私のアプリが強制終了されたので、それは私のアプリである必要があります。しかし、私はプログラムからmallocを実行していません。変数のスコープを制限して、使用後に割り当てが解除されるように注意しました。だから私は、なぜスラブがトップ出力で増加しているのかについて完全に途方に暮れています。http://valgrind.org/docs/manual/faq.html#faq.reportsを試しましたが、機能しませんでした。

現在、デスクトップでValgrindを使用しようとしています（読んだので、arm-cortexでのみ機能します）。ビジネスロジックを確認します。

追加情報：

root@freescale ~/Application/app$ uname -a
Linux freescale 2.6.31-207-g7286c01 #2053 Fri Jun 22 10:29:11 IST 2012 armv5tejl GNU/Linux
Compiler : arm-none-linux-gnueabi-4.1.2 glibc2.5
cpp libs : libstdc++.so.6.0.8
Qt : 4.7.3 libs

任意のポインタをいただければ幸いです...

4

2 に答える 2

3

問題があなたのコードに直接あるとは思いません。理由は明らかです。アプリケーション スペースが増加しません (RSS と VSW の両方が増加しません)。

ただし、スラブの数は増えています。アプリケーションからスラブの数を使用したり増やしたりすることはできません。これはカーネルのみのものです。

頭のてっぺんからスラブのサイズが大きくなる明らかな原因は次のとおりです。

  • ネットワークソケットを実際に閉じることはありません
  • あなたは多くのファイルを読みますが、決してそれらを閉じません
  • 多くの ioctl を使用する

strace を実行して、しばらくその出力を確認します。strace は、カーネルとの対話をインターセプトします。メモリに問題がある場合は、brk() を繰り返し呼び出す必要があります。他の問題がある場合は、閉じることなく開くための呼び出しが繰り返し表示されます。

于 2012-10-29T09:34:13.760 に答える
1

データ構造の割り当てがある場合は、子の追加などの正確性を確認してください。コードに同様のバグがありました。また、データベースに対して大規模なクエリを実行すると、より多くの RAM メモリが使用される場合があります。メモリリーク検出器を見つけて、リークがあるかどうかを確認してください。

于 2012-10-27T10:04:59.090 に答える