Làm thế nào để phát hiện rò rỉ bộ nhớ?

Tôi dường như bị rò rỉ bộ nhớ lớn hơn trên Hệ thống Ubuntu hiện tại của mình

Sau khi báo cáo các lỗi bộ nhớ Eclipse lạ ( https://askubfox.com/questions/148998/eclipse-constant-different-out-of-memory-errors ) Tôi bắt đầu nhận được thông báo lỗi 'Không đủ bộ nhớ' trong bảng điều khiển của mình ngày hôm nay - trong khi thực hiện các tác vụ đơn giản như gõ vào sudo -s- hoặc thậm chí -free -m

Nhập vào 'free -m' một cách rõ ràng cho tôi thấy RAM của tôi nhanh chóng tăng từ 700M lên 900M, tăng lên đến kích thước 2000M trong vài giây (sau khi giải phóng bộ nhớ với echo 3 > /proc/sys/vm/drop_caches )

Eclipse không phải là nguyên nhân, tôi đã hoàn toàn giết quá trình và ram vẫn đang tăng lên. Có cách nào để phát hiện nơi rò rỉ đến từ đâu không? Tôi thậm chí không thể cập nhật hệ thống của mình nữa, kể từ khiapt-get update thất bại (có lẽ vì nó hết bộ nhớ)

Sử dụng Ubuntu 11.10

memprof là một công cụ để định hình việc sử dụng bộ nhớ và tìm rò rỉ bộ nhớ. Nó có thể tạo ra một cấu hình bao nhiêu bộ nhớ được phân bổ cho mỗi chức năng trong chương trình của bạn. Ngoài ra, nó có thể quét bộ nhớ và tìm các khối mà bạn đã phân bổ nhưng không còn được tham chiếu ở bất cứ đâu.

memprof hoạt động bằng cách tải trước một thư viện để ghi đè các chức năng cấp phát bộ nhớ của thư viện C và không yêu cầu bạn biên dịch lại chương trình của mình.

bản ghi nhớ

Nguồn: Hướng dẫn sử dụng Ubuntu

Trước tiên, hãy đảm bảo có sẵn một thư mục tạm thời có đủ dung lượng trống. Các lệnh sau tạo các bãi chứa có thể có kích thước vài GB.

Bạn có thể tạo một thư mục tmp mới bằng lệnh sau. Bạn có thể muốn thay đổi /tmpthành một hệ thống tập tin khác với đủ dung lượng

TMPDIR=$(mktemp -d -t -p /tmp)

Các bước để tìm rò rỉ bộ nhớ

1. Tìm hiểu PID của quá trình gây rò rỉ bộ nhớ (bạn cũng có thể sử dụng, ví dụ htopnếu có) và lưu trữ nó trong một biến được gọi làpid

   ps -aux
   

2. Cho rằng PID có sẵn trong biến pid, bạn có thể nắm bắt mức tiêu thụ bộ nhớ bằng cách sử dụng /proc/$pid/smapsvà lưu vào một số tệp như thế nào beforeMemInc.txt.

   cat /proc/$pid/smaps > $TMPDIR/beforeMemInc.txt
   

3. Đợi một thời gian để tiêu thụ bộ nhớ tăng lên.

4. Chụp /proc/$pid/smapslại và lưu nó dưới dạngafterMemInc.txt

   cat /proc/$pid/smaps > $TMPDIR/afterMemInc.txt
   

5. Tìm sự khác biệt giữa thứ nhất smapsvà thứ 2 smaps, ví dụ với

   diff -u $TMPDIR/beforeMemInc.txt $TMPDIR/afterMemInc.txt
   

6. Lưu ý phạm vi địa chỉ nơi bộ nhớ đã tăng, ví dụ:

      beforeMemInc.txt            afterMemInc.txt
   ---------------------------------------------------
   2b3289290000-2b3289343000   2b3289290000-2b3289343000  #ADDRESS
   Shared_Clean:    0 kB       Shared_Clean:    0 kB          
   Shared_Dirty:    0 kB       Shared_Dirty:    0 kB
   Private_Clean:   0 kB       Private_Clean:   0 kB
   Private_Dirty:  28 kB       Private_Dirty:  36 kB  
   Referenced:     28 kB       Referenced:     36 kB
   Anonymous:      28 kB       Anonymous:      36 kB  #INCREASE MEM
   AnonHugePages:   0 kB       AnonHugePages:   0 kB
   Swap:            0 kB       Swap:            0 kB
   KernelPageSize:  4 kB       KernelPageSize:  4 kB
   MMUPageSize:     4 kB       MMUPageSize:     4 kB
   Locked:          0 kB       Locked:          0 kB
   VmFlags: rd wr mr mw me ac  VmFlags: rd wr mr mw me ac
   

7. Sử dụng GDB để kết xuất bộ nhớ trong quá trình chạy hoặc sử dụng coredump bằng cách sử dụng

   gcore -o $TMPDIR/process $PID
   

8. Tôi đã sử dụng gdb trong quá trình chạy để kết xuất bộ nhớ vào một số tệp.

   cd $TMPDIR
   gdb -p $pid
   dump memory memory.dump 0x2b3289290000 0x2b3289343000
   

9. Bây giờ, sử dụng stringslệnh hoặc hexdump -Cđể inmemory.dump

   strings memory.dump
   

   Từ đó bạn có được thông tin có thể đọc được giúp bạn định vị các chuỗi đó trong mã nguồn của mình.

10. Phân tích nguồn của bạn để tìm rò rỉ.

Thủ thuật drop_cache sẽ không giải phóng bộ nhớ, nó sẽ thiết lập lại bộ đệm. Sử dụng ps lệnh nếu bạn muốn xác định quá trình nào sử dụng nhiều bộ nhớ hơn.

Ví dụ để theo dõi danh sách 15 người dùng bộ nhớ thường trú hàng đầu.

$ watch "ps --sort -rss -eo pid,pmem,rss,vsz,comm | head -16"
  PID %MEM   RSS    VSZ COMMAND
 2590 13.4 136892 825000 firefox
 1743 10.7 109020 300780 Xorg
 2067  8.5 86764 1118140 unity-2d-shell
 3307  4.1 42560 627780 unity-2d-spread
 2068  2.9 29904 617644 unity-2d-panel
 2092  2.5 25524 1291204 nautilus
 2457  1.9 20292 530276 gnome-terminal
 2351  1.9 20016 821488 unity-scope-vid
 2161  1.9 19476 531968 unity-panel-ser
 2034  1.7 18256 759716 gnome-settings-
 2074  1.5 16176 518016 nm-applet
 2273  1.5 15452 580416 unity-lens-vide
 2051  1.4 15112 524260 metacity
 2395  1.2 12836 407336 update-notifi

Bạn cũng có thể kiểm tra phần đặt trước bộ nhớ được chia sẻ nhưng bạn sẽ chỉ biết ai là chủ sở hữu của các phân đoạn.

Phân bổ Pmap:

$ ls -l /run/shm
total 272
-r-------- 1 ed      ed      67108904 Nov 29 18:17 pulse-shm-1884617860
-r-------- 1 lightdm lightdm 67108904 Nov 29 18:11 pulse-shm-2352897759
-r-------- 1 ed      ed      67108904 Nov 29 18:12 pulse-shm-3444873503
-r-------- 1 ed      ed      67108904 Nov 29 18:12 pulse-shm-3485341848
-r-------- 1 lightdm lightdm 67108904 Nov 29 18:11 pulse-shm-535843976
-r-------- 1 ed      ed      67108904 Nov 29 19:12 pulse-shm-789046959
-r-------- 1 ed      ed      67108904 Nov 29 18:38 pulse-shm-863909656

$ df /run/shm 
Filesystem     1K-blocks  Used Available Use% Mounted on
none              509332   272    509060   1% /run/shm

lưu ý rằng phân bổ dành riêng cao hơn nhiều so với thực tế các trang được phân bổ (df 'used')

Phân bổ hệ thống V:

$ ipcs -m 

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status      
0x00000000 294912     ed         700        122880     2          dest         
0x00000000 327681     ed         700        4823040    2          dest         
0x00000000 491522     ed         600        393216     2          dest         
0x00000000 589827     ed         700        4578120    2          dest         
0x00000000 425988     ed         700        27852      2          dest         
0x00000000 458757     ed         600        393216     2          dest         

Chỉnh sửa : Cần phải vượt qua --sort -rssđể pscó được các quy trình có mức sử dụng bộ nhớ nhiều nhất, nếu không, danh sách quy trình được sắp xếp tăng dần theo số và cung cấp cho các quy trình có mức sử dụng bộ nhớ ít nhất.

Tôi có một máy cũ hơn mà tôi sử dụng liên tục phát ra các thông báo rò rỉ bộ nhớ:

root@:~# free -m
             total       used       free     shared    buffers     cached
Mem:          1898       1523        374        131         32        588
-/+ buffers/cache:        902        995
Swap:         1942        480       1462

Kịch bản của tôi:

sync; sudo echo 3 > /proc/sys/vm/drop_caches

Đặt tên cho nó cache.sh

root@~# ./cache.sh
root@~# free -m
             total       used       free     shared    buffers     cached
Mem:          1898       1106        791        126          1        207
-/+ buffers/cache:        897       1000
Swap:         1942        480       1462

Bạn có thể thấy tôi đã giảm xuống còn 374 MB, đã chạy sync; sudo echo 3 > /proc/sys/vm/drop_cachesvà kiếm được 417 MB trở lại. Một người có thể cronchạy mỗi 5 phút hoặc chỉ cần mở một thiết bị đầu cuối và chạy nó khi bạn thấy hiệu suất chậm. Có, tôi cần thêm bộ nhớ vào máy ...

memstat cũng là một công cụ tốt sẽ hiển thị lượng bộ nhớ được sử dụng bởi mỗi khối cũng như dung lượng bộ nhớ được sử dụng bởi các thư viện được tải. Không phải là công cụ tốt nhất nhưng đáng để sử dụng để thu thập chi tiết và số liệu thống kê.

memstat -w -p pid là một lệnh tốt để sử dụng.

Tôi đã có một vấn đề tương tự nhưng với một giải pháp rất kỳ lạ.

Vì một số lý do không rõ, tôi đã cài đặt máy chủ mail trên máy tính xách tay của mình và chạy. Tôi không biết tại sao tôi lại có nó ... Tuy nhiên, tôi đã tắt dịch vụ của nó và hóa ra phần mềm trên máy tính xách tay của tôi đã bị tấn công ddos. Sau đó mọi thứ vẫn bình thường.