zoukankan      html  css  js  c++  java
  • 排除服务器的问题

     

    转载:https://mp.weixin.qq.com/wiki?t=resource/res_main&id=mp1433747358&token=&lang=zh_CN

    下面对查看服务器性能负载的常用工具做简单介绍,详细的工具使用请另行查阅。

    1、查看CPU的性能负载

    a)uptime

    用于观察服务器整体负载,系统负载指运行队列(1分钟、5分钟、15分钟前)的平均长度, 正常情况需要小于cpu个数。

    b)vmstat

    vmstat是Virtual Meomory Statistics(虚拟内存统计)的缩写,可对操作系统的虚拟内存、进程、CPU活动进行监控。他是对系统的整体情况进行统计,通常使用vmstat 5 5(表示每隔5秒生成一次数据,生成五次)命令测试。将得到一个数据汇总他能够反映真正的系统情况。

    c)top top命令是最流行Unix/Linux的性能工具之一。系统管理员可用运行top命令监视进程和Linux整体性能。

    2、查看内存的性能负载

    a)free

    Linux下的free命令,可以用于查看当前系统内存的使用情况,它显示系统中剩余及已用的物理内存和交换内存,以及共享内存和被核心使用的缓冲区。

    3、查看网络的性能负载

    b)netstat

    Netstat是控制台命令,是一个监控TCP/IP网络的非常有用的工具,它可以显示路由表、实际的网络连接以及每一个网络接口设备的状态信息。Netstat用于显示与IP、TCP、UDP和ICMP协议相关的统计数据,一般用于检验本机各端口的网络连接情况。

    c)sar

    sar(System Activity Reporter系统活动情况报告)是目前 Linux 上最为全面的系统性能分析工具之一,可以从多方面对系统的活动进行报告,包括:文件的读写情况、系统调用的使用情况、磁盘I/O、CPU效率、内存使用状况、进程活动及IPC有关的活动等。本文主要以CentOS 6.3 x64系统为例,介绍sar命令。

    4、查看磁盘的性能负载

    a)iostat

    Linux下的iostat命令,可用于报告中央处理器(CPU)统计信息和整个系统、适配器、tty 设备、磁盘和 CD-ROM 的输入/输出统计信息。

    附录3:nginx配置和排查指引

    nginx问题的排查方法

    当出现直接超时、处理返回慢时的报警时,nigix侧的故障排查参考方法有如下: 1、检查请求日志情况, tail -f logs/access.log ,看upstream_status字段。

       200:表示正常;

       502/503/504:表示处理慢,或者后端down机;再看upstream_response_time返回的时间是否真的较慢,有没有上百毫秒,或更高的,有则说明是后端服务有问题。

       404:表示请求的路径不存在或不对,文件不在了。需要检查你配置在公众平台上的url路径是否正确; 服务器上的文件、程序是否存在。

       403:表示无权限访问。 检查一下nginx.conf 是否有特殊的访问配置。

       499: 则是客户端的问题,请联系微信团队。  此错误少见。

    2、检查错误日志情况,tail -f logs/error_log ,查看是否有connect() failed、Connection refused、 Connection reset by peer等error错误日志,有则说明有可能nginx出现的连接数超负载等情况。

       (1)查看系统的网络连接数情况确认是否有较大的链接数

        # netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}' 

        解析: 

       CLOSED //无连接是活动的或正在进行 

       LISTEN //服务器在等待进入呼叫 

       SYN_RECV //一个连接请求已经到达,等待确认 

         SYN_SENT //应用已经开始,打开一个连接 

       ESTABLISHED //正常数据传输状态/当前并发连接数  

       FIN_WAIT1 //应用说它已经完成  

       FIN_WAIT2 //另一边已同意释放  

       ITMED_WAIT //等待所有分组死掉 

       CLOSING //两边同时尝试关闭 

       TIME_WAIT //另一边已初始化一个释放 

       LAST_ACK //等待所有分组死掉

       

       (2)查看系统的句柄配置情况,ulimit -n ,确认是否过小(小于请求数)

       (3)worker_rlimit_nofile、worker_connections配置项,是否过小(小于请求数)

     


     

    为什么Top命令的CPU使用率这么高?但是CPU空闲率也很高?

    最近对我的本本(4核8线程)用top命令看系统状况出现了CPU利用率超过200%的情况,非常诧异,查了下相关资料,把这个问题弄清楚了。
    首先来分析下CPU Load

    load average: 0.09, 0.05, 0.01

    分别是1分钟、5分钟、15分钟的平均Load。
    Load这个东西怎么理解呢,就像一条马路,有N个车道,如果N个进程进入车道,那么正好一人一个,再多一辆车就占不到车道,要等有一个车空出车道。
    在CPU中可以理解为CPU可以并行处理的任务数,那么就是“CPU个数 * 核数”,如果CPU Load = CPU个数 * 核数 那么就是说CPU正好满负载,再多一点,可能就要出问题了,有任务不能被及时分配处理器,那么保证性能的话,最好是小于CPU个数 * 核数 *0.7。

    查看CPU核数可以通过:grep ‘model name’ /proc/cpuinfo

    那么以哪个平均值为准呢?如果1分钟平均出现大于CPU个数 * 核数的情况,还不用担心,如果5分钟平均也是,那就要警惕了,15分钟平均也是这样,就要分析哪里出问题了,防范于未然
    CPU利用率超过100%的问题,也是差不多,top命令应该是把每个核的CPU占用率加起来,算一个和,于是多核情况下会出现超过100%。

    另外Context Switch Rate也是个非常值得注意的值,因为线程间切换的代价也是非常高的。

    引用一个公式:Context Switch Rate = Interrupt Rate + TPS* N

    对于一个多线程的程序,我觉得准备一个控制线程来调度任务是非常必要的,免得线程过于高并发,导致资源的争用和线程切换带来性能问题,最好控制并发的线程数基本等于CPU的总核数,减少这个N,获得更好的处理器性能。


    2.1 使用top命令查看

    数据来自/proc/stat文件

    bubuko.com,布布扣

    %us =(User time + Nice time)/CPU时间*100%

    %sy=(System time + Hardirq time +Softirq time)/ CPU时间*100%

    %id=(Idle time)/CPU时间*100%

    %ni=(Nice time)/CPU时间*100%

    %wa=(Waiting time)/CPU时间*100%

    %hi=(Hardirq time)/CPU时间*100%

    %si=(Softirq time)/CPU时间*100%

    %st=(Steal time)/CPU时间*100%

    备注: top 命令默认情况下,是每 3 秒刷新一次。也可以通过 top -d <刷新时间间隔> 来指定刷新频率,如top -d 0.1 或top -d 0.01 等。top 执行时,也可以按“s ”键,修改时间间隔。


    http://www.bubuko.com/infodetail-506058.html

    http://www.jb51.net/LINUXjishu/323397.html

    单核cpu和多核cpu

    单核cpu的使用率范围为0%-100%,四核cpu的使用率范围为0%-400%.

  • 相关阅读:
    js 各种常用js验证
    js url校验
    最近遇到的技术问题
    a标签的target的四个值
    新系统用到的新知识
    7 天打造前端性能监控系统
    前端必读:浏览器内部工作原理
    怎么判断ThreadPool线程池里的任务都执行完毕
    docker 在window 10 专业版的安装 && .net core 在docker的部署
    .net core 中后台获取前台 数据(post)的方法
  • 原文地址:https://www.cnblogs.com/studyNT/p/5464716.html
Copyright © 2011-2022 走看看