Tóm tắt tháng 8 năm 2015

Xin lưu ý, điều này vẫn đang xảy ra. Điều này không liên quan đến linuxHRyram.com - bộ nhớ không được sử dụng cho bộ đệm / bộ đệm đĩa. Đây là những gì nó trông giống như trong NewRelic - hệ thống rò rỉ tất cả bộ nhớ, sử dụng hết dung lượng trao đổi và sau đó gặp sự cố. Trong ảnh chụp màn hình này, tôi đã khởi động lại máy chủ trước khi nó bị sập:

Không thể xác định nguồn rò rỉ bằng các công cụ không gian người dùng phổ biến. Hiện tại có một phòng trò chuyện để thảo luận về vấn đề này: http://chat.stackexchange.com/rooms/27309/invisible-memory-leak-on-linux

Cách duy nhất để khôi phục bộ nhớ "mất tích" dường như là khởi động lại máy chủ. Đây là một vấn đề tồn tại lâu dài được sao chép trong Ubuntu Server 14.04, 14.10 và 15.04.

Hàng đầu

Việc sử dụng bộ nhớ không hiển thị trên cùng và không thể được phục hồi ngay cả sau khi giết mọi tiến trình (không bao gồm những thứ như tiến trình kernel và ssh). Nhìn vào các trường "Bộ nhớ đệm", "bộ đệm" và "miễn phí" ở trên cùng, chúng không sử dụng hết bộ nhớ, bộ nhớ được sử dụng bị "thiếu" và không thể phục hồi nếu không khởi động lại.

Việc cố gắng sử dụng bộ nhớ "mất tích" này khiến máy chủ hoán đổi, chậm thu thập dữ liệu và cuối cùng bị đóng băng.

root@XanBox:~# top -o +%MEM
top - 12:12:13 up 15 days, 20:39,  3 users,  load average: 0.00, 0.06, 0.77
Tasks: 126 total,   1 running, 125 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.1 us,  0.2 sy,  0.0 ni, 99.7 id,  0.0 wa,  0.1 hi,  0.0 si,  0.0 st
KiB Mem:   2,040,256 total,  1,881,228 used,    159,028 free,     1,348 buffers
KiB Swap:  1,999,868 total,     27,436 used,  1,972,432 free.    67,228 cached Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
11502 root      20   0  107692   4252   3240 S   0.0  0.2   0:00.06 sshd: deployer [priv]
11336 root      20   0  107692   4248   3240 S   0.0  0.2   0:00.06 sshd: deployer [priv]
11841 root      20   0  107692   4248   3240 S   0.0  0.2   0:00.06 sshd: deployer [priv]
11301 root      20   0   26772   3436   2688 S   0.7  0.2   0:01.30 /usr/sbin/openvpn --writepid /var/run/openvpn.zanview.com.pid --status /var/run/openvpn.zanview.com.status 10 --cd /etc/openvpn --config /etc/openvpn/z+
11385 deployer  20   0   19972   2392   1708 S   0.0  0.1   0:00.03 -bash
11553 deployer  20   0   19972   2388   1708 S   0.0  0.1   0:00.03 -bash
11890 deployer  20   0   19972   2388   1708 S   0.0  0.1   0:00.02 -bash
11889 deployer  20   0  108008   2280    944 S   0.0  0.1   0:00.25 sshd: deployer@pts/3
12009 root      20   0   18308   2228   1608 S   0.0  0.1   0:00.09 -su
12114 root      20   0   18308   2192   1564 S   0.0  0.1   0:00.04 -su
12007 root      20   0   67796   2136   1644 S   0.0  0.1   0:00.01 sudo su -
12112 root      20   0   67796   2136   1644 S   0.0  0.1   0:00.01 sudo su -
12008 root      20   0   67376   2016   1528 S   0.0  0.1   0:00.01 su -
12113 root      20   0   67376   2012   1528 S   0.0  0.1   0:00.01 su -
    1 root      20   0   33644   1988    764 S   0.0  0.1   2:29.77 /sbin/init
11552 deployer  20   0  107692   1952    936 S   0.0  0.1   0:00.07 sshd: deployer@pts/2
11384 deployer  20   0  107692   1948    936 S   0.0  0.1   0:00.06 sshd: deployer@pts/0
12182 root      20   0   20012   1516   1012 R   0.7  0.1   0:00.08 top -o +%MEM
 1152 message+  20   0   39508   1448    920 S   0.0  0.1   1:40.01 dbus-daemon --system --fork
 1791 root      20   0  279832   1312    816 S   0.0  0.1   1:16.18 /usr/lib/policykit-1/polkitd --no-debug
 1186 root      20   0   43736    984    796 S   0.0  0.0   1:13.07 /lib/systemd/systemd-logind
 1212 syslog    20   0  256228    688    184 S   0.0  0.0   1:41.29 rsyslogd
 5077 root      20   0   25324    648    520 S   0.0  0.0   0:34.35 /usr/sbin/hostapd -B -P /var/run/hostapd.pid /etc/hostapd/hostapd.conf
  336 root      20   0   19476    512    376 S   0.0  0.0   0:07.40 upstart-udev-bridge --daemon
  342 root      20   0   51228    468    344 S   0.0  0.0   0:00.85 /lib/systemd/systemd-udevd --daemon
 1097 root      20   0   15276    364    256 S   0.0  0.0   0:06.39 upstart-file-bridge --daemon
 4921 root      20   0   61364    364    240 S   0.0  0.0   0:00.05 /usr/sbin/sshd -D
  745 root      20   0   15364    252    180 S   0.0  0.0   0:06.51 upstart-socket-bridge --daemon
 4947 root      20   0   23656    168    100 S   0.0  0.0   0:14.70 cron
