精华内容
下载资源
问答
  • linux 系统负载高 如何检查

    千次阅读 2019-08-29 18:17:03
    Linux的负载高,主要是由于CPU使用、内存使用、IO消耗三部分构成。任意一项使用过多,都将导致服务器负载的急剧攀升。 查看服务器负载有多种命令,w或者uptime都可以直接展示负载, $ uptime 12:20:30 up 44 days...

    负载(load)是linux机器的一个重要指标,直观了反应了机器当前的状态。如果机器负载过高,那么对机器的操作将难以进行。

    Linux的负载高,主要是由于CPU使用、内存使用、IO消耗三部分构成。任意一项使用过多,都将导致服务器负载的急剧攀升。

    查看服务器负载有多种命令,w或者uptime都可以直接展示负载,

    $ uptime
    12:20:30 up 44 days, 21:46,  2 users,  load average: 8.99, 7.55, 5.40
    $ w
    12:22:02 up 44 days, 21:48,  2 users,  load average: 3.96, 6.28, 5.16

    load average分别对应于过去1分钟,5分钟,15分钟的负载平均值。

    什么是Load?什么是Load Average? 

      Load 就是对计算机干活多少的度量(WikiPedia:the system Load is a measure of the amount of work that a compute system is doing)简单的说是进程队列的长度。Load Average 就是一段时间(1分钟、5分钟、15分钟)内平均Load

    如何判断系统是否已经Over Load
      对一般的系统来说,根据cpu数量去判断。如果平均负载始终在1.2以下,而你有2颗cup的机器。那么基本不会出现cpu不够用的情况。也就是Load平均要小于Cpu的数量,一般是会根据15分钟那个load 平均值为首先

    这两个命令只是单纯的反映出负载,linux提供了更为强大,也更为实用的top命令来查看服务器负载。

    $top

    技术分享

    Tasks行展示了目前的进程总数及所处状态,要注意zombie,表示僵尸进程,不为0则表示有进程出现问题。

    Cpu(s)行展示了当前CPU的状态,us表示用户进程占用CPU比例,sy表示内核进程占用CPU比例,id表示空闲CPU百分比,wa表示IO等待所占用的CPU时间的百分比。wa占用超过30%则表示IO压力很大

    Mem行展示了当前内存的状态,total是总的内存大小,userd是已使用的,free是剩余的,buffers是目录缓存。

    Swap行同Mem行,cached表示缓存,用户已打开的文件。如果Swap的used很高,则表示系统内存不足

    在top命令下,按1,则可以展示出服务器有多少CPU,及每个CPU的使用情况

    技术分享

    一般而言,服务器的合理负载是CPU核数*2。也就是说对于8核的CPU,负载在16以内表明机器运行很稳定流畅。如果负载超过16了,就说明服务器的运行有一定的压力了。

    在top命令下,按shift + "c",则将进程按照CPU使用率从大到小排序按shift+"p",则将进程按照内存使用率从大到小排序,很容易能够定位出哪些服务占用了较高的CPU和内存。

    仅仅有top命令是不够的,因为它仅能展示CPU和内存的使用情况,对于负载升高的另一重要原因——IO没有清晰明确的展示。linux提供了iostat命令,可以了解io的开销。

    输入iostat -x 1 10命令,表示开始监控输入输出状态,-x表示显示所有参数信息,1表示每隔1秒监控一次,10表示共监控10次

    技术分享

    其中rsec/s表示读入,wsec/s表示每秒写入,这两个参数某一个特别高的时候就表示磁盘IO有很大压力,util表示IO使用率,如果接近100%,说明IO满负荷运转。 

    查看系统负载vmstat

    $vmstat
    procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
    r b swpd free buff cache si so bi bo in cs us sy id wa st
    0 0 0 689568 121068 1397252 0 0 77 8 110 745 4 1 93 1 0

    r 列表示运行和等待cpu时间片的进程数,如果长期大于1,说明cpu不足,需要增加cpu。 
    b 列表示在等待资源的进程数,比如正在等待I/O、或者内存交换等。 cpu 表示cpu的使用状态 
    us 列显示了用户方式下所花费 CPU 时间的百分比。us的值比较高时,说明用户进程消耗的cpu时间多,但是如果长期大于50%,需要考虑优化用户的程序。 
    sy 列显示了内核进程所花费的cpu时间的百分比。这里us + sy的参考值为80%,如果us+sy 大于 80%说明可能存在CPU不足。 
    wa 列显示了IO等待所占用的CPU时间的百分比。这里wa的参考值为30%,如果wa超过30%,说明IO等待严重,这可能是磁盘大量随机访问造成的,也可能磁盘或者磁盘访问控制器的带宽瓶颈造成的(主要是块操作)。 
    id 列显示了cpu处在空闲状态的时间百分比 system 显示采集间隔内发生的中断数 
    in 列表示在某一时间间隔中观测到的每秒设备中断数。 cs列表示每秒产生的上下文切换次数,如当 cs 比磁盘 I/O 和网络信息包速率高得多,都应进行进一步调查。
    memory 
    swpd 切换到内存交换区的内存数量(k表示)。如果swpd的值不为0,或者比较大,比如超过了100m,只要si、so的值长期为0,系统性能还是正常 
    free 当前的空闲页面列表中内存数量(k表示) buff 作为buffer cache的内存数量,一般对块设备的读写才需要缓冲。 cache: 作为page cache的内存数量,一般作为文件系统的cache,如果cache较大,说明用到cache的文件较多,如果此时IO中bi比较小,说明文件系统效率比较好。 swap 
    si 由内存进入内存交换区数量。 so由内存交换区进入内存数量。 IO 
    bi 从块设备读入数据的总量(读磁盘)(每秒kb)。 bo 块设备写入数据的总量(写磁盘)(每秒kb) 
    这里我们设置的bi+bo参考值为1000,如果超过1000,而且wa值较大应该考虑均衡磁盘负载,可以结合iostat输出来分析

     

    Load误解:
    1:系统load高一定是性能有问题。
        真相:Load高也许是因为在进行cpu密集型的计算
            2:系统Load高一定是CPU能力问题或数量不够。
        真相:Load高只是代表需要运行的队列累计过多了。但队列中的任务实际可能是耗Cpu的,也可能是耗i/0及其他因素的。
    3:系统长期Load高,首先增加CPU
        真相:Load只是表象,不是实质。增加CPU个别情况下会临时看到Load下降,但治标不治本。

    2:在Load average 高的情况下如何鉴别系统瓶颈。
       是CPU不足,还是io不够快造成或是内存不足?

    2.1:查看系统负载vmstat
    Vmstat
    procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
    r b swpd free buff cache si so bi bo in cs us sy id wa
    0 0 100152 2436 97200 289740 0 1 34 45 99 33 0 0 99 0

    procs
    r 列表示运行和等待cpu时间片的进程数,如果长期大于1,说明cpu不足,需要增加cpu。
    b 列表示在等待资源的进程数,比如正在等待I/O、或者内存交换等。
    cpu 表示cpu的使用状态
    us 列显示了用户方式下所花费 CPU 时间的百分比。us的值比较高时,说明用户进程消耗的cpu时间多,但是如果长期大于50%,需要考虑优化用户的程序。
    sy 列显示了内核进程所花费的cpu时间的百分比。这里us + sy的参考值为80%,如果us+sy 大于 80%说明可能存在CPU不足。
    wa 列显示了IO等待所占用的CPU时间的百分比。这里wa的参考值为30%,如果wa超过30%,说明IO等待严重,这可能是磁盘大量随机访问造成的,也可能磁盘或者磁盘访问控制器的带宽瓶颈造成的(主要是块操作)。
    id 列显示了cpu处在空闲状态的时间百分比
    system 显示采集间隔内发生的中断数
    in 列表示在某一时间间隔中观测到的每秒设备中断数。
    cs列表示每秒产生的上下文切换次数,如当 cs 比磁盘 I/O 和网络信息包速率高得多,都应进行进一步调查。
    memory
    swpd 切换到内存交换区的内存数量(k表示)。如果swpd的值不为0,或者比较大,比如超过了100m,只要si、so的值长期为0,系统性能还是正常
    free 当前的空闲页面列表中内存数量(k表示)
    buff 作为buffer cache的内存数量,一般对块设备的读写才需要缓冲。
    cache: 作为page cache的内存数量,一般作为文件系统的cache,如果cache较大,说明用到cache的文件较多,如果此时IO中bi比较小,说明文件系统效率比较好。
    swap
    si 由内存进入内存交换区数量。
    so由内存交换区进入内存数量。
    IO
    bi 从块设备读入数据的总量(读磁盘)(每秒kb)。
    bo 块设备写入数据的总量(写磁盘)(每秒kb)
    这里我们设置的bi+bo参考值为1000,如果超过1000,而且wa值较大应该考虑均衡磁盘负载,可以结合iostat输出来分析。

       2.2:查看磁盘负载iostat
    每隔2秒统计一次磁盘IO信息,直到按Ctrl+C终止程序,-d 选项表示统计磁盘信息, -k 表示以每秒KB的形式显示,-t 要求打印出时间信息,2 表示每隔 2 秒输出一次。第一次输出的磁盘IO负载状况提供了关于自从系统启动以来的统计信息。随后的每一次输出则是每个间隔之间的平均IO负载状况。

    # iostat -x 1 10
    Linux 2.6.18-92.el5xen 02/03/2009
    avg-cpu:   %user %nice %system %iowait   %steal %idle
                1.10 0.00 4.82 39.54 0.07 54.46
    Device:       rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await   svctm   %util
       sda             0.00     3.50   0.40   2.50     5.60 48.00 18.48     0.00 0.97 0.97 0.28
       sdb             0.00     0.00   0.00   0.00     0.00     0.00     0.00     0.00 0.00 0.00 0.00
       sdc             0.00     0.00   0.00   0.00     0.00     0.00     0.00     0.00 0.00 0.00 0.00
       sdd             0.00     0.00   0.00   0.00     0.00     0.00     0.00     0.00 0.00 0.00 0.00
       sde             0.00     0.10   0.30   0.20     2.40     2.40     9.60     0.00 1.60 1.60 0.08
       sdf              17.40     0.50 102.00   0.20 12095.20     5.60 118.40     0.70 6.81 2.09   21.36
       sdg          232.40     1.90 379.70   0.50 76451.20 19.20 201.13     4.94 13.78 2.45   93.16
       rrqm/s: 每秒进行 merge 的读操作数目。即 delta(rmerge)/s
       wrqm/s:   每秒进行 merge 的写操作数目。即 delta(wmerge)/s
       r/s:           每秒完成的读 I/O 设备次数。即 delta(rio)/s
       w/s:       每秒完成的写 I/O 设备次数。即 delta(wio)/s
       rsec/s: 每秒读扇区数。即 delta(rsect)/s
       wsec/s: 每秒写扇区数。即 delta(wsect)/s
       rkB/s:   每秒读K字节数。是 rsect/s 的一半,因为每扇区大小为512字节。(需要计算)
       wkB/s: 每秒写K字节数。是 wsect/s 的一半。(需要计算)
       avgrq-sz: 平均每次设备I/O操作的数据大小 (扇区)。delta(rsect+wsect)/delta(rio+wio)
       avgqu-sz: 平均I/O队列长度。即 delta(aveq)/s/1000 (因为aveq的单位为毫秒)。
       await: 平均每次设备I/O操作的等待时间 (毫秒)。即 delta(ruse+wuse)/delta(rio+wio)
       svctm: 平均每次设备I/O操作的服务时间 (毫秒)。即 delta(use)/delta(rio+wio)
       %util:    一秒中有百分之多少的时间用于 I/O 操作,或者说一秒中有多少时间 I/O 队列是非空的。即 delta(use)/s/1000 (因为use的单位为毫秒)
      
       如果 %util 接近 100%,说明产生的I/O请求太多,I/O系统已经满负荷,该磁盘
       可能存在瓶颈。
       idle小于70% IO压力就较大了,一般读取速度有较多的wait.
      
       同时可以结合vmstat 查看查看b参数(等待资源的进程数)和wa参数(IO等待所占用的CPU时间的百分比,高过30%时IO压力高)
      
       另外还可以参考
       一般:
       svctm < await (因为同时等待的请求的等待时间被重复计算了),
       svctm的大小一般和磁盘性能有关:CPU/内存的负荷也会对其有影响,请求过多也会间接导致 svctm 的增加。
       await: await的大小一般取决于服务时间(svctm) 以及 I/O 队列的长度和 I/O 请求的发出模式。
       如果 svctm 比较接近 await,说明I/O 几乎没有等待时间;
       如果 await 远大于 svctm,说明 I/O队列太长,应用得到的响应时间变慢,
       如果响应时间超过了用户可以容许的范围,这时可以考虑更换更快的磁盘,调整内核 elevator算法,优化应用,或者升级 CPU。
       队列长度(avgqu-sz)也可作为衡量系统 I/O 负荷的指标,但由于 avgqu-sz 是按照单位时间的平均值,所以不能反映瞬间的 I/O 洪水。

    展开全文
  • 为了确保应用的可用性,在做服务器负载均衡时,负载均衡器对服务器做健康检查是必须的。健康检查可以应用到服务器、服务器端口、服务组(Service-group)3个层面,之间是否有关联?应当如何应用?下面就此进行阐述...

    为了确保应用的高可用性,在做服务器负载均衡时,负载均衡器对服务器做健康检查是必须的。健康检查可以应用到服务器、服务器端口、服务组(Service-group)3个层面,之间是否有关联?应当如何应用?下面就此进行阐述。

    首先,我们要理解服务器、服务器端口、服务组的真正概念。服务器和服务器端口的概念很容易理解,服务器定义IP地址,服务器端口定义TCP/UDP端口。服务组这个概念在有些厂商的产品中没有。服务组概念引入后,可以更灵活地让一个服务器端口属于多个服务组,不同服务组可能采取不同的负载均衡策略及健康检查方法。举个例子,个人博客或虚拟主机基本都是很多用户共用一个IP地址。配置如下:

    。。。。。。

    health monitor http-user1 
    method http url GET /user1/index.html

    health monitor http-user2 
    method http url GET /user2/index.html

    slb server s1 10.1.1.1

    port 80 tcp

    slb server s2 10.1.1.2

    port 80 tcp

    slb service-group sg-user1 tcp

    method round-robin

    health-check http-user1

    member s1:80

    member s2:80

    slb service-group sg-user2 tcp

    method least-connection

    health-check http-user2

    member s1:80

    member s2:80

    slb template http tp-http1 
       host-switching starts-with user1 service-group sg-user1 
       host-switching starts-with user2 service-group sg-user2

    slb virtual-server vip1 192.168.1.10

    port 80 http

    template http tp-http1

     

    在上面配置中,user1.blog.com和user2.blog.com域名都指向相同VIP,负载均衡可以根据域名选择不同服务组,也可以根据HOST字段重定向或重写URL为后台真实服务器真正的路径,重定向工作也可由服务器自己处理,这里就不讨论这部分了。

    接下来,我们看看健康检查的配置,

    1. 服务器下缺省使用了ICMP(PING)的检查。

    2. 服务器端口80下使用了缺省的TCP端口检查,TCP 连接能建立就标识端口为UP。

    3. 服务组下缺省没有健康检查,这个例子中分别使用不同的HTTP健康检查。user1检查其文件目录user1下的文件,user2检查其目录文件user2下的文件。

     

    以上3个层面的检查同时运行,千万不要误解服务组下定义的健康检查会覆盖服务器端口下的健康检查。我们可以把UP认为是1,DOWN认为是0。服务器是最低层,然后是服务器端口,最后是服务组内成员。判断任一层面状态,只需用将本层面及以下想与即可。

    1. 服务器Down,意味着一切都Down。

    2. 服务器UP,服务器端口Down,该端口在任一服务组内成员均为Down。

    3. 服务器UP,服务器端口UP,在不同服务组中,由于健康方法不同,该端口成员状态可能UP,也可能Down。如上述例子,user1内容如果丢失,状态即为Down。

     

    在实际应用中,定制健康检查时可以应用到服务组层面,这样做修改健康检查时,可以大大简化配置,尤其是服务器和端口数量很大时。

    个别情况需要注意,针对port 0 tcp(udp),由于端口0是代表所有端口,在服务组下做检查时,一定不能忘记关掉服务器端口(port)下得健康检查,否则port 0为down,其在任何服务组内均为down。

    服务器数量多时,为了降低控制CPU负担,可以关闭低层ICMP检查和服务器端口检查,只应用服务组的健康检查即可。

     

    (R.S.)

    本文转自 virtualadc 51CTO博客,原文链接:http://blog.51cto.com/virtualadc/669420


    展开全文
  • 工欲善其事必先利其器,我说一下思路思路:1、确定高负载的类型 htop,dstat命令看负载高是CPU还是IO2、监控具体的sql语句,是insert update 还是 delete导致高负载3、检查mysql日志4、检查硬件问题dstat可以看到...

    工欲善其事必先利其器,我说一下思路

    思路:

    1、确定高负载的类型 htop,dstat命令看负载高是CPU还是IO

    2、监控具体的sql语句,是insert update 还是 delete导致高负载

    3、检查mysql日志

    4、检查硬件问题

    dstat

    可以看到具体是哪个用户哪个进程占用了相关系统资源,当前CPU、内存谁在使用

    [root@cc ~]# dstat -l -m -r -c --top-io --top-mem --top-cpu

    --io/total- ------memory-usage----- --most-expensive- ----most-expensive---- -most-expensive-

    read writ| used buff cach free| memory process | i/o process | cpu process

    1.90 267 |3399M 178M 3892M 400M|php-fpm: poo 372M|init 1682k 647k|flush-202:0 0.1

    0 72.0 |3399M 178M 3892M 400M|php-fpm: poo 372M|php-fpm: po 10k 143k|php-fpm: pool2.0

    0 8.00 |3399M 178M 3892M 399M|php-fpm: poo 372M|nginx: work 228k 229k|php-fpm: pool0.5

    0 88.0 |3399M 178M 3892M 399M|php-fpm: poo 372M|nginx: work 102k 166k|php-fpm: pool 11

    0 38.0 |3399M 178M 3892M 399M|php-fpm: poo 372M|php-fpm: po 787k 650B|php-fpm: pool4.8

    0 0 |3399M 178M 3892M 399M|php-fpm: poo 372M|php-fpm: po 788k 723B|php-fpm: pool1.8

    0 140 |3400M 178M 3892M 399M|php-fpm: poo 372M|nginx: work 38k 154k|php-fpm: pool1.2

    0 12.0 |3400M 178M 3892M 399M|php-fpm: poo 372M|nginx: work 178k 364k|php-fpm: pool1.5

    0 0 |3400M 178M 3892M 399M|php-fpm: poo 372M|nginx: work 758k 639k|php-fpm: pool1.5

    0 12.0 |3400M 178M 3892M 399M|php-fpm: poo 372M|nginx: work 773k 616k|php-fpm: pool2.0

    6.00 0 |3401M 178M 3892M 398M|php-fpm: poo 372M|nginx: work 994k 688k|nginx: worker1.5

    0 272 |3401M 178M 3892M 398M|php-fpm: poo 372M|nginx: work 388k 422k|php-fpm: pool1.5

    0 0 |3400M 178M 3893M 398M|php-fpm: poo 372M|nginx: work 483k 548k|php-fpm: pool1.8

    0 4.00 |3400M 178M 3893M 398M|php-fpm: poo 372M|php-fpm: po 787k 650B|php-fpm: pool1.5

    0 12.0 |3400M 178M 3893M 398M|php-fpm: poo 372M|nginx: work 223k 323k|php-fpm: pool1.5

    0 0 |3400M 178M 3893M 398M|php-fpm: poo 372M|nginx: work 371k 474k|php-fpm: pool7.8

    htop

    htop是top的增强版,更直观

    [root@cc ~]# htop

    1 [||||||||||| 12.4%]

    2 [||||||||| 9.5%]

    3 [| 1.0%]

    4 [|| 1.9%]

    Mem[|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||3394/7869MB]

    Swp[|||||||||||||| 75/478MB]

    Tasks: 71, 12 thr; 2 running

    Load average: 0.39 0.39 0.31

    Uptime: 526 days(!), 17:36:38

    PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command

    1 root 20 0 19232 396 248 S 0.0 0.0 0:01.86 /sbin/init

    30752 root 20 0 52532 72 56 S 0.0 0.0 0:00.16 ├─ /usr/sbin/vsftpd /etc/vsftpd/vsftpd.conf

    24301 root 20 0 193M 3268 1600 S 0.0 0.0 1:41.43 ├─ /usr/sbin/snmpd -LS0-6d -Lf /dev/null -p /var/run/snmpd.pid

    21361 root 20 0 902M 6500 1308 S 0.0 0.1 0:07.16 ├─ php-fpm: master process (/etc/php-fpm.conf)

    28627 www 20 0 962M 202M 138M S 0.0 2.6 0:34.46 │ ├─ php-fpm: pool www-c

    27537 www 20 0 965M 236M 171M R 1.4 3.0 1:19.64 │ ├─ php-fpm: pool www-c

    27449 www 20 0 961M 251M 189M S 0.0 3.2 1:35.54 │ ├─ php-fpm: pool www-a

    26442 www 20 0 962M 280M 217M S 0.0 3.6 2:29.71 │ ├─ php-fpm: pool www-a

    26310 www 20 0 917M 251M 234M S 1.9 3.2 2:46.45 │ ├─ php-fpm: pool www-a

    26162 www 20 0 962M 297M 233M S 0.0 3.8 2:37.50 │ ├─ php-fpm: pool www-b

    26147 www 20 0 924M 258M 233M S 0.0 3.3 2:38.37 │ ├─ php-fpm: pool www-c

    25717 www 20 0 965M 302M 238M S 0.0 3.8 2:54.50 │ ├─ php-fpm: pool www-c

    24585 www 20 0 964M 324M 260M S 0.0 4.1 4:15.20 │ ├─ php-fpm: pool www-b

    tcpdump

    抓取mysql包分析,一般抓3306端口的数据

    [root@cc ~]# tcpdump -i eth0 -A -s 3000 port 3306 > ~/sql.log

    然后使用awk,sort,wc 等命令进行分析

    或者

    [root@cc ~]# tcpdump -i eth0 -s 0 -l -w - dst port 3306 | strings | perl -e '

    while(<>) { chomp; next if /^[^ ]+[ ]*$/;

    if(/^(SELECT|UPDATE|DELETE|INSERT|SET|COMMIT|ROLLBACK|CREATE|DROP|ALTER)/i) {

    if (defined $q) { print "$qn"; }

    $q=$_;

    } else {

    $_ =~ s/^[ t]+//; $q.=" $_";

    }

    }'

    就可以看出最繁忙的sql语句了

    strace

    查看系统调用是否有问题,进程是否堵塞,是否有Broken pipe

    [root@cc ~]# strace -p 26578

    pt-query-digest

    分析mysql慢日志,查看哪些sql语句最耗时

    [root@cc ~]# pt-query-digest slow.logs

    # 390ms USER TIME, 10ms system TIME, 15.67M rss, 105.84M vsz

    # CURRENT DATE: Thu DEC 29 13:22:42 2014

    # Hostname: test

    # Files: slow.log

    # Overall: 776 total, 11 UNIQUE, 0.00 QPS, 0.00x concurrency _____________

    # TIME range: 2011-09-10 04:03:19 TO 2011-12-29 05:02:51

    # Attribute total MIN MAX avg 95% stddev median

    # ============ ======= ======= ======= ======= ======= ======= =======

    # EXEC TIME 5657s 2s 33s 7s 23s 6s 5s

    # LOCK TIME 33s 0 19s 43ms 98us 715ms 38us

    # ROWS sent 323.38k 0 107.36k 426.73 0.99 6.35k 0

    # ROWS examine 323.39k 0 107.36k 426.74 0 6.35k 0

    # Query SIZE 217.95k 38 562 287.61 420.77 81.78 284.79

    show processlist

    查看系统到底在干什么

    mysql> show full processlist;

    +-----------+---------------+---------------------+---------------------+---------+------+---------------+---------------------------+

    | Id | User | Host | db | Command | Time | State | Info |

    +-----------+---------------+---------------------+---------------------+---------+------+---------------+---------------------------+

    | 184498848 | testdb_rr1356 | 10.11.211.120:61343 | testdb_rr1356_db121 | Sleep | 1384 | | NULL |

    | 184508740 | testdb_rr1356 | 10.11.211.120:11809 | testdb_rr1356_db121 | Sleep | 87 | | NULL |

    | 184509415 | testdb_rr1356 | 10.11.211.120:12760 | testdb_rr1356_db121 | Query | 0 | NULL | show full processlist |

    | 184509451 | testdb_rr1356 | 10.11.211.120:12804 | testdb_rr1356_db121 | Sleep | 10 | | NULL |

    | 184509528 | testdb_rr1356 | 10.11.211.120:12919 | testdb_rr1356_db121 | Query | 0 | freeing items | DESCRIBE test_channel |

    检查mysql配置参数是否有问题,引起大量的IO或者高CPU操作

    innodb_flush_log_at_trx_commit 、innodb_buffer_pool_size 、key_buffer_size 等重要参数

    mysql> show variables like '%innodb%';

    +---------------------------------+----------------------------+

    | Variable_name | Value |

    +---------------------------------+----------------------------+

    | have_innodb | YES |

    | ignore_builtin_innodb | ON |

    | innodb_adaptive_flushing | ON |

    | innodb_adaptive_hash_index | ON |

    | innodb_additional_mem_pool_size | 2097152 |

    | innodb_autoextend_increment | 8 |

    | innodb_autoinc_lock_mode | 1 |

    | innodb_buffer_pool_size | 2013265920 |

    | innodb_change_buffering | inserts |

    | innodb_checksums | ON |

    通过show engine innodb status查看当前事务,内存使用

    mysql> show engine innodb status \G

    LATEST DETECTED DEADLOCK

    ------------------------

    150731 10:36:50

    *** (1) TRANSACTION:

    TRANSACTION EBFBBEC, ACTIVE 0 sec, process no 20691, OS thread id 47345217033984 inserting

    mysql tables in use 1, locked 1

    LOCK WAIT 5 lock struct(s), heap size 1248, 4 row lock(s), undo log entries 2

    MySQL thread id 143249904, query id 1286731854 10.135.21.120 tybuser2014 update

    #此处具体sql省略

    ----------------------

    BUFFER POOL AND MEMORY

    ----------------------

    Total memory allocated 2058485760; in additional pool allocated 0

    Dictionary memory allocated 819282

    Buffer pool size 122879

    Free buffers 97599

    Database pages 24313

    Old database pages 8954

    Modified db pages 7

    Pending reads 0

    Pending writes: LRU 0, flush list 0, single page 0

    Pages made young 6, not young 0

    0.00 youngs/s, 0.00 non-youngs/s

    Pages read 1049, created 41853, written 30401604

    0.00 reads/s, 0.00 creates/s, 1.75 writes/s

    Buffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 0 / 1000

    Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s

    LRU len: 24313, unzip_LRU len: 0

    I/O sum[45]:cur[0], unzip sum[0]:cur[0]

    最后通过zabbix或者cacti等监控来查看IO、CPU、MEMORY、磁盘等是否有异常

    这样基本上就可以把问题找出来了

    仅供参考,当然,不同的DBA肯定还有其他更好的方式

    展开全文
  • 服务器CPU高检查路径

    2019-09-18 13:42:13
    top -c 显示系统资源使用情况 输入大写 P 将应用按照 CPU...top -Hp pid 然后输入 P 查看负载高的进程中的线程资源排序 jstack pid >stack.log 查看进程堆栈日志,16进制转换找到线程 通过 jstat -gcutil pid 200...
    • top -c 显示系统资源使用情况
    • 输入大写 P 将应用按照 CPU 使用率排序
    • top -Hp pid 然后输入 P 查看负载高的进程中的线程资源排序
    • jstack pid >stack.log 查看进程堆栈日志,16进制转换找到线程
    • 通过 jstat -gcutil pid 200 100 将内存使用、gc 回收状况打印出来(每隔 200ms 打印 100次)

    转载于:https://my.oschina.net/jsycwangwei/blog/3072412

    展开全文
  • 技术支持分析师们常常接到用户对服务器高负载的...下列项目的过度使用会直接导致高负载问题:CPU内存(包括虚拟内存)磁盘I/O该如何检查这些项目?这取决于大家是要审查当前资源使用情况还是历史资源使用情况。当然,...
  • 今天例行top检查服务器的时候,忽然发现负载竟然到了30多!我勒个去啊! 进程16319的cpu负载到了198.3%,出现这么负载很有可能有死循环! jstack打印堆栈,里面有大量的这样的线程在RUNNABLE: ...
  • 负载均衡可由软件和硬件来实现,一般在中小型企业,他们采用的是软件,硬件的稍微贵一些,并且中小型企业一般也用不到太多,如果选择硬件会浪费,一般只有大型的企业由可能需要使用硬件构成的负载均衡。 负载均衡...
  • 【2013年7月11日 51CTO外电头条】技术支持分析师们常常接到用户对服务器高负载的控诉。事实上cPanel软件及其安装的...下列项目的过度使用会直接导致高负载问题:CPU内存(包括虚拟内存)磁盘I/O该如何检查这些项目...
  • Oracle服务器系统负载的处理

    千次阅读 2014-05-01 17:01:31
    1.检查系统 top命令显示系统 load averages: 99.90, 117.54, 125.71 观察cpu使用率不。 iowait ! 2.检查进程数量 ps -ef|grep oracle|wc -l 显示进程数量大概在150左右3.检查数据库 查询v$session_wait...
  • 这篇论坛文章(赛迪网技术社区)主要介绍了配置一个可用性的MySQL服务器负载均衡群集的具体过程,详细内容请参考下文: 本文将告诉你如何配置一个三个节点的MySQL 5数据库服务器群集:两个存储节点和一个 管理...
  • nginx系列友情链接:nginx性能WEB服务器系列之一简介及安装https://www.cnblogs.com/maxtgood/p/9597596.htmlnginx性能WEB服务器系列之二命令管理https://www.cnblogs.com/maxtgood/p/9597990.htmlnginx性能WEB...
  • Mysql 高负载排查思路Mysql高负载排查思路发现问题top命令查看服务器负载,发现mysql竟然百分之两百的cpu,引起Mysql负载这么高的原因,估计是索引问题和某些变态SQL语句.排查思路1.确定高负载的类型,top命令看负载高是...
  • 调度器具有很好的吞吐率,将请求均衡地转移到不同的服务器上执行,且调度器自动屏蔽掉服务器的故障,从而将一组服务器构成一个性能的、可用的虚拟服务器。整个服务器集群的结构对客户是透明的,而且无需修改...
  • 本文将告诉你如何配置一个三个节点的MySQL 5数据库服务器群集:两个存储节点和一个 管理节点。这个群集是由用提供“heartbeat心跳”(用来检查...一个可用性负载均衡器。 本文我们的每个节点使用Debian Sarge Lin...
  • 本文将告诉你如何配置一个三个节点的MySQL5数据库服务器群集:两个存储节点和一个 管理节点。这个群集是由用提供...一个可用性负载均衡器。 本文我们的每个节点使用DebianSargeLinux系统。其它Linux发行版本的...
  • Linux的负载高,主要是由于CPU使用、内存使用、IO消耗三部分构成,任意一个使用过多度会导致服务器整体的卡顿。本文为大家列举了具体检查负载过程中,常用到的命令:1、uptime命令系统当前时间 11:35:14up 235 days,...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 611
精华内容 244
关键字:

服务器负载高检查