精华内容
下载资源
问答
  • 1、JSTACK 排除CPU占用过高的线程 查找TOMCAT的进程ID ps aux | grep tomcat top -H -p pid ps -mp pid -o THREAD,tid,time //转化TID为16进制 printf "%x\n" tid jstack p...

    1、JSTACK 排除CPU占用过高的线程

    查找TOMCAT的进程ID

    ps aux | grep tomcat

    top -H -p pid

    ps -mp pid -o THREAD,tid,time

    //转化TID为16进制

    printf "%x\n" tid

    jstack pid | grep tid -A 30

    一般配置JVM启动参数,让JVM在遇到OutOfMemoryError时自动生成Dump文件

    -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path

    2、jmap -histo pid 展示class的内存情况

    说明:instances(实例数)、bytes(大小)、classs name(类名)。它基本是按照使用使用大小逆序排列的。 

    #instance 是对象的实例个数 
    #bytes 是总占用的字节数 
    class name 对应的就是 Class 文件里的 class 的标识 
    B 代表 byte
    C 代表 char
    D 代表 double
    F 代表 float
    I 代表 int
    J 代表 long
    Z 代表 boolean
    前边有 [ 代表数组, [I 就相当于 int[]
    对象用 [L+ 类名表示

    第一步:导出堆

    #jmap -dump:live,file=a.log pid

    除了使用jmap命令,还可以通过以下方式:

    1、使用 jconsole 选项通过 HotSpotDiagnosticMXBean 从运行时获得堆转储(生成dump文件)、

    2、虚拟机启动时如果指定了 -XX:+HeapDumpOnOutOfMemoryError 选项, 则在抛出 OutOfMemoryError 时, 会自动执行堆转储。

    3、使用 hprof 命令

     

    第二步:分析堆文件,推荐用其他工具加载,例如:visualvm

    #jhat -J-Xmx512M a1.log

    说明:有时dump出来的堆很大,在启动时会报堆空间不足的错误,可加参数:jhat -J-Xmx512m <heap dump file>。这个内存大小可根据自己电脑进行设置。

    解析Java堆转储文件,并启动一个 web server

     

    第三步:查看html

    http://ip:7000/

     

    第四步,jmap -heap pid

    using parallel threads in the new generation.  ##新生代采用的是并行线程处理方式

    using thread-local object allocation.   

    Concurrent Mark-Sweep GC   ##同步并行垃圾回收

     

    Heap Configuration:  ##堆配置情况

       MinHeapFreeRatio = 40 ##最小堆使用比例

       MaxHeapFreeRatio = 70 ##最大堆可用比例

       MaxHeapSize      = 2147483648 (2048.0MB) ##最大堆空间大小

       NewSize          = 268435456 (256.0MB) ##新生代分配大小

       MaxNewSize       = 268435456 (256.0MB) ##最大可新生代分配大小

       OldSize          = 5439488 (5.1875MB) ##老生代大小

       NewRatio         = 2  ##新生代比例

       SurvivorRatio    = 8 ##新生代与suvivor的比例

       PermSize         = 134217728 (128.0MB) ##perm区大小

       MaxPermSize      = 134217728 (128.0MB) ##最大可分配perm区大小

     

    Heap Usage: ##堆使用情况

    New Generation (Eden + 1 Survivor Space):  ##新生代(伊甸区 + survior空间)

       capacity = 241631232 (230.4375MB)  ##伊甸区容量

       used     = 77776272 (74.17323303222656MB) ##已经使用大小

       free     = 163854960 (156.26426696777344MB) ##剩余容量

       32.188004570534986% used ##使用比例

    Eden Space:  ##伊甸区

       capacity = 214827008 (204.875MB) ##伊甸区容量

       used     = 74442288 (70.99369812011719MB) ##伊甸区使用

       free     = 140384720 (133.8813018798828MB) ##伊甸区当前剩余容量

       34.65220164496263% used ##伊甸区使用情况

    From Space: ##survior1区

       capacity = 26804224 (25.5625MB) ##survior1区容量

       used     = 3333984 (3.179534912109375MB) ##surviror1区已使用情况

       free     = 23470240 (22.382965087890625MB) ##surviror1区剩余容量

       12.43827838477995% used ##survior1区使用比例

    To Space: ##survior2 区

       capacity = 26804224 (25.5625MB) ##survior2区容量

       used     = 0 (0.0MB) ##survior2区已使用情况

       free     = 26804224 (25.5625MB) ##survior2区剩余容量

       0.0% used ## survior2区使用比例

    concurrent mark-sweep generation: ##老生代使用情况

       capacity = 1879048192 (1792.0MB) ##老生代容量

       used     = 30847928 (29.41887664794922MB) ##老生代已使用容量

       free     = 1848200264 (1762.5811233520508MB) ##老生代剩余容量

       1.6416783843721663% used ##老生代使用比例

    Perm Generation: ##perm区使用情况

       capacity = 134217728 (128.0MB) ##perm区容量

       used     = 47303016 (45.111671447753906MB) ##perm区已使用容量

       free     = 86914712 (82.8883285522461MB) ##perm区剩余容量

       35.24349331855774% used ##perm区使用比例

     

    3、jstat 命令

    jstat -gc pid 1000 或者 jstat -gc pid 1000 > out.txt: 每隔1000号码打印一次或导出 GC 的状态。

    • S0C S0U:Survivor 0区的大小及使用情况
    • S1C S1U:Survivor 1区的大小及使用情况
    • EC EU:Eden 区的大小及使用情况
    • OC OU:Old 区的大小及使用情况
    • PC PU:Perm 区的大小及使用情况(Java 8 中取消)
    • MC MU:Metaspace 区的大小及使用情况(Java 8 中用户替代 Perm 区)
    • YGC YGCT:Young Generation Minor GC 的数目及时间(单位秒)
    • FGC FGCT:Old Generation Full GC 的数目及时间(单位秒)
    • GCT:GC 总时间 = YGCT + FGCT(单位秒)

    转载于:https://my.oschina.net/u/3086399/blog/1923875

    展开全文
  • c++内存泄漏查找

    2019-09-23 21:20:14
    1、查找内存泄漏 top 查看内存情况 找到异常pid cat /proc/pid/maps 找到堆栈地址 gdbGameServer attach pid dump memory /tmp/test.dump 0x12121221 0x3431534151 more /tmp/test.dump (sudogdbattach6900) ...

    1、查找内存泄漏
    top 查看内存情况 找到异常pid
    cat /proc/pid/maps 找到堆栈地址
    gdb GameServer
    attach pid
    dump memory /tmp/test.dump 0x12121221 0x3431534151
    more /tmp/test.dump

    (sudo gdb attach 6900)

     

    strings -n 20 test.dump | more

    你已经找到运行的进程的PID,dump出了那个进程的内存内容,然后用gdb,strings命令找出了有用的数据。

     

    # 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以上。

     

     

    linux下利用valgrind工具进行内存泄露检测和性能分析

    valgrind通常用来成分析程序性能及程序中的内存泄露错误

     

    一 Valgrind工具集简绍

    Valgrind包含下列工具:

        1、memcheck:检查程序中的内存问题,如泄漏、越界、非法指针等。

        2、callgrind:检测程序代码的运行时间和调用过程,以及分析程序性能。

        3、cachegrind:分析CPU的cache命中率、丢失率,用于进行代码优化。

        4、helgrind:用于检查多线程程序的竞态条件。

        5、massif:堆栈分析器,指示程序中使用了多少堆内存等信息。

        6、lackey:

        7、nulgrind:

    这几个工具的使用是通过命令:valgrand --tool=name 程序名来分别调用的,当不指定tool参数时默认是 --tool=memcheck

     

    二 Valgrind工具详解

    1.Memcheck

        最常用的工具,用来检测程序中出现的内存问题,所有对内存的读写都会被检测到,一切对malloc、free、new、delete的调用都会被捕获。所以,它能检测以下问题:

           1、对未初始化内存的使用;

           2、读/写释放后的内存块;

           3、读/写超出malloc分配的内存块;

           4、读/写不适当的栈中内存块;

           5、内存泄漏,指向一块内存的指针永远丢失;

           6、不正确的malloc/free或new/delete匹配;

           7、memcpy()相关函数中的dst和src指针重叠。

    这些问题往往是C/C++程序员最头疼的问题,Memcheck能在这里帮上大忙。

     

    2.Callgrind

        和gprof类似的分析工具,但它对程序的运行观察更是入微,能给我们提供更多的信息。和gprof不同,它不需要在编译源代码时附加特殊选项,但加上调试选项是推荐的。Callgrind收集程序运行时的一些数据,建立函数调用关系图,还可以有选择地进行cache模拟。在运行结束时,它会把分析数据写入一个文件。callgrind_annotate可以把这个文件的内容转化成可读的形式。

    生成可视化的图形需要下载gprof2dot:http://jrfonseca.googlecode.com/svn/trunk/gprof2dot/gprof2dot.py

    这是个python脚本,把它下载之后修改其权限chmod +7 gprof2dot.py ,并把这个脚本添加到$PATH路径中的任一文件夹下,我是将它放到了/usr/bin目录下,这样就可以直接在终端下执行gprof2dot.py了。

       Callgrind可以生成程序性能分析的图形,首先来说说程序性能分析的工具吧,通常可以使用gnu自带的gprof,它的使用方法是:在编译程序时添加-pg参数,例如:

    首先执行 gcc -pg -o tmp tmp.c,然后运行该程序./tmp,程序运行完成后会在当前目录下生成gmon.out文件(这个文件gprof在分析程序时需要),
    再执行gprof ./tmp | gprof2dot.py |dot -Tpng -o report.png,打开report.png结果:

    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]

     

    显示test被调用了5次,程序中耗时所占百分比最多的是test函数。

    再来看 Callgrind的生成调用图过程吧,执行:valgrind --tool=callgrind ./tmp,执行完成后在目录下生成"callgrind.out.XXX"的文件这是分析文件,可以直接利用:callgrind_annotate callgrind.out.XXX 打印结果,也可以使用:gprof2dot.py -f callgrind callgrind.out.XXX |dot -Tpng -o report.png 来生成图形化结果:

    3.Cachegrind

           Cache分析器,它模拟CPU中的一级缓存I1,Dl和二级缓存,能够精确地指出程序中cache的丢失和命中。如果需要,它还能够为我们提供cache丢失次数,内存引用次数,以及每行代码,每个函数,每个模块,整个程序产生的指令数。这对优化程序有很大的帮助。

        作一下广告:valgrind自身利用该工具在过去几个月内使性能提高了25%-30%。据早先报道,kde的开发team也对valgrind在提高kde性能方面的帮助表示感谢。

    它的使用方法也是:valgrind --tool=cachegrind 程序名,

    4.Helgrind

        它主要用来检查多线程程序中出现的竞争问题。Helgrind寻找内存中被多个线程访问,而又没有一贯加锁的区域,这些区域往往是线程之间失去同步的地方,而且会导致难以发掘的错误。Helgrind实现了名为“Eraser”的竞争检测算法,并做了进一步改进,减少了报告错误的次数。不过,Helgrind仍然处于实验阶段。

    5. Massif

        堆栈分析器,它能测量程序在堆栈中使用了多少内存,告诉我们堆块,堆管理块和栈的大小。Massif能帮助我们减少内存的使用,在带有虚拟内存的现代系统中,它还能够加速我们程序的运行,减少程序停留在交换区中的几率。

           Massif对内存的分配和释放做profile。程序开发者通过它可以深入了解程序的内存使用行为,从而对内存使用进行优化。这个功能对C++尤其有用,因为C++有很多隐藏的内存分配和释放。

     

    此外,lackey和nulgrind也会提供。Lackey是小型工具,很少用到;Nulgrind只是为开发者展示如何创建一个工具。我们就不做介绍了。

    三 使用Valgrind

           Valgrind使用起来非常简单,你甚至不需要重新编译你的程序就可以用它。当然如果要达到最好的效果,获得最准确的信息,还是需要按要求重新编译一下的。比如在使用memcheck的时候,最好关闭优化选项。

           valgrind命令的格式如下:

           valgrind [valgrind-options] your-prog [your-prog options]

    valgrind --tool=massif --stacks=yes ./test

    (这个工具有个bug, 只有程序中出现new或者malloc之类的堆操作,才会统计栈的使用,否则只统计堆的使用)

    一些常用的选项如下:

    选项

    作用

    -h --help

    显示帮助信息。

    --version

    显示valgrind内核的版本,每个工具都有各自的版本。

    -q --quiet

    安静地运行,只打印错误信息。

    -v --verbose

    打印更详细的信息。

    --tool=<toolname> [default: memcheck]

    最常用的选项。运行valgrind中名为toolname的工具。如果省略工具名,默认运行memcheck。

    --db-attach=<yes|no> [default: no]

    绑定到调试器上,便于调试错误。

     

    展开全文
  • android 内存泄漏查找

    2019-04-02 21:53:21
    前提:一般在日志中看到如下信息基本上就是内存泄漏了,然后需要知道是哪个应用 第一步:找到内存泄漏的机器连上电脑。 第二步:输入命令找到进程号:adb shell top -d 1 -m 10,我这里是lancher泄漏,找到进程号是...

    前提:一般在日志中看到如下信息基本上就是内存泄漏了,然后需要知道是哪个应用

    第一步:找到内存泄漏的机器连上电脑。

    第二步:输入命令找到进程号:adb shell top -d 1 -m 10,我这里是lancher泄漏,找到进程号是1025
    在这里插入图片描述第三步: adb shell dumpsys meminfo xx.xx.launcher 查看这个应用下当前有多少个activity,可以确定这里有15个activity,不应该这么多,因为我们很多activity是单列的
    在这里插入图片描述第四步:打开sdk目录,C:\Users\Orion\AppData\Local\Android\Sdk,点击monitor在这里插入图片描述第五步:导出dump文件,找到lancher进程然后导出

    https://blog.csdn.net/my_rabbit/article/details/79831911
    在这里插入图片描述

    第六步:转换dump文件,第五步导出的文件在MemoryAnalyzer 是不能直接看的需要转化,输入如下命令:hprof-conv.exe 导出.hprof 111.hprof,这个111.hprof就是我们转换好的

    在这里插入图片描述第7步:打开MemoryAnalyzer ,然后file–>open

    在这里插入图片描述第8步:输入指令查找那15个activity
    在这里插入图片描述第9步:右键查找引用:在这里插入图片描述第10步:这里就知道是某activity的fragment的$1变量持有了,$1可以在maping文件中找到
    在这里插入图片描述

    展开全文
  • 在实际的项目中,最难缠的问题就是内存泄漏,当然还有panic之类的,内存泄漏分为两部分用户空间的和内核空间的.我们就分别从这两个层面分析一下.用户空间查看内存泄漏和解决都相对简单。定位问题的方法和工具也很多...

    在实际的项目中,最难缠的问题就是内存泄漏,当然还有panic之类的,内存泄漏分为两部分用户空间的和内核空间的.我们就分别从这两个层面分析一下.

    98d82b34efca83c06a868ebc397028f4.png

    用户空间查看内存泄漏和解决都相对简单。定位问题的方法和工具也很多相对容易.我们来看看.

    1. 查看内存信息

    cat /proc/meminfo、free、cat /proc/slabinfo等

    2.  查看进程的状态信息

    top、ps、cat /proc/pid/maps/status/fd等

    通常我们定位问题先在shell下ps查看当前运行进程的状态,嵌入式上可能显示的信息会少一些.

    点击(此处)折叠或打开

    root@hos-machine:~# ps -uaxw

    USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND

    root 1 0.0 0.1 119872 3328 ? Ss 8月10 0:24 /sbin/init splash

    root 2 0.0 0.0 0 0 ? S 8月10 0:00 [kthreadd]

    root 3 0.0 0.0 0 0 ? S 8月10 0:44 [ksofTIrqd/0]

    root 5 0.0 0.0 0 0 ? S

    root 7 0.0 0.0 0 0 ? S 8月10 3:50 [rcu_sched]

    root 8 0.0 0.0 0 0 ? S 8月10 0:00 [rcu_bh]

    root 9 0.0 0.0 0 0 ? S 8月10 0:12 [migraTIon/0]

    root 10 0.0 0.0 0 0 ? S 8月10 0:01 [watchdog/0]

    root 11 0.0 0.0 0 0 ? S 8月10 0:01 [watchdog/1]

    root 12 0.0 0.0 0 0 ? S 8月10 0:12 [migraTIon/1]

    root 13 0.0 0.0 0 0 ? S 8月10 1:18 [ksofTIrqd/1]

    root 15 0.0 0.0 0 0 ? S

    root 16 0.0 0.0 0 0 ? S 8月10 0:01 [watchdog/2]

    root 17 0.0 0.0 0 0 ? S 8月10 0:12 [migration/2]

    root 18 0.0 0.0 0 0 ? S 8月10 1:19 [ksoftirqd/2]

    root 20 0.0 0.0 0 0 ? S

    root 21 0.0 0.0 0 0 ? S 8月10 0:01 [watchdog/3]

    root 22 0.0 0.0 0 0 ? S 8月10 0:13 [migration/3]

    root 23 0.0 0.0 0 0 ? S 8月10 0:41 [ksoftirqd/3]

    root 25 0.0 0.0 0 0 ? S

    root 26 0.0 0.0 0 0 ? S 8月10 0:00 [kdevtmpfs]

    root 27 0.0 0.0 0 0 ? S

    root 329 0.0 0.0 0 0 ? S

    root 339 0.0 0.0 0 0 ? S

    root 343 0.0 0.0 0 0 ? S

    root 368 0.0 0.0 39076 1172 ? Ss 8月10 0:10 /lib/systemd/systemd-journald

    root 373 0.0 0.0 0 0 ? S 8月10 0:00 [kauditd]

    root 403 0.0 0.0 45772 48 ? Ss 8月10 0:01 /lib/systemd/systemd-udevd

    root 444 0.0 0.0 0 0 ? S

    systemd+ 778 0.0 0.0 102384 516 ? Ssl 8月10 0:04 /lib/systemd/systemd-timesyncd

    root 963 0.0 0.0 191264 8 ? Ssl 8月10 0:00 /usr/bin/vmhgfs-fuse -o subtype=vmhgfs-fuse,allow_other /mnt/hgfs

    root 987 9.6 0.0 917024 0 ? Ssl 8月10 416:08 /usr/sbin/vmware-vmblock-fuse -o subtype=vmware-vmblock,default_permi

    root 1007 0.2 0.1 162728 3084 ? Sl 8月10 10:14 /usr/sbin/vmtoolsd

    root 1036 0.0 0.0 56880 844 ? S 8月10 0:00 /usr/lib/vmware-vgauth/VGAuthService -s

    root 1094 0.0 0.0 203216 388 ? Sl 8月10 1:48 ./ManagementAgentHost

    root 1100 0.0 0.0 28660 136 ? Ss 8月10 0:02 /lib/systemd/systemd-logind

    message+ 1101 0.0 0.1 44388 2608 ? Ss 8月10 0:21 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile

    root 1110 0.0 0.0 173476 232 ? Ssl 8月10 0:54 /usr/sbin/thermald --no-daemon --dbus-enable

    root 1115 0.0 0.0 4400 28 ? Ss 8月10 0:14 /usr/sbin/acpid

    root 1117 0.0 0.0 36076 568 ? Ss 8月10 0:01 /usr/sbin/cron -f

    root 1133 0.0 0.0 337316 976 ? Ssl 8月10 0:00 /usr/sbin/ModemManager

    root 1135 0.0 0.2 634036 5340 ? Ssl 8月10 0:19 /usr/lib/snapd/snapd

    root 1137 0.0 0.0 282944 392 ? Ssl 8月10 0:06 /usr/lib/accountsservice/accounts-daemon

    syslog 1139 0.0 0.0 256396 352 ? Ssl 8月10 0:04 /usr/sbin/rsyslogd -n

    avahi 1145 0.0 0.0 44900 1092 ? Ss 8月10 0:11 avahi-daemon: running [hos-machine.local]

    这个是ubuntu系统里的信息比较详细,我们可以很清晰看到VMZ和RSS的对比信息.VMZ就是这个进程申请的虚拟地址空间,而RSS是这个进程占用的实际物理内存空间.

    通常一个进程如果有内存泄露VMZ会不断增大,相对的物理内存也会增加,如果是这样一般需要检查malloc/free是否匹配。根据进程ID我们可以查看详细的VMZ相关的信息。例:

    点击(此处)折叠或打开

    root@hos-machine:~# cat /proc/1298/status

    Name:    sshd

    State:    S (sleeping)

    Tgid:    1298

    Ngid:    0

    Pid:    1298

    PPid:    1

    TracerPid:    0

    Uid:    0    0    0    0

    Gid:    0    0    0    0

    FDSize:    128

    Groups:

    NStgid:    1298

    NSpid:    1298

    NSpgid:    1298

    NSsid:    1298

    VmPeak:     65620 kB

    VmSize:     65520 kB

    VmLck:     0 kB

    VmPin:     0 kB

    VmHWM:     5480 kB

    VmRSS:     5452 kB

    VmData:     580 kB

    VmStk:     136 kB

    VmExe:     764 kB

    VmLib:     8316 kB

    VmPTE:     148 kB

    VmPMD:     12 kB

    VmSwap:     0 kB

    HugetlbPages:     0 kB

    Threads:    1

    SigQ:    0/7814

    SigPnd:    0000000000000000

    ShdPnd:    0000000000000000

    SigBlk:    0000000000000000

    SigIgn:    0000000000001000

    SigCgt:    0000000180014005

    CapInh:    0000000000000000

    CapPrm:    0000003fffffffff

    CapEff:    0000003fffffffff

    CapBnd:    0000003fffffffff

    CapAmb:    0000000000000000

    Seccomp:    0

    Cpus_allowed:    ffffffff,ffffffff

    Cpus_allowed_list:    0-63

    Mems_allowed:    00000000,00000001

    Mems_allowed_list:    0

    voluntary_ctxt_switches:    1307

    nonvoluntary_ctxt_switches:    203

    如果我们想查看这个进程打开了多少文件可以

    ls -l /proc/1298/fd/* | wc

    查看进程详细的内存映射信息

    cat /proc/7393/maps

    我们看一下meminfo各个注释:参考documentation/filesystem/proc.txt

    MemTotal: Total usable ram (i.e. physical ram minus a few reserved bits and the kernel binary code)

    MemFree: The sum of LowFree+HighFree

    Buffers: Relatively temporary storage for raw disk blocks shouldn't get tremendously large (20MB or so)

    Cached: in-memory cache for files read from the disk (the pagecache). Doesn't include

    SwapCached SwapCached: Memory that once was swapped out, is swapped back in but still also is in the swapfile (if memory is needed it

    doesn't need to be swapped out AGAIN because it is already in the swapfile. This saves I/O)

    Active: Memory that has been used more recently and usually not reclaimed unless absolutely necessary.

    Inactive: Memory which has been less recently used. It is more eligible to be reclaimed for other purposes

    HighTotal:

    HighFree: Highmem is all memory above ~860MB of physical memory Highmem areas are for use by userspace programs, or

    for the pagecache. The kernel must use tricks to access this memory, making it slower to access than lowmem.

    LowTotal:

    LowFree: Lowmem is memory which can be used for everything that highmem can be used for, but it is also available for the

    kernel's use for its own data structures. Among many other things, it is where everything from the Slab is

    allocated. Bad things happen when you're out of lowmem.

    SwapTotal: total amount of swap space available

    SwapFree: Memory which has been evicted from RAM, and is temporarily on the disk

    Dirty: Memory which is waiting to get written back to the disk

    Writeback: Memory which is actively being written back to the disk

    AnonPages: Non-file backed pages mapped into userspace page tables

    AnonHugePages: Non-file backed huge pages mapped into userspace page tables

    Mapped: files which have been mmaped, such as libraries

    Slab: in-kernel data structures cache

    SReclaimable: Part of Slab, that might be reclaimed, such as caches

    SUnreclaim: Part of Slab, that cannot be reclaimed on memory pressure

    PageTables: amount of memory dedicated to the lowest level of page tables.

    NFS_Unstable: NFS pages sent to the server, but not yet committed to stable storage

    Bounce: Memory used for block device "bounce buffers"

    WritebackTmp: Memory used by FUSE for temporary writeback buffers

    CommitLimit: Based on the overcommit ratio ('vm.overcommit_ratio'), this is the total amount of memory currently available to

    be allocated on the system. This limit is only adhered to if strict overcommit accounting is enabled (mode 2 in

    'vm.overcommit_memory').

    The CommitLimit is calculated with the following formula: CommitLimit = ('vm.overcommit_ratio' * Physical RAM) + Swap

    For example, on a system with 1G of physical RAM and 7G

    of swap with a `vm.overcommit_ratio` of 30 it would

    yield a CommitLimit of 7.3G.

    For more details, see the memory overcommit documentation in vm/overcommit-accounting.

    Committed_AS: The amount of memory presently allocated on the system. The committed memory is a sum of all of the memory which

    has been allocated by processes, even if it has not been

    "used" by them as of yet. A process which malloc()'s 1G

    of memory, but only touches 300M of it will only show up as using 300M of memory even if it has the address space

    allocated for the entire 1G. This 1G is memory which has been "committed" to by the VM and can be used at any time

    by the allocating application. With strict overcommit enabled on the system (mode 2 in 'vm.overcommit_memory'),

    allocations which would exceed the CommitLimit (detailed above) will not be permitted. This is useful if one needs

    to guarantee that processes will not fail due to lack of memory once that memory has been successfully allocated.

    VmallocTotal: total size of vmalloc memory area

    VmallocUsed: amount of vmalloc area which is used

    VmallocChunk: largest contiguous block of vmalloc area which is free

    我们只需要关注几项就ok.  buffers/cache/slab/active/anonpages

    Active= Active(anon) + Active(file)    (同样Inactive)

    AnonPages: Non-file backed pages mapped into userspace page tables\

    buffers和cache的区别注释说的很清楚了.

    有时候不是内存泄露,同样也会让系统崩溃,比如cache、buffers等占用的太多,打开太多文件,而等待系统自动回收是一个非常漫长的过程.

    从proc目录下的meminfo文件了解到当前系统内存的使用情况汇总,其中可用的物理内存=memfree+buffers+cached,当memfree不够时,内核会通过

    回写机制(pdflush线程)把cached和buffered内存回写到后备存储器,从而释放相关内存供进程使用,或者通过手动方式显式释放cache内存

    点击(此处)折叠或打开

    drop_caches

    Writing to this will cause the kernel to drop clean caches, dentries and inodes from memory, causing that memory to become free.

    To free pagecache:

    echo 1 > /proc/sys/vm/drop_caches

    To free dentries and inodes:

    echo 2 > /proc/sys/vm/drop_caches

    To free pagecache, dentries and inodes:

    echo 3 > /proc/sys/vm/drop_caches

    As this is a non-destructive operation and dirty objects are not freeable, the user should run `sync`first

    用户空间内存检测也可以通过mtrace来检测用法也非常简单,之前文章我们有提到过. 包括比较有名的工具valgrind、以及dmalloc、memwatch等.各有特点.

    内核内存泄露的定位比较复杂,先判断是否是内核泄露了,然后在具体定位什么操作,然后再排查一些可疑的模块,内核内存操作基本都是kmalloc

    即通过slab/slub/slob机制,所以如果meminfo里slab一直增长那么很有可能是内核的问题.我们可以更加详细的查看slab信息

    cat /proc/slabinfo

    如果支持slabtop更好,基本可以判断内核是否有内存泄漏,并且是在操作什么对象的时候发生的。

    点击(此处)折叠或打开

    cat /proc/slabinfo

    slabinfo - version: 2.1

    # name      : tunables    : slabdata

    fuse_request 0 0 288 28 2 : tunables 0 0 0 : slabdata 0 0 0

    fuse_inode 0 0 448 18 2 : tunables 0 0 0 : slabdata 0 0 0

    fat_inode_cache 0 0 424 19 2 : tunables 0 0 0 : slabdata 0 0 0

    fat_cache 0 0 24 170 1 : tunables 0 0 0 : slabdata 0 0 0

    在内核的配置中里面已经支持了一部分memleak自动检查的选项,可以打开来进行跟踪调试.

    这里没有深入的东西,算是抛砖引玉吧~.

    展开全文
  • Showing top 10 nodes out of 117 (cum >= 1802254) flat flat% sum% cum cum% 62308988 74.71% 74.71% 62521981 74.97% reflect.Value.call 2413961 2.89% 77.61% 2424884 2.91% calldb.fromToDiff 1769493 ...
  • 方法 import tracemalloc def test(): tracemalloc.start() snapshot1 = tracemalloc.take_snapshot() ... top_stats = snapshot2.compare_to(snapshot1, 'lineno') print(top_stats[0:10]) 打印结果: [<
  • 今天发现在OpenWRT(RT5350)跑的一个应用程序(C++写的)内存溢出导致程序崩溃;同事叫我安装GDB来调试,我...无奈之下我就一个线程一个线程注释来查看内存top命令看内存使用情况);发现其中一个线程注释后就不会内
  • jvm内存泄漏排查流程

    千次阅读 2019-08-02 13:15:22
    1.查询cpu消耗最大的进程 jps 先找出来那些java进程 ...2.查找占用内存最大的线程 1.命令:ps p pid -L -o pcpu,pid,tid,time,tname,cmd %CPU PID TID TIME TTY CMD 0.0 32060 32060 00:00:00 ? /data/...
  • 1.查询cpu消耗最大的进程jps 先找出来那些java进程top 命令查看...查找占用内存最大的线程1.命令:ps p pid -L -o pcpu,pid,tid,time,tname,cmd%CPU PID TID TIME TTY CMD0.0 32060 32060 00:00:00 ? /data/java0.0...
  • 利用top以及valgrind命令去查找测试, 1.利用valgrind命令。这个命令大概是这样使用的:valgrind --tool=memcheck --show-reachable=yes ./a.out 然后可以得到一个这样的东西: /* ==2741== ==2741== ERROR ...
  • 线上问题查找

    2021-02-22 13:55:42
    线上cpu百分之百 top找到耗费cpu高的程序的进程id 利用top-hp命令查看该进程下各个线程的cpu使用情况。并找出消耗cpu高的线程id 将进程id转换为16进制 ... 使用jstack生成所有线程快照文件...内存泄漏 ...
  • 但是增加了这个保存功能后,通过“top”或者“free”命令发现可用内存越来越少,由于太菜就判断为内存泄漏了,各种调试查找原因,发现无论如何都没有遏制住内存的持续减少,个人十分崩溃。 原因以及解决办法见博客...
  • 1. htop简介 Htop是一款运行于Linux系统监控与进程管理软件,用于取代Unix下传统的top。与top只提供最消耗资源的...比如,在查找应用程序的内存泄漏问题时。与top相比,htop提供更方便、光标控制的界面来杀死进程。
  • 所以怀疑是内存泄漏.一, 对症下药 首先, 第一步肯定是先瞅瞅代码, 看看有没有那些资源啥的没关闭, 正如读者所想 ---- 没有发现.二, 通过辅助工具 最简单查看java内存的方法就是分析dump文件. 1&gt; 查找...
  • htop/dstat/ps命令的使用

    2015-12-27 18:16:44
    top概述:top是所有类unix系统的必备工具,能直观方便的查看到系统负载、内存及进程等信息。而htop具有top工具的全部功能且还新增了一些额外的...可以在查找应用程序内存泄漏问题时使用;提供更方便、光标控制的界面...
  • 应用程序找bug

    千次阅读 2012-06-30 16:20:18
    1 描述符泄漏 在程序运行一段时间后 ls -l /proc/pid/fd 查看使用描述符是否...2 内存泄漏 top查看程序使用内存是否一直增加 3 在写socket tcp程序时,当未检测到对方断开链接,还往描述符write,内核会返回sigpipe
  • htop 安装与使用

    2019-04-10 19:28:17
    一、htop简介 >htop是一款运行于Linux系统监控与进程管理软件,用于取代Unix下传统的top。与top只提供最消耗资源的...比如,在查找应用程序的内存泄漏问题时。与top相比,htop提供更方便、光标控制的界面来杀死...
  • 每天实践一点点

    2014-04-27 15:15:57
    以最小的代价换取最大的收益运维实用技巧之Htop详解1. htop简介Htop是一款运行于Linux系统监控与进程管理软件,用于取代Unix下传统的top。与top只提供最消耗资源的进程列表...比如,在查找应用程序的内存泄漏问题时...
  • 线上问题一般有两类:CPU 持续飙高内存泄漏下面分别针对两种问题一步一解决。CPU 持续飙高经验中有两种情况会出现 cpu 飙高,分别是死循环或者频繁 GC解决方案:1.通过 top 命令查看 pidtop2.找到子进程top -H -p ...
  • JVM 问题排查

    2020-12-03 10:54:23
    CPU使用率高 找出使用率高的进程的pid top 找出使用率高的线程tpid top -p pid -H ...查看使用率高的线程当前在干什么 ...// 将线程的tpid转为16进制,到stack.log中查找 ...内存泄漏 执行FullGC后不能
  • 6月1日 ORA-4030和内存泄漏 今日点评 优化小技巧 如何分析ORA-4030 6月2日 优化方案 今日点评 优化小技巧 一个提供参考的 优化方案 优化小技巧 游标的共享 6月3日 拆分大型SQL 优化小技巧 拆分复杂SQL 6月4日 TNS-...
  • 6月1日 ORA-4030和内存泄漏 181 今日点评 184 优化小技巧 如何分析ORA-4030 184 6月2日 优化方案 187 今日点评 188 优化小技巧 一个提供参考的优化方案 189 优化小技巧 游标的共享 190 6月3日 拆分大型...
  • c++ 面试题 总结

    2009-09-16 08:44:40
    没有释放p的空间,造成内存泄漏。 -------------------------------------------------------------------------- 8.下面的代码有什么问题?并请给出正确的写法。 void DoSomeThing(char* p) { char str[16]; ...
  • ExtAspNet_v2.3.2_dll

    2010-09-29 14:37:08
    -MenuButton, LinkButton, Button, LinkButtonField的ConfirmTarget属性由字符串变为枚举类型,可以取三个枚举值Self, Parent, Top。 -Confirm.GetShowReference的最后一个参数target变为枚举类型。 -Alert....
  • -MenuButton, LinkButton, Button, LinkButtonField的ConfirmTarget属性由字符串变为枚举类型,可以取三个枚举值Self, Parent, Top。 -Confirm.GetShowReference的最后一个参数target变为枚举类型。 -Alert....

空空如也

空空如也

1 2
收藏数 26
精华内容 10
关键字:

top查找内存泄漏