11290 daemon    20   0   19140    164      0 S   0.0  0.0   0:00.00 atd
  850 root      20   0   23420     80     16 S   0.0  0.0   0:11.00 rpcbind
  872 statd     20   0   21544      8      4 S   0.0  0.0   0:00.00 rpc.statd -L
 4880 root      20   0   14540      4      0 S   0.0  0.0   0:00.00 /sbin/getty -8 38400 tty4
 4883 root      20   0   14540      4      0 S   0.0  0.0   0:00.00 /sbin/getty -8 38400 tty5
 4890 root      20   0   14540      4      0 S   0.0  0.0   0:00.00 /sbin/getty -8 38400 tty2
 4891 root      20   0   14540      4      0 S   0.0  0.0   0:00.00 /sbin/getty -8 38400 tty3
 4894 root      20   0   14540      4      0 S   0.0  0.0   0:00.00 /sbin/getty -8 38400 tty6
 4919 root      20   0    4368      4      0 S   0.0  0.0   0:00.00 acpid -c /etc/acpi/events -s /var/run/acpid.socket
 5224 root      20   0   24048      4      0 S   0.0  0.0   0:00.00 /usr/sbin/rpc.mountd --manage-gids
 6160 root      20   0   14540      4      0 S   0.0  0.0   0:00.00 /sbin/getty -8 38400 tty1
    2 root      20   0       0      0      0 S   0.0  0.0   0:03.44 [kthreadd]
    3 root      20   0       0      0      0 S   0.0  0.0   1:04.63 [ksoftirqd/0]
    5 root       0 -20       0      0      0 S   0.0  0.0   0:00.00 [kworker/0:0H]
    7 root      20   0       0      0      0 S   0.0  0.0  16:03.32 [rcu_sched]
    8 root      20   0       0      0      0 S   0.0  0.0   4:08.79 [rcuos/0]
    9 root      20   0       0      0      0 S   0.0  0.0   4:10.42 [rcuos/1]
   10 root      20   0       0      0      0 S   0.0  0.0   4:30.71 [rcuos/2]

Phần cứng

Tôi đã quan sát điều này trên 3 máy chủ trong số khoảng 100 máy chủ cho đến nay (mặc dù những máy chủ khác có thể bị ảnh hưởng). Một là Intel Atom D525 @ 1.8ghz và 2 cái còn lại là Core2Duo E4600 và Q6600. Một người đang sử dụng Bộ điều khiển Ethernet Gigabit Ethernet JMC250 của Tập đoàn Công nghệ JMicron, những người khác đang sử dụng Qualcomm Atheros Attansic L1 Gigabit Ethernet (rev b0).

Tôi đã chạy lshw trên các máy chủ rắc rối cũng như trên một máy chủ ví dụ OK. Máy chủ sự cố: http://pastie.org/10370534 http://pastie.org/10370537 và http://pastie.org/10370541 - Máy chủ OK: http://pastie.org/10370544

Ứng dụng

Đây là một ứng dụng hoàn toàn không đầu. Không có màn hình nào được kết nối và thực tế không có XServer nào được cài đặt cả. Điều này sẽ loại trừ các trình điều khiển / vấn đề đồ họa.

Máy chủ được sử dụng để ủy quyền và phân tích video RTSP bằng live555ProxyServer, ffmpeg và openCV. Các máy chủ này hoạt động rất nhanh qua lưu lượng truy cập vì đây là ứng dụng camera quan sát: http://pastie.org/9558324

Tôi đã thử cả hai phiên bản trung kế rất cũ và mới nhất của live555, ffmpeg và openCV mà không thay đổi. Tôi cũng đã thử sử dụng opencv thông qua các mô-đun python2 và python3, không thay đổi.

Chính xác cùng một phần mềm / cấu hình đã được tải lên gần 100 máy chủ, cho đến nay 3 đã được xác nhận là rò rỉ bộ nhớ. Các máy chủ rò rỉ chậm và lén lút xung quanh xMB (một rò rỉ 8 MB, một chậm hơn, một nhanh hơn) mỗi giờ cho đến khi hết ram, các máy chủ bắt đầu hoán đổi mạnh, chậm thu thập dữ liệu và yêu cầu khởi động lại.

Meminfo

Một lần nữa, bạn có thể thấy Bộ đệm và Bộ đệm không sử dụng hết bộ nhớ. HugePages cũng bị vô hiệu hóa nên đây không phải là thủ phạm.

root@XanBox:~# cat /proc/meminfo
MemTotal:          2,040,256 kB
MemFree:             159,004 kB
Buffers:               1,348 kB
Cached:               67,228 kB
SwapCached:            9,940 kB
Active:               10,788 kB
Inactive:             81,120 kB
Active(anon):          1,900 kB
Inactive(anon):       21,512 kB
Active(file):          8,888 kB
Inactive(file):       59,608 kB
Unevictable:               0 kB
Mlocked:                   0 kB
SwapTotal:         1,999,868 kB
SwapFree:          1,972,432 kB
Dirty:                     0 kB
Writeback:                 0 kB
AnonPages:            14,496 kB
Mapped:                8,160 kB
Shmem:                    80 kB
Slab:                 33,472 kB
SReclaimable:         17,660 kB
SUnreclaim:           15,812 kB
KernelStack:           1,064 kB
PageTables:            3,992 kB
NFS_Unstable:              0 kB
Bounce:                    0 kB
WritebackTmp:              0 kB
CommitLimit:       3,019,996 kB
Committed_AS:         94,520 kB
VmallocTotal: 34,359,738,367 kB
VmallocUsed:         535,936 kB
VmallocChunk: 34,359,147,772 kB
HardwareCorrupted:         0 kB
AnonHugePages:             0 kB
HugePages_Total:           0
HugePages_Free:            0
HugePages_Rsvd:            0
HugePages_Surp:            0
Hugepagesize:          2,048 kB
DirectMap4k:          62,144 kB
DirectMap2M:       2,025,472 kB

Đầu ra miễn phí

