• free vmstat查看内存及系统调优【转】


    内存查看

    查看内存是否存在瓶颈,使用top指令看比较麻烦,而free命令更为直观:

    [/home/weber#]free
                 total       used       free     shared    buffers     cached
    Mem:        501820     452028      49792      37064       5056     136732
    -/+ buffers/cache:     310240     191580
    Swap:            0          0          0
    [/home/weber#]top
    top - 17:52:17 up 42 days,  7:10,  1 user,  load average: 0.02, 0.02, 0.05
    Tasks:  80 total,   1 running,  79 sleeping,   0 stopped,   0 zombie
    %Cpu(s):  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
    KiB Mem:    501820 total,   452548 used,    49272 free,     5144 buffers
    KiB Swap:        0 total,        0 used,        0 free.   136988 cached Mem

    top工具显示了free工具的第一行所有信息,但真实可用的内存,还需要自己计算才知道; 系统实际可用的内存为free工具输出第二行的free+buffer+cached;也就是第三行的free值191580;关于free命令各个值的详情解读,请参考这篇文章 free 查询可用内存 ;

    性能优化的核心是找出系统的瓶颈点,问题找到了,优化的工作也就完成了大半; 这里介绍的性能优化主要从两个层面来介绍:系统层面和程序层面;

    3.1. 分析系统瓶颈

    系统响应变慢,首先得定位大致的问题出在哪里,是IO瓶颈、CPU瓶颈、内存瓶颈还是程序导致的系统问题;

    使用top工具能够比较全面的查看我们关注的点:

    $top
        top - 09:14:56 up 264 days, 20:56,  1 user,  load average: 0.02, 0.04, 0.00
        Tasks:  87 total,   1 running,  86 sleeping,   0 stopped,   0 zombie
        Cpu(s):  0.0%us,  0.2%sy,  0.0%ni, 99.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.2%st
        Mem:    377672k total,   322332k used,    55340k free,    32592k buffers
        Swap:   397308k total,    67192k used,   330116k free,    71900k cached
        PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
        1 root      20   0  2856  656  388 S  0.0  0.2   0:49.40 init
        2 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kthreadd
        3 root      20   0     0    0    0 S  0.0  0.0   7:15.20 ksoftirqd/0
        4 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 migration/
    进入交互模式后:
    • 输入M,进程列表按内存使用大小降序排序,便于我们观察最大内存使用者使用有问题(检测内存泄漏问题);
    • 输入P,进程列表按CPU使用大小降序排序,便于我们观察最耗CPU资源的使用者是否有问题;
    top第三行显示当前系统的,其中有两个值很关键:
    • %id:空闲CPU时间百分比,如果这个值过低,表明系统CPU存在瓶颈;
    • %wa:等待I/O的CPU时间百分比,如果这个值过高,表明IO存在瓶颈;

    3.2. 分析内存瓶颈

    查看内存是否存在瓶颈,使用top指令看比较麻烦,而free命令更为直观:

    [/home/weber#]free
                 total       used       free     shared    buffers     cached
    Mem:        501820     452028      49792      37064       5056     136732
    -/+ buffers/cache:     310240     191580
    Swap:            0          0          0
    [/home/weber#]top
    top - 17:52:17 up 42 days,  7:10,  1 user,  load average: 0.02, 0.02, 0.05
    Tasks:  80 total,   1 running,  79 sleeping,   0 stopped,   0 zombie
    %Cpu(s):  0.0 us,  0.0 sy,  0.0 ni,100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
    KiB Mem:    501820 total,   452548 used,    49272 free,     5144 buffers
    KiB Swap:        0 total,        0 used,        0 free.   136988 cached Mem

    top工具显示了free工具的第一行所有信息,但真实可用的内存,还需要自己计算才知道; 系统实际可用的内存为free工具输出第二行的free+buffer+cached;也就是第三行的free值191580;关于free命令各个值的详情解读,请参考这篇文章 free 查询可用内存 ;

    如果是因为缺少内存,系统响应变慢很明显,因为这使得系统不停的做换入换出的工作;

    进一步的监视内存使用情况,可使用vmstat工具,实时动态监视操作系统的内存和虚拟内存的动态变化。 参考: vmstat 监视内存使用情况 ;

    3.3. 分析IO瓶颈

    如果IO存在性能瓶颈,top工具中的%wa会偏高;

    进一步分析使用iostat工具:

    /root$iostat -d -x -k 1 1
    Linux 2.6.32-279.el6.x86_64 (colin)   07/16/2014      _x86_64_        (4 CPU)
    
    Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
    sda               0.02     7.25    0.04    1.90     0.74    35.47    37.15     0.04   19.13   5.58   1.09
    dm-0              0.00     0.00    0.04    3.05     0.28    12.18     8.07     0.65  209.01   1.11   0.34
    dm-1              0.00     0.00    0.02    5.82     0.46    23.26     8.13     0.43   74.33   1.30   0.76
    dm-2              0.00     0.00    0.00    0.01     0.00     0.02     8.00     0.00    5.41   3.28   0.00
    • 如果%iowait的值过高,表示硬盘存在I/O瓶颈。
    • 如果 %util 接近 100%,说明产生的I/O请求太多,I/O系统已经满负荷,该磁盘可能存在瓶颈。
    • 如果 svctm 比较接近 await,说明 I/O 几乎没有等待时间;
    • 如果 await 远大于 svctm,说明I/O 队列太长,io响应太慢,则需要进行必要优化。
    • 如果avgqu-sz比较大,也表示有大量io在等待。

    更多参数说明请参考 iostat 监视I/O子系统 ;

    3.4. 分析进程调用

    通过top等工具发现系统性能问题是由某个进程导致的之后,接下来我们就需要分析这个进程;继续 查询问题在哪;

    这里我们有两个好用的工具: pstack和pstrace

    pstack用来跟踪进程栈,这个命令在排查进程问题时非常有用,比如我们发现一个服务一直处于work状态(如假死状态,好似死循环),使用这个命令就能轻松定位问题所在;可以在一段时间内,多执行几次pstack,若发现代码栈总是停在同一个位置,那个位置就需要重点关注,很可能就是出问题的地方;

    示例:查看bash程序进程栈:

    /root$iostat -d -x -k 1 1
    Linux 2.6.32-279.el6.x86_64 (colin)   07/16/2014      _x86_64_        (4 CPU)
    
    Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
    sda               0.02     7.25    0.04    1.90     0.74    35.47    37.15     0.04   19.13   5.58   1.09
    dm-0              0.00     0.00    0.04    3.05     0.28    12.18     8.07     0.65  209.01   1.11   0.34
    dm-1              0.00     0.00    0.02    5.82     0.46    23.26     8.13     0.43   74.33   1.30   0.76
    dm-2              0.00     0.00    0.00    0.01     0.00     0.02     8.00     0.00    5.41   3.28   0.00

    而strace用来跟踪进程中的系统调用;这个工具能够动态的跟踪进程执行时的系统调用和所接收的信号。是一个非常有效的检测、指导和调试工具。系统管理员可以通过该命令容易地解决程序问题。

    参考: strace 跟踪进程中的系统调用 ;

    如果是因为缺少内存,系统响应变慢很明显,因为这使得系统不停的做换入换出的工作;

    进一步的监视内存使用情况,可使用vmstat工具,实时动态监视操作系统的内存和虚拟内存的动态变化

    转自

    3. 性能优化 — Linux Tools Quick Tutorial
    http://linuxtools-rst.readthedocs.io/zh_CN/latest/advance/03_optimization.html#gprof

  • 相关阅读:
    『设计模式』再谈麦当劳的点单模式--命令模式(Command)
    『设计模式』备忘录模式(memento)下象棋,我就想悔棋怎么办
    『设计模式』职责链模式(Chain of Responsibility) 可怜的加薪、请假之路
    『设计模式』状态模式(不起花里胡哨的名字了)
    『设计模式』外观模式--这篇博客也太明了吧
    『设计模式』电话接线员与中介者模式
    『安卓』安卓开发基础--基本控件
    『设计模式』再谈Macdonald的汉堡口味--策略模式
    hive启动报错:Exception in thread "main" java.lang.NoSuchMethodError: com.google.common.base.Preconditions.checkArgumen
    hive安装报错:Class path contains multiple SLF4J bindings
  • 原文地址:https://www.cnblogs.com/paul8339/p/6719523.html
Copyright © 2020-2023  润新知