So ermitteln Sie Speicherstatistiken und Speicherlecks unter Linux

[Einführung] In der Produktentwicklung können wir durch Zählen des vom aktuellen System verbrauchten Gesamtspeichers den für das Produkt erforderlichen Gesamtspeicher genau bewerten, wodurch der geeignete Speicherchip und die entsprechende Größe ausgewählt und die Kosten des Produkts gesenkt werden. Wenn wir auf Speicherverlustprobleme stoßen, sind wir in diesem Artikel oft hilflos. Indem wir den Prozess

in der Entwicklung des Produkts durchgehen, können wir anhand der Statistiken des vom aktuellen System verbrauchten Gesamtspeichers abschätzen Bewerten Sie den Gesamtspeicherbedarf des Produkts genau, um den geeigneten Speicherchip und die entsprechende Größe auszuwählen und so die Kosten des Produkts zu senken. Wenn wir auf Speicherverlustprobleme stoßen, sind wir oft hilflos. Dieser Artikel analysiert die prozessbezogenen Dateien unter proc, um die Größe des vom System verbrauchten Speichers genau einzuschätzen. Er kann auch eine Positionierungsmethode zur Lösung von Speicherverlustproblemen bereitstellen.

Das Prinzip von Linux zur Speichernutzung lautet: Wenn genügend Speicher vorhanden ist, verwenden Sie ihn nicht umsonst, um die Ausführungsgeschwindigkeit des Prozesses zu beschleunigen nicht ausreicht, wird der entsprechende Speicher wiederverwendet. Die Richtlinie fordert den Cache-Speicher zur Verwendung durch den Prozess zurück.

1. Analyse des gesamten Systemspeichers

Sie können die aktuelle Zusammenfassung der Systemspeichernutzung aus der Meminfo-Datei im Proc-Verzeichnis erfahren, wo verfügbarer physischer Speicher = memfree + ist Puffer + Cache: Wenn memfree nicht ausreicht, schreibt der Kernel den zwischengespeicherten und gepufferten Speicher über den Rückschreibmechanismus (pdflush-Thread) in den Hintergrundspeicher zurück und gibt dadurch den relevanten Speicher zur Verwendung durch den Prozess frei oder gibt den Cache-Speicher explizit frei manuell:

echo 3 > /proc/sys/vm/drop_caches

Das Bild unten zeigt die Gesamtnutzung des Systemspeichers unter der HiSilicon-Plattform. Es ist ersichtlich, dass das System 29 MB Speicher verbraucht hat.

# cat /proc/meminfo

MemTotal: 68956 kB

 MemTotal:        68956 kB

MemFree:         18632 kB

Buffers:          4096 kB

Cached:          17260 kB

SwapCached:          0 kB

Active:          21304 kB

Inactive:        19248 kB

SwapTotal:           0 kB

SwapFree:            0 kB

Dirty:               0 kB

Writeback:           0 kB

AnonPages:       19216 kB

Mapped:           2472 kB

Slab:             6900 kB

SReclaimable:      924 kB

SUnreclaim:       5976 kB

PageTables:        460 kB

NFS_Unstable:        0 kB

Bounce:              0 kB

CommitLimit:     62060 kB

Committed_AS:    28864 kB

VmallocTotal:   442368 kB

VmallocUsed:     46984 kB

VmallocChunk:   393212 kB

MemFree: 18632 kBPuffer: 4096 kBGespeichert: 17260 kBSwapCached: 0 kBAktiv: 21304 kBInaktiv: 19248 kBSwapTotal: 0 kBSwapFree: 0 kBDirty: 0 kBWriteback:         0 kBAnonPages: 19216 kBZugeordnet: 2472 kBSlab: 6900 kBSReclaimable: 924 kBSUnreclaim: 5976 kBPageTables: 460 kBNFS_Unstable: 0 kBBounce: 0 kBCommitLimit: 62060 kBCommitted_AS: 28864 kBVmallocTotal: 442368 kBVmallocUsed: 46984 kBVmallocChunk: 393212 kB

　　二、进程使用内存的统计

在32位操作系统中，每个进程拥有4G的虚拟内存空间，其中0~3GB是每个进程的私有用户空间，这个空间对系统中其他进程是不可见的。3~4GB是linux内核空间，由系统所有的进程以及内核所共享的。通过访问/proc/{pid}/下相关文件，可以了解每个线程虚拟内存空间的使用情况，从而了解每个线程所消耗内存的多少。

由于我们的产品都是使用多线程方式实现的，多个线程共享一个进程的用户态虚拟地址空间，虚拟地址空间包含若干区域，主要有如下几个区域：

1、当前执行文件的代码段，该代码段称为text段。