Miễn phí hiển thị các mục sau (lưu ý bộ đệm và bộ đệm đều ở mức thấp nên đây không phải là bộ đệm hoặc bộ đệm đĩa!) - bộ nhớ không thể phục hồi được nếu không khởi động lại:

root@XanBox:~# free -m
             total       used       free     shared    buffers     cached
Mem:         1,992      1,838        153          0          1         66

Nếu chúng tôi trừ / thêm bộ đệm / bộ đệm vào Được sử dụng và Miễn phí, chúng tôi sẽ thấy:

• 1.772MB Được sử dụng thực sự (- Bộ đệm / Bộ nhớ cache) = 1.838 MB được sử dụng - Bộ đệm 1MB - Bộ nhớ cache 66MB
• 220MB Thực sự miễn phí (+ Bộ đệm / Bộ đệm) = 154 MB miễn phí + Bộ đệm 1MB + Bộ đệm 66MB

Chính xác như chúng ta mong đợi:

-/+ buffers/cache:      1,772        220

Vì vậy, khoảng 1.7GB không được sử dụng bởi không gian người dùng và trên thực tế được sử dụng bởi kernel vì hệ thống thực sự đang sử dụng 53,7 MB (xem đầu ra PS Mem bên dưới).

Tôi ngạc nhiên với số lượng bình luận cho rằng 1.7GB được sử dụng cho bộ đệm / bộ đệm - điều này về cơ bản là đọc sai sản lượng! - dòng này có nghĩa là bộ nhớ được sử dụng không bao gồm bộ đệm / bộ đệm , xem linuxHRyram.com để biết chi tiết.

Đầu ra PS

Dưới đây là danh sách đầy đủ các quy trình đang chạy được sắp xếp theo bộ nhớ:

# ps -e -o pid,vsz,comm= | sort -n -k 2
    2      0 kthreadd
    3      0 ksoftirqd/0
    5      0 kworker/0:0H
    7      0 rcu_sched
    8      0 rcuos/0
    9      0 rcuos/1
   10      0 rcuos/2
   11      0 rcuos/3
   12      0 rcu_bh
   13      0 rcuob/0
   14      0 rcuob/1
   15      0 rcuob/2
   16      0 rcuob/3
   17      0 migration/0
   18      0 watchdog/0
   19      0 watchdog/1
   20      0 migration/1
   21      0 ksoftirqd/1
   23      0 kworker/1:0H
   24      0 watchdog/2
   25      0 migration/2
   26      0 ksoftirqd/2
   28      0 kworker/2:0H
   29      0 watchdog/3
   30      0 migration/3
   31      0 ksoftirqd/3
   32      0 kworker/3:0
   33      0 kworker/3:0H
   34      0 khelper
   35      0 kdevtmpfs
   36      0 netns
   37      0 writeback
   38      0 kintegrityd
   39      0 bioset
   41      0 kblockd
   42      0 ata_sff
   43      0 khubd
   44      0 md
   45      0 devfreq_wq
   46      0 kworker/0:1
   47      0 kworker/1:1
   48      0 kworker/2:1
   50      0 khungtaskd
   51      0 kswapd0
   52      0 ksmd
   53      0 khugepaged
   54      0 fsnotify_mark
   55      0 ecryptfs-kthrea
   56      0 crypto
   68      0 kthrotld
   70      0 scsi_eh_0
   71      0 scsi_eh_1
   92      0 deferwq
   93      0 charger_manager
   94      0 kworker/1:2
   95      0 kworker/3:2
  149      0 kpsmoused
  155      0 jbd2/sda1-8
  156      0 ext4-rsv-conver
  316      0 jbd2/sda3-8
  317      0 ext4-rsv-conver
  565      0 kmemstick
  770      0 cfg80211
  818      0 hd-audio0
  853      0 kworker/2:2
  953      0 rpciod
  PID    VSZ
 1714      0 kauditd
11335      0 kworker/0:2
12202      0 kworker/u8:2
20228      0 kworker/u8:0
25529      0 kworker/u9:1
28305      0 kworker/u9:2
29822      0 lockd
 4919   4368 acpid
 4074   7136 ps
 6681  10232 dhclient
 4880  14540 getty
 4883  14540 getty
 4890  14540 getty
 4891  14540 getty
 4894  14540 getty
 6160  14540 getty
14486  15260 upstart-socket-
14489  15276 upstart-file-br
12009  18308 bash
12114  18308 bash
12289  18308 bash
 4075  19008 sort
11290  19140 atd
14483  19476 upstart-udev-br
11385  19972 bash
11553  19972 bash
11890  19972 bash
29503  21544 rpc.statd
 2847  23384 htop
  850  23420 rpcbind
29588  23480 rpc.idmapd
 4947  23656 cron
29833  24048 rpc.mountd
 5077  25324 hostapd
11301  26912 openvpn
    1  37356 init
 1152  39508 dbus-daemon
14673  43452 systemd-logind
14450  51204 systemd-udevd
 4921  61364 sshd
12008  67376 su
12113  67376 su
12288  67376 su
12007  67796 sudo
12112  67796 sudo
12287  67796 sudo
11336 107692 sshd
11384 107692 sshd
11502 107692 sshd
11841 107692 sshd
11552 108008 sshd
11889 108008 sshd
 1212 256228 rsyslogd
 1791 279832 polkitd
 4064 335684 whoopsie

Dưới đây là danh sách đầy đủ của tất cả các quy trình đang chạy:

root@XanBox:~# ps aux
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.0  33644  1988 ?        Ss   Jul21   2:29 /sbin/init
root         2  0.0  0.0      0     0 ?        S    Jul21   0:03 [kthreadd]
root         3  0.0  0.0      0     0 ?        S    Jul21   1:04 [ksoftirqd/0]
root         5  0.0  0.0      0     0 ?        S<   Jul21   0:00 [kworker/0:0H]
root         7  0.0  0.0      0     0 ?        S    Jul21  16:03 [rcu_sched]
root         8  0.0  0.0      0     0 ?        S    Jul21   4:08 [rcuos/0]
root         9  0.0  0.0      0     0 ?        S    Jul21   4:10 [rcuos/1]
root        10  0.0  0.0      0     0 ?        S    Jul21   4:30 [rcuos/2]
root        11  0.0  0.0      0     0 ?        S    Jul21   4:28 [rcuos/3]
root        12  0.0  0.0      0     0 ?        S    Jul21   0:00 [rcu_bh]
root        13  0.0  0.0      0     0 ?        S    Jul21   0:00 [rcuob/0]
root        14  0.0  0.0      0     0 ?        S    Jul21   0:00 [rcuob/1]
root        15  0.0  0.0      0     0 ?        S    Jul21   0:00 [rcuob/2]
root        16  0.0  0.0      0     0 ?        S    Jul21   0:00 [rcuob/3]
root        17  0.0  0.0      0     0 ?        S    Jul21   0:13 [migration/0]
root        18  0.0  0.0      0     0 ?        S    Jul21   0:08 [watchdog/0]
root        19  0.0  0.0      0     0 ?        S    Jul21   0:07 [watchdog/1]
root        20  0.0  0.0      0     0 ?        S    Jul21   0:13 [migration/1]
root        21  0.0  0.0      0     0 ?        S    Jul21   1:03 [ksoftirqd/1]
root        23  0.0  0.0      0     0 ?        S<   Jul21   0:00 [kworker/1:0H]
root        24  0.0  0.0      0     0 ?        S    Jul21   0:07 [watchdog/2]
root        25  0.0  0.0      0     0 ?        S    Jul21   0:23 [migration/2]
root        26  0.0  0.0      0     0 ?        S    Jul21   1:01 [ksoftirqd/2]
root        28  0.0  0.0      0     0 ?        S<   Jul21   0:00 [kworker/2:0H]
root        29  0.0  0.0      0     0 ?        S    Jul21   0:07 [watchdog/3]
root        30  0.0  0.0      0     0 ?        S    Jul21   0:23 [migration/3]
root        31  0.0  0.0      0     0 ?        S    Jul21   1:03 [ksoftirqd/3]
root        32  0.0  0.0      0     0 ?        S    Jul21   0:00 [kworker/3:0]
root        33  0.0  0.0      0     0 ?        S<   Jul21   0:00 [kworker/3:0H]
root        34  0.0  0.0      0     0 ?        S<   Jul21   0:00 [khelper]
root        35  0.0  0.0      0     0 ?        S    Jul21   0:00 [kdevtmpfs]
root        36  0.0  0.0      0     0 ?        S<   Jul21   0:00 [netns]
root        37  0.0  0.0      0     0 ?        S<   Jul21   0:00 [writeback]
root        38  0.0  0.0      0     0 ?        S<   Jul21   0:00 [kintegrityd]
root        39  0.0  0.0      0     0 ?        S<   Jul21   0:00 [bioset]
root        41  0.0  0.0      0     0 ?        S<   Jul21   0:00 [kblockd]
root        42  0.0  0.0      0     0 ?        S<   Jul21   0:00 [ata_sff]
root        43  0.0  0.0      0     0 ?        S    Jul21   0:00 [khubd]
root        44  0.0  0.0      0     0 ?        S<   Jul21   0:00 [md]
root        45  0.0  0.0      0     0 ?        S<   Jul21   0:00 [devfreq_wq]
root        46  0.0  0.0      0     0 ?        S    Jul21  18:51 [kworker/0:1]
root        47  0.0  0.0      0     0 ?        S    Jul21   0:00 [kworker/1:1]
root        48  0.0  0.0      0     0 ?        S    Jul21   1:14 [kworker/2:1]
root        50  0.0  0.0      0     0 ?        S    Jul21   0:01 [khungtaskd]
root        51  0.4  0.0      0     0 ?        S    Jul21  95:51 [kswapd0]
root        52  0.0  0.0      0     0 ?        SN   Jul21   0:00 [ksmd]
root        53  0.0  0.0      0     0 ?        SN   Jul21   0:28 [khugepaged]
root        54  0.0  0.0      0     0 ?        S    Jul21   0:00 [fsnotify_mark]
root        55  0.0  0.0      0     0 ?        S    Jul21   0:00 [ecryptfs-kthrea]
root        56  0.0  0.0      0     0 ?        S<   Jul21   0:00 [crypto]
root        68  0.0  0.0      0     0 ?        S<   Jul21   0:00 [kthrotld]
root        70  0.0  0.0      0     0 ?        S    Jul21   0:00 [scsi_eh_0]
root        71  0.0  0.0      0     0 ?        S    Jul21   0:00 [scsi_eh_1]
root        92  0.0  0.0      0     0 ?        S<   Jul21   0:00 [deferwq]
root        93  0.0  0.0      0     0 ?        S<   Jul21   0:00 [charger_manager]
root        94  0.0  0.0      0     0 ?        S    Jul21   1:05 [kworker/1:2]
root        95  0.0  0.0      0     0 ?        S    Jul21   1:08 [kworker/3:2]
root       149  0.0  0.0      0     0 ?        S<   Jul21   0:00 [kpsmoused]
root       155  0.0  0.0      0     0 ?        S    Jul21   3:39 [jbd2/sda1-8]
root       156  0.0  0.0      0     0 ?        S<   Jul21   0:00 [ext4-rsv-conver]
root       316  0.0  0.0      0     0 ?        S    Jul21   1:28 [jbd2/sda3-8]
root       317  0.0  0.0      0     0 ?        S<   Jul21   0:00 [ext4-rsv-conver]
root       336  0.0  0.0  19476   512 ?        S    Jul21   0:07 upstart-udev-bridge --daemon
root       342  0.0  0.0  51228   468 ?        Ss   Jul21   0:00 /lib/systemd/systemd-udevd --daemon
root       565  0.0  0.0      0     0 ?        S<   Jul21   0:00 [kmemstick]
root       745  0.0  0.0  15364   252 ?        S    Jul21   0:06 upstart-socket-bridge --daemon
root       770  0.0  0.0      0     0 ?        S<   Jul21   0:00 [cfg80211]
root       818  0.0  0.0      0     0 ?        S<   Jul21   0:00 [hd-audio0]
root       850  0.0  0.0  23420    80 ?        Ss   Jul21   0:11 rpcbind
root       853  0.0  0.0      0     0 ?        S    Jul21   0:00 [kworker/2:2]
statd      872  0.0  0.0  21544     8 ?        Ss   Jul21   0:00 rpc.statd -L
root       953  0.0  0.0      0     0 ?        S<   Jul21   0:00 [rpciod]
root      1097  0.0  0.0  15276   364 ?        S    Jul21   0:06 upstart-file-bridge --daemon
message+  1152  0.0  0.0  39508  1448 ?        Ss   Jul21   1:40 dbus-daemon --system --fork
root      1157  0.0  0.0  23480     0 ?        Ss   Jul21   0:00 rpc.idmapd
root      1186  0.0  0.0  43736   984 ?        Ss   Jul21   1:13 /lib/systemd/systemd-logind
syslog    1212  0.0  0.0 256228   688 ?        Ssl  Jul21   1:41 rsyslogd
root      1714  0.0  0.0      0     0 ?        S    Jul21   0:00 [kauditd]
root      1791  0.0  0.0 279832  1312 ?        Sl   Jul21   1:16 /usr/lib/policykit-1/polkitd --no-debug
root      4880  0.0  0.0  14540     4 tty4     Ss+  Jul21   0:00 /sbin/getty -8 38400 tty4
root      4883  0.0  0.0  14540     4 tty5     Ss+  Jul21   0:00 /sbin/getty -8 38400 tty5
root      4890  0.0  0.0  14540     4 tty2     Ss+  Jul21   0:00 /sbin/getty -8 38400 tty2
root      4891  0.0  0.0  14540     4 tty3     Ss+  Jul21   0:00 /sbin/getty -8 38400 tty3
root      4894  0.0  0.0  14540     4 tty6     Ss+  Jul21   0:00 /sbin/getty -8 38400 tty6
root      4919  0.0  0.0   4368     4 ?        Ss   Jul21   0:00 acpid -c /etc/acpi/events -s /var/run/acpid.socket
root      4921  0.0  0.0  61364   364 ?        Ss   Jul21   0:00 /usr/sbin/sshd -D
root      4947  0.0  0.0  23656   168 ?        Ss   Jul21   0:14 cron
root      5077  0.0  0.0  25324   648 ?        Ss   Jul21   0:34 /usr/sbin/hostapd -B -P /var/run/hostapd.pid /etc/hostapd/hostapd.conf
root      5192  0.0  0.0      0     0 ?        S    Jul21   0:00 [lockd]
root      5224  0.0  0.0  24048     4 ?        Ss   Jul21   0:00 /usr/sbin/rpc.mountd --manage-gids
root      6160  0.0  0.0  14540     4 tty1     Ss+  Jul21   0:00 /sbin/getty -8 38400 tty1
root      6681  0.0  0.0  10232     0 ?        Ss   11:07   0:00 dhclient -1 -v -pf /run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases eth0
root      9452  0.0  0.0      0     0 ?        S    11:28   0:00 [kworker/u8:1]
root      9943  0.0  0.0      0     0 ?        S    11:42   0:00 [kworker/u8:0]
daemon   11290  0.0  0.0  19140   164 ?        Ss   11:59   0:00 atd
root     11301  0.2  0.1  26772  3436 ?        Ss   12:00   0:01 /usr/sbin/openvpn --writepid /var/run/openvpn.zanview.com.pid --status /var/run/openvpn.zanview.com.status 10 --cd /etc/openvpn --config /etc/openvpn/zanvie
root     11335  0.0  0.0      0     0 ?        S    12:01   0:00 [kworker/0:2]
root     11336  0.0  0.2 107692  4248 ?        Ss   12:01   0:00 sshd: deployer [priv]
deployer 11384  0.0  0.0 107692  1948 ?        S    12:01   0:00 sshd: deployer@pts/0
deployer 11385  0.0  0.1  19972  2392 pts/0    Ss+  12:01   0:00 -bash
root     11502  0.0  0.2 107692  4252 ?        Ss   12:01   0:00 sshd: deployer [priv]
deployer 11552  0.0  0.0 107692  1952 ?        S    12:01   0:00 sshd: deployer@pts/2
deployer 11553  0.0  0.1  19972  2388 pts/2    Ss   12:01   0:00 -bash
root     11841  0.0  0.2 107692  4248 ?        Ss   12:02   0:00 sshd: deployer [priv]
deployer 11889  0.0  0.1 108008  2280 ?        S    12:02   0:00 sshd: deployer@pts/3
deployer 11890  0.0  0.1  19972  2388 pts/3    Ss   12:02   0:00 -bash
root     12007  0.0  0.1  67796  2136 pts/3    S    12:02   0:00 sudo su -
root     12008  0.0  0.0  67376  2016 pts/3    S    12:02   0:00 su -
root     12009  0.0  0.1  18308  2228 pts/3    S+   12:02   0:00 -su
root     12112  0.0  0.1  67796  2136 pts/2    S    12:08   0:00 sudo su -
root     12113  0.0  0.0  67376  2012 pts/2    S    12:08   0:00 su -
root     12114  0.0  0.1  18308  2192 pts/2    S    12:08   0:00 -su
root     12180  0.0  0.0  15568  1160 pts/2    R+   12:09   0:00 ps aux
root     25529  0.0  0.0      0     0 ?        S<   Jul28   0:09 [kworker/u9:1]
root     28305  0.0  0.0      0     0 ?        S<   Aug05   0:00 [kworker/u9:2]

Đầu ra PS Mem

Tôi cũng đã thử ps_mem.py từ https://github.com/pixelb/ps_mem

root@XanBox:~/ps_mem# python ps_mem.py
 Private  +   Shared  =  RAM used   Program

144.0 KiB +   9.5 KiB = 153.5 KiB   acpid
172.0 KiB +  29.5 KiB = 201.5 KiB   atd
248.0 KiB +  35.0 KiB = 283.0 KiB   cron
272.0 KiB +  84.0 KiB = 356.0 KiB   upstart-file-bridge
276.0 KiB +  84.5 KiB = 360.5 KiB   upstart-socket-bridge
280.0 KiB + 102.5 KiB = 382.5 KiB   upstart-udev-bridge
332.0 KiB +  54.5 KiB = 386.5 KiB   rpc.idmapd
368.0 KiB +  91.5 KiB = 459.5 KiB   rpcbind
388.0 KiB + 251.5 KiB = 639.5 KiB   systemd-logind
668.0 KiB +  43.5 KiB = 711.5 KiB   hostapd
576.0 KiB + 157.5 KiB = 733.5 KiB   systemd-udevd
676.0 KiB +  65.5 KiB = 741.5 KiB   rpc.mountd
604.0 KiB + 163.0 KiB = 767.0 KiB   rpc.statd
908.0 KiB +  62.5 KiB = 970.5 KiB   dbus-daemon [updated]
932.0 KiB + 117.0 KiB =   1.0 MiB   getty [updated] (6)
  1.0 MiB +  69.5 KiB =   1.1 MiB   openvpn
  1.0 MiB + 137.0 KiB =   1.2 MiB   polkitd
  1.5 MiB + 202.0 KiB =   1.7 MiB   htop
  1.4 MiB + 306.5 KiB =   1.7 MiB   whoopsie
  1.4 MiB + 279.0 KiB =   1.7 MiB   su (3)
  1.5 MiB + 268.5 KiB =   1.8 MiB   sudo (3)
  2.2 MiB +  11.5 KiB =   2.3 MiB   dhclient
  3.9 MiB + 741.0 KiB =   4.6 MiB   bash (6)
  5.3 MiB + 254.5 KiB =   5.5 MiB   init
  2.7 MiB +   3.3 MiB =   6.1 MiB   sshd (7)
 18.1 MiB +  56.5 KiB =  18.2 MiB   rsyslogd
---------------------------------
                         53.7 MiB
=================================

Đầu ra Slabtop

Tôi cũng đã thử slabtop:

root@XanBox:~# slabtop -sc
 Active / Total Objects (% used)    : 131306 / 137558 (95.5%)
 Active / Total Slabs (% used)      : 3888 / 3888 (100.0%)
 Active / Total Caches (% used)     : 63 / 105 (60.0%)
 Active / Total Size (% used)       : 27419.31K / 29580.53K (92.7%)
 Minimum / Average / Maximum Object : 0.01K / 0.21K / 8.00K

  OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME
  8288   7975  96%    0.57K    296       28      4736K inode_cache
 14259  12858  90%    0.19K    679       21      2716K dentry
  2384   1943  81%    0.96K    149       16      2384K ext4_inode_cache
 20916  20494  97%    0.11K    581       36      2324K sysfs_dir_cache
   624    554  88%    2.00K     39       16      1248K kmalloc-2048
   195    176  90%    5.98K     39        5      1248K task_struct
  6447   6387  99%    0.19K    307       21      1228K kmalloc-192
  2128   1207  56%    0.55K     76       28      1216K radix_tree_node
   768    761  99%    1.00K     48       16       768K kmalloc-1024
   176    155  88%    4.00K     22        8       704K kmalloc-4096
  1100   1100 100%    0.63K     44       25       704K proc_inode_cache
  1008   1008 100%    0.66K     42       24       672K shmem_inode_cache
  2640   2262  85%    0.25K    165       16       660K kmalloc-256
   300    300 100%    2.06K     20       15       640K sighand_cache
  5967   5967 100%    0.10K    153       39       612K buffer_head
  1152   1053  91%    0.50K     72       16       576K kmalloc-512
  3810   3810 100%    0.13K    127       30       508K ext4_allocation_context
    60     60 100%    8.00K     15        4       480K kmalloc-8192
   225    225 100%    2.06K     15       15       480K idr_layer_cache
  7616   7324  96%    0.06K    119       64       476K kmalloc-64
   700    700 100%    0.62K     28       25       448K sock_inode_cache
   252    252 100%    1.75K     14       18       448K TCP
  8925   8544  95%    0.05K    105       85       420K shared_policy_node
  3072   2351  76%    0.12K     96       32       384K kmalloc-128
   360    360 100%    1.06K     12       30       384K signal_cache
   432    337  78%    0.88K     24       18       384K mm_struct

Khác

Tôi cũng đã thử quét rootkit bằng rkhunter - nó không tìm thấy gì. Và tôi đã cố gắng đồng bộ hóa và kết xuất bộ đệm với:

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

Nó cũng không có gì khác biệt.

Tôi cũng đã cố gắng buộc trao đổi hoặc vô hiệu hóa trao đổi với:

sudo sysctl -w vm.swappiness=100
sudo swapoff /dev/sda2

Tôi cũng đã thử sử dụng htop và sắp xếp theo bộ nhớ và nó cũng không hiển thị bộ nhớ đang đi đâu. Phiên bản kernel là Linux 3.13.0-40-chung # 69-Ubuntu SMP.

Đầu ra Dmesg: http://pastie.org/9558255 đầu ra smem: http://pastie.org/9558290

Phần kết luận

Chuyện gì đang xảy ra vậy? - Tất cả ký ức sẽ đi đâu? - Làm thế nào để tôi tìm ra?

Kết luận của tôi là nó bị rò rỉ bộ nhớ kernel ở đâu đó trong kernel Linux, đây là lý do tại sao không có công cụ không gian người dùng nào có thể hiển thị nơi bộ nhớ bị rò rỉ. Có lẽ nó liên quan đến câu hỏi này: /server/670423/linux-memory-usage-higher-than-sum-of- Processes

Tôi đã nâng cấp phiên bản kernel từ 3.13 lên 3.19 và có vẻ như việc rò rỉ bộ nhớ đã dừng lại! - Tôi sẽ báo cáo lại nếu tôi thấy rò rỉ một lần nữa.

Sẽ vẫn hữu ích khi có một số cách dễ dàng / dễ dàng hơn để xem dung lượng bộ nhớ được sử dụng cho các phần khác nhau của nhân Linux. Nó vẫn là một bí ẩn những gì đã gây ra rò rỉ trong 3.13.

Câu chuyện

Tôi có thể tái tạo vấn đề của bạn bằng ZFS trên Linux .

Đây là một máy chủ được gọi node51bằng 20GBRAM. Tôi đã đánh dấu 16GiBRAM để phân bổ vào bộ đệm thay thế thích ứng ZFS (ARC) :

root@node51 [~]# echo 17179869184 > /sys/module/zfs/parameters/zfs_arc_max
root@node51 [~]# grep c_max /proc/spl/kstat/zfs/arcstats
c_max                           4    17179869184

Sau đó, tôi đọc một 45GiBtệp bằng Trình xem ống trong nhóm ZFS của mình zeltikđể điền ARC:

root@node51 [~]# pv /zeltik/backup-backups/2014.04.11.squashfs > /dev/zero
  45GB 0:01:20 [ 575MB/s] [==================================>] 100%

Bây giờ hãy nhìn vào bộ nhớ miễn phí:

root@node51 [~]# free -m
             total       used       free     shared    buffers     cached
Mem:         20013      19810        203          1         51         69
-/+ buffers/cache:      19688        324
Swap:         7557          0       7556

Nhìn!

51MiBtrong bộ đệm
69MiBtrong bộ đệm
120MiBtrong cả hai
19688MiBRAM đang sử dụng, bao gồm cả bộ đệm và bộ đệm
19568MiBcủa RAM đang sử dụng, ngoại trừ bộ đệm và bộ đệm

Tập lệnh Python mà bạn đã tham chiếu báo cáo rằng các ứng dụng chỉ sử dụng một lượng RAM nhỏ:

root@node51 [~]# python ps_mem.py
 Private  +   Shared  =  RAM used       Program

148.0 KiB +  54.0 KiB = 202.0 KiB       acpid
176.0 KiB +  47.0 KiB = 223.0 KiB       swapspace
184.0 KiB +  51.0 KiB = 235.0 KiB       atd
220.0 KiB +  57.0 KiB = 277.0 KiB       rpc.idmapd
304.0 KiB +  62.0 KiB = 366.0 KiB       irqbalance
312.0 KiB +  64.0 KiB = 376.0 KiB       sftp-server
308.0 KiB +  89.0 KiB = 397.0 KiB       rpcbind
300.0 KiB + 104.5 KiB = 404.5 KiB       cron
368.0 KiB +  99.0 KiB = 467.0 KiB       upstart-socket-bridge
560.0 KiB + 180.0 KiB = 740.0 KiB       systemd-logind
724.0 KiB +  93.0 KiB = 817.0 KiB       dbus-daemon
720.0 KiB + 136.0 KiB = 856.0 KiB       systemd-udevd
912.0 KiB + 118.5 KiB =   1.0 MiB       upstart-udev-bridge
920.0 KiB + 180.0 KiB =   1.1 MiB       rpc.statd (2)
  1.0 MiB + 129.5 KiB =   1.1 MiB       screen
  1.1 MiB +  84.5 KiB =   1.2 MiB       upstart-file-bridge
960.0 KiB + 452.0 KiB =   1.4 MiB       getty (6)
  1.6 MiB + 143.0 KiB =   1.7 MiB       init
  5.1 MiB +   1.5 MiB =   6.5 MiB       bash (3)
  5.7 MiB +   5.2 MiB =  10.9 MiB       sshd (8)
 11.7 MiB + 322.0 KiB =  12.0 MiB       glusterd
 27.3 MiB +  99.0 KiB =  27.4 MiB       rsyslogd
 67.4 MiB + 453.0 KiB =  67.8 MiB       glusterfsd (2)
---------------------------------
                        137.4 MiB
=================================

19568MiB - 137.4MiB ≈ 19431MiB RAM không đếm được

Giải trình

Bộ 120MiBđệm và bộ đệm được sử dụng mà bạn đã thấy trong câu chuyện trên cho thấy hành vi hiệu quả của dữ liệu bộ đệm của hạt nhân được gửi đến hoặc nhận từ một thiết bị bên ngoài.

Hàng đầu tiên, được gắn nhãn Mem , hiển thị việc sử dụng bộ nhớ vật lý, bao gồm cả bộ nhớ được phân bổ cho bộ đệm và bộ đệm. Bộ đệm, còn được gọi là bộ nhớ đệm , thường được định nghĩa là một phần của bộ nhớ được dành riêng làm nơi lưu giữ tạm thời cho dữ liệu được gửi đến hoặc nhận từ một thiết bị bên ngoài, chẳng hạn như ổ cứng, bàn phím, máy in hoặc mạng.