2、执行文件的数据段，主要存储执行文件用到的全局变量，静态变量。

3、存储全局变量和动态产生的数据的堆。

4、用于保存局部变量和实现函数调用的栈。

5、采用mmap方式映射到虚拟地址空间中的内存段

所以只需要查看任意一个线程的用户态虚拟地址空间分配即可知道属于同一进程的所有线程占用总内存的大小。可以通过查看/proc/{pid}/maps文件来获取相关的虚拟地址空间内容，下文摘列部分典型的内容：

# cat /proc/568/maps

 00008000-0036a000 r-xp 00000000 00:0e 236        /home/hik/hicore

00372000-003a5000 rw-p 00362000 00:0e 236        /home/hik/hicore

003a5000-00e28000 rwxp 003a5000 00:00 0          [heap]

40000000-40005000 r-xp 00000000 01:00 94         /lib/ld-uClibc.so.0

416db000-41770000 rw-s c2005000 00:0f 68         /dev/mem

b51fc000-b5200000 rwxp b51fc000 00:00 0

…….

be1fc000-be200000 rwxp be1fc000 00:00 0

be93b000-be950000 rwxp befeb000 00:00 0          [stack]

第一行：从r-xp可知其权限为只读、可执行，该段内存地址对应于执行文件的代码段，程序的代码段需加载到内存中才可以执行。由于其只读，不会被修改，所以在整个系统内共享。

第二行：从rw-p可知其权限为可读写，不可执行，该段内存地址对应于执行文件的数据段，存放执行文件所用到的全局变量、静态变量。

第三行：从rwxp可知其权限是可读写，可执行，地址空间向上增长，而且不对应文件，是堆段，进程使用malloc申请的内存放在堆段。每个进程只有一个堆段，不论是主进程，还是不同的线程申请的内存，都反映到到进程的堆段。堆段向上增长，最大可以增长到1GB的位置，即0x40000000，如果大于1GB，glibc将采用mmap的方式，为堆申请一块内存。

第四行：是程序连接的共享库的内存地址。

第五行：是以mmap方式映射的虚拟地址空间。

第六、七行：是线程的栈区地址段，每个线程的栈大小都是16K。

第八行：是进程的栈区。关于栈段，每个线程都有一个，如果进程中有多个线程，则包含多个栈段。

三、当前系统总内存的统计

1、进程占用的总内存可以通过上述maps表计算出来。

2、当系统运行起来以后，会把应用层相关的文件挂载到tmpfs文件系统下，海思系统下这部分大概有13M左右，这部分内存是以cache方式统计出来的，但是这部分内存cache无法通过回收策略或者显式的调用释放掉。

3、根文件系统ramdisk占用的内存。

4、当前系统保留内存的大小，可以通过查看/proc/sys/vm/min_free_kbytes来获取或者修改此内存的大小。

5、当然，当系统运行起来后，还应该留有一定的内存用于在硬盘读写时做cache或者网络负荷比较高时分配skb等，一般需要30M以上。

四、对调试内存泄露类问题的一些启示

当进程申请内存时，实际上是glibc中内置的内存管理器接收了该请求，随着进程申请内存的增加，内存管理器会通过系统调用陷入内核，从而为进程分配更多的内存。

针对堆段的管理，内核提供了两个系统调用brk和mmap，brk用于更改堆顶地址，而mmap则为进程分配一块虚拟地址空间。

当进程向glibc申请内存时，如果申请内存的数量大于一个阀值的时候，glibc会采用mmap为进程分配一块虚拟地址空间，而不是采用brk来扩展堆顶的指针。缺省情况下，此阀值是128K，可以通过函数来修改此值。

#include <malloc.h>

Int mallopt(int param, int value)

Param的取值分别为M_MMAP_THRESHOLD、M_MMAP_MAX。

Value的取值是以字节为单位的。

M_MMAP_THRESHOLD是glibc中申请大块内存阀值，大于该阀值的内存申请，内存管理器将使用mmap系统调用申请内存，如果小于该阀值的内存申请，内存管理器使用brk系统调用扩展堆顶指针。

M_MMAP_MAX是该进程中最多使用mmap分配地址段的数量。

如果在实际的调试过程中，怀疑某处发生了内存泄露，可以查看该进程的maps表，看进程的堆段或者mmap段的虚拟地址空间是否持续增加，如果是，说明很可能发生了内存泄露，如果mmap段虚拟地址空间持续增加，还可以看到各个段的虚拟地址空间的大小，从而可以确定是申请了多大的内存，对调试内存泄露类问题可以起到很好的定位作用。

• 
  

Das obige ist der detaillierte Inhalt vonSo ermitteln Sie Speicherstatistiken und Speicherlecks unter Linux. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!