Dòng dữ liệu thứ hai, bắt đầu bằng - / + bộ đệm / bộ đệm , hiển thị lượng bộ nhớ vật lý hiện được dành cho bộ đệm bộ đệm hệ thống . Điều này đặc biệt có ý nghĩa đối với các chương trình ứng dụng, vì tất cả dữ liệu được truy cập từ các tệp trên hệ thống được thực hiện thông qua việc sử dụng các cuộc gọi hệ thống read () và write () đều đi qua bộ đệm này. Bộ đệm này có thể tăng tốc độ truy cập dữ liệu rất nhiều bằng cách giảm hoặc loại bỏ nhu cầu đọc hoặc ghi vào ổ cứng hoặc ổ đĩa khác.

^{_{Nguồn: http://www.linfo.org/free.html}}

Bây giờ làm thế nào để chúng ta giải thích cho sự mất tích 19431MiB?

Trong free -mđầu ra ở trên, 19688MiB" được sử dụng " trong " - / + bộ đệm / bộ đệm " xuất phát từ công thức này:

(kb_main_used) - (buffers_plus_cached) =
(kb_main_total - kb_main_free) - (kb_main_buffers + kb_main_cached)

kb_main_total:   MemTotal from /proc/meminfo
kb_main_free:    MemFree  from /proc/meminfo
kb_main_buffers: Buffers  from /proc/meminfo
kb_main_cached:  Cached   from /proc/meminfo

^{_{Nguồn: Procps / free.c và Procps / Proc / sysinfo.c}}

(Nếu bạn thực hiện các số dựa trên free -mđầu ra của tôi , bạn sẽ nhận thấy rằng 2MiBkhông được tính, nhưng đó là do lỗi làm tròn được giới thiệu bởi mã này #define S(X) ( ((unsigned long long)(X) << 10) >> shift):)

Các con số không được thêm vào /proc/meminfo, (tôi đã không ghi lại /proc/meminfokhi tôi chạy free -m, nhưng chúng tôi có thể thấy từ câu hỏi của bạn /proc/meminfokhông cho thấy RAM bị thiếu ở đâu), vì vậy chúng tôi có thể kết luận từ trên mà /proc/meminfokhông kể toàn bộ câu chuyện

Trong các điều kiện thử nghiệm của mình, tôi biết rằng ZFS trên Linux chịu trách nhiệm cho việc sử dụng RAM cao. Tôi đã nói với ARC rằng nó có thể sử dụng tối đa 16GiBRAM của máy chủ.

ZFS trên Linux không phải là một quá trình. Đây là một mô-đun hạt nhân.

Từ những gì tôi tìm thấy cho đến nay, việc sử dụng RAM của mô-đun hạt nhân sẽ không hiển thị bằng các công cụ thông tin quy trình vì mô-đun không phải là một quá trình.

Xử lý sự cố

Thật không may, tôi không biết đủ về Linux để cung cấp cho bạn cách xây dựng danh sách bao nhiêu thành phần không xử lý RAM (như kernel và các mô-đun của nó) đang sử dụng.

Tại thời điểm này, chúng ta có thể suy đoán, đoán và kiểm tra.

Bạn đã cung cấp một dmesgđầu ra. Các mô-đun hạt nhân được thiết kế tốt sẽ ghi lại một số chi tiết của chúng dmesg.

Sau khi nhìn qua dmesg, một món đồ nổi bật với tôi:FS-Cache

FS-Cachelà một phần của cachefilesmô-đun hạt nhân và liên quan đến gói cachefilesdtrên Debian và Red Hat Enterprise Linux.

Có lẽ cách đây một thời gian, bạn đã cấu hình FS-Cachetrên đĩa RAM để giảm tác động của I / O mạng khi máy chủ của bạn phân tích dữ liệu video.

Hãy thử vô hiệu hóa bất kỳ mô-đun hạt nhân đáng ngờ nào có thể ăn hết RAM. Họ có lẽ có thể bị vô hiệu hóa với blacklisttrong /etc/modprobe.d/, tiếp theo là một sudo update-initramfs -u(lệnh và địa điểm có thể khác nhau tùy theo bản phân phối Linux).

Phần kết luận

Rò rỉ bộ nhớ đang ăn hết 8MB/hrRAM của bạn và sẽ không giải phóng RAM, dường như bất kể bạn làm gì. Tôi không thể xác định nguồn rò rỉ bộ nhớ của bạn dựa trên thông tin mà bạn cung cấp, tôi cũng không thể đưa ra cách để tìm ra rò rỉ bộ nhớ đó.

Một người có nhiều kinh nghiệm với Linux hơn tôi sẽ cần cung cấp đầu vào về cách chúng tôi có thể xác định việc sử dụng RAM "khác" sẽ đi đâu.

Tôi đã bắt đầu trả tiền cho câu hỏi này để xem liệu chúng ta có thể nhận được câu trả lời tốt hơn là "suy đoán, đoán và kiểm tra" hay không.

Bạn có thay đổi Swapiness của hướng dẫn sử dụng Kernel của bạn hoặc vô hiệu hóa nó không?

bạn có thể giúp bạn đạt được mức độ hài lòng hiện tại với

cat /proc/sys/vm/swappiness

Bạn có thể cố gắng buộc kernel của mình trao đổi mạnh mẽ với

sudo sysctl -w vm.swappiness=100

nếu mức giảm này bạn gặp vấn đề tìm giá trị tốt trong khoảng từ 1 đến 100, phù hợp với yêu cầu của bạn.

Bạn không hoàn toàn đúng - vâng, lệnh miễn phí của bạn đang hiển thị 220 MB miễn phí nhưng nó cũng cho thấy 1771 MB được sử dụng làm bộ đệm. Bộ đệm và bộ đệm là bộ nhớ được sử dụng bởi kernel để tối ưu hóa quyền truy cập vào dữ liệu truy cập chậm, thường là đĩa. Vì vậy, bạn nên coi tất cả bộ nhớ được đánh dấu là bộ đệm là bộ nhớ trống vì kernel có thể lấy lại bất cứ khi nào cần.

Xem: /server/23433/in-linux-what-is-the-difference-b between-buffers-and-cache-reported-by-the-f