服务器性能优化

时间 2019-12-11

原文原文链接

1.度量性能php

持续地对性能进行度量在两个方面有帮助。首先，度量能够帮助了解性能趋势，包括好坏两方面的趋势。做为一个简单的方法，查看一下 Web 服务器上的中央处理单元（CPU）使用率，就能够了解 CPU 是否负载太重。一样，查看过去使用的总带宽并推断将来的变化，能够帮助判断何时须要进行网络升级。这些度量最好与其余度量和观测结合考虑。例如，当用户抱怨应用程序太慢时，能够检查磁盘操做是否达到了最大容量。html

性能度量的第二个用途是，判断调优是对系统性能有帮助，仍是使它更糟糕了。方法是比较修改以前和以后的度量结果。可是，为了进行有效的比较，每次应该只修改一个设置，而后对适当的指标进行比较以判断修改的效果。每次只修改一个设置的缘由应该是很明显的：同时作出的两个修改极可能会相互影响。选择用来进行比较的指标比较微妙。mysql

选择的指标必须可以反映应用程序用户感受到的响应。若是一项修改的目标是减小数据库的内存占用量，那么取消各类缓冲区确定会有帮助，可是这会牺牲查询速度和应用程序性能。因此，应该选择应用程序响应时间这样的指标，这会使调优向着正确的方向发展，而不只仅是针对数据库内存使用量。linux

(1).能够以许多方式度量应用程序响应时间。最简单的方法多是使用 curl 命令.web

1.使用curl度量 fix.weirenmai.dragon-stone.cn的响应时间redis

[root@web ~]# curl -o /dev/null -s -w %{time_connect}:%{time_starttransfer}:%{time_total} http://www.baidu.com算法

0.004:0.882:1.393sql

对 www.baidu.com执行curl命令，输出一般是html代码,经过 -o参数将html代码发送到/dev/null。-s去除掉全部的状态信息,-w参数是让curl列出计时器的状态信息:shell

curl使用的计时器:数据库

time_connect	创建到服务器的 TCP 链接所用的时间 (0.004)
time_starttransfer	在发出请求以后，Web 服务器返回数据的第一个字节所用的时间 (0.882)
time_total	完成请求所用的时间 (1.393)

服务器创建tcp链接所用时间： 0.004s.

web服务器处理请求并开始返回数据所用的时间 : 0.882 - 0.004 = 0.878s.

客户端从服务器下载数据所用的时间是： 1.393 - 0.882 = 0.511s.

经过观察curl数据及其随时间变化的趋势，能够很好的了解网站对用户响应性.

(2).能够经过uptime了解系统负载状况

[root@web ~]# uptime

11:11:39 up 67 days, 1:30, 9 users, load average: 4.41, 4.40, 3.22

load average后的3个数字，分别表明系统最近一分钟,五分钟,十五分钟的系统负载.

(3).使用sar监控系统(sar 主要负责收集，汇报与存储系统运行信息)

1)经过sar -u输出cpu使用状况:

[root@web ~]# sar -u 1 3

Linux 2.6.32-220.el6.x86_64 (web.youlu.com.cn) 2013年02月18日 _x86_64_ (4 CPU)

11时38分59秒 CPU %user %nice %system %iowait %steal %idle

11时39分00秒 all 88.31 0.00 8.71 0.00 0.00 2.99

11时39分01秒 all 90.75 0.00 7.50 1.25 0.00 0.50

11时39分02秒 all 80.75 0.00 19.25 0.00 0.00 0.00

平均时间: all 86.61 0.00 11.81 0.42 0.00 1.16

%user：在用户模式中运行进程所花的时间比。
%nice : 运行正常进程所花的时间
%system：在内核模式（系统）中运行进程所花的时间。
%iowait：没有进程在该CPU上执行时，处理器等待I/O完成的时间
%idle：没有进程在该CPU上执行的时间

1. 若 %iowait 的值太高，表示硬盘存在I/O瓶颈

2. 若 %idle 的值高但系统响应慢时，有多是 CPU 等待分配内存，此时应加大内存容量

3. 若 %idle 的值持续低于1，则系统的 CPU 处理能力相对较低，代表系统中最须要解决的资源是 CPU 。

2)经过sar -d 查看硬盘活动：

sar -d 10 3

Linux 2.6.32-220.el6.x86_64 (web.youlu.com.cn) 2013年02月18日 _x86_64_ (4 CPU)

11时55分16秒 DEV tps rd_sec/s wr_sec/s avgrq-sz avgqu-sz await svctm %util

11时55分26秒 dev8-0 3.30 0.00 69.67 21.09 0.02 7.09 6.55 2.16

11时55分26秒 dev8-16 3.20 0.00 69.67 21.75 0.02 6.69 6.16 1.97

11时55分26秒 dev8-32 16.32 108.91 146.55 15.66 0.09 5.48 3.50 5.72

11时55分26秒 dev8-48 15.42 8.81 146.55 10.08 0.07 4.86 3.03 4.66

tps : 每秒从物理磁盘I/O的次数.多个逻辑请求会被合并为一个I/O磁盘请求,一次传输的大小是不肯定的
rd_sec/s : 每秒读扇区的次数
wr_sec/s: 每秒写扇区的次数
avgrq-sz: 平均每次设备I/O操做的数据大小(扇区).
avgqu-sz: 磁盘请求队列的平均长度
await: 从请求磁盘操做到系统完成处理,每次请求的平均消耗时间,包括请求队列等待时间,单位是毫秒(1秒=1000毫秒)
svctm: 系统处理每次请求的平均时间,不包括在请求队列中消耗的时间
%util: I/O请求占CPU的百分比,比率越大,说明越饱和

1. avgqu-sz 的值较低时，设备的利用率较高。

2.当%util的值接近 1% 时，表示设备带宽已经占满

3) 要判断系统瓶颈问题，有时需几个 sar 命令选项结合起来

1.怀疑CPU存在瓶颈，可用 sar -u 和 sar -q 等来查看

2.怀疑内存存在瓶颈，可用 sar -B、sar -r 和 sar -W 等来查看

3.怀疑I/O存在瓶颈，可用 sar -b、sar -u 和 sar -d 等来查看

(4) 使用top查看cpu,内存使用状况:

Tasks: 219 total, 2 running, 217 sleeping, 0 stopped, 0 zombie

Cpu(s): 8.4%us, 0.8%sy, 0.0%ni, 90.3%id, 0.2%wa, 0.0%hi, 0.2%si, 0.0%st

Mem: 3853728k total, 3415984k used, 437744k free, 197692k buffers

Swap: 8388600k total, 350820k used, 8037780k free, 799716k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

7605 root 20 0 212m 9352 3772 S 4.3 0.2 0:00.13 svn

12004 root 20 0 305m 9756 3216 S 1.3 0.3 27:26.98 php

9720 xufengqi 20 0 299m 13m 6440 S 1.0 0.4 1:16.80 php

12667 root 20 0 806m 9452 888 S 0.7 0.2 62:12.83 opportunity_rec

22854 root 20 0 147m 67m 664 S 0.7 1.8 194:47.15 redis-server

24161 mysql 20 0 2188m 45m 4172 S 0.7 1.2 295:30.25 mysqld

8744 zhusheng 20 0 340m 6392 2540 S 0.3 0.2 57:03.99 recommend_compa

1.输入P查看系统cpu使用状况.

2.输入M查看系统内存使用状况.

2. linux系统调优

大多数 Linux 发布版都定义了适当的缓冲区和其余 Transmission Control Protocol（TCP）参数。能够修改这些参数来分配更多的内存，从而改进网络性能。设置内核参数的方法是经过 proc 接口，也就是经过读写 /proc 中的值。幸运的是，sysctl 能够读取/etc/sysctl.conf 中的值并根据须要填充 /proc，这样就可以更轻松地管理这些参数.

1).添加/etc/sysctl.conf中的参数

# Use TCP syncookies when needed

net.ipv4.tcp_syncookies = 1

# Enable TCP window scaling

net.ipv4.tcp_window_scaling: = 1

# Increase TCP max buffer size

net.core.rmem_max = 16777216

net.core.wmem_max = 16777216

# Increase Linux autotuning TCP buffer limits

net.ipv4.tcp_rmem = 4096 87380 16777216

net.ipv4.tcp_wmem = 4096 65536 16777216

# Increase number of ports available

net.ipv4.ip_local_port_range = 1024 65000

将这些设置添加到 /etc/sysctl.conf 的现有内容中。

第一个设置启用 TCP SYN cookie。当从客户机发来新的 TCP 链接时，数据包设置了 SYN 位，服务器就为这个半开的链接建立一个条目，并用一个 SYN-ACK 数据包进行响应。在正常操做中，远程客户机用一个 ACK 数据包进行响应，这会使半开的链接转换为全开的。有一种称为 SYN 泛滥的网络攻击，它使 ACK 数据包没法返回，致使服务器用光内存空间，没法处理到来的链接。SYN cookie 特性能够识别出这种状况，并使用一种优雅的方法保留队列中的空间。大多数系统都默认启用这个特性，可是确保配置这个特性更可靠。

第二个设置是启用tcp窗口伸缩使客户机可以以更高的速度下载数据。tcp容许在未从远程端收到确认的状况下发送多个数据包,默认设置最多使64k,在与延迟比较大的远程机进行通信时这个设置是不够。窗口伸缩会在头中启用更多的位，从而增长窗口大小

后面4个配置项是增长tcp发送和接收缓存区。这使得运用程序能够更快丢掉它的数据,从而为另外一个请求服务.还能够强化远程客户机在服务器繁忙时发送数据的能力。

最后一个配置是增长可用的本地端口数量,这样就增长了能够同时服务的最大链接数量. 运行 sysctl -p /etc/sysctl.conf ，这样设置就会生效

2)磁盘调优

磁盘在 LAMP 架构中扮演着重要的角色。静态文件、模板和代码都来自磁盘，组成数据库的数据表和索引也来自磁盘。对磁盘的许多调优（尤为是对于数据库）集中于避免磁盘访问，由于磁盘访问的延迟至关高.

首先要在文件系统上禁用atime日志记录特性. atime是最近访问文件的时间,每当访问文件时,底层文件系统必须记录这个时间戳。由于咱们不多使用atime，禁用它能够减小磁盘的访问时间. 禁用该特性的方法是，在/etc/fstab的第四列中添加noatime。

如何启用 noatime 的 fstab 示例

/dev/mapper/VolGroup-lv_root / ext4 defaults,noatime 1 1

UUID=ba007d22-b42b-4b1e-9301-eec5535dffe1 /boot ext4 defaults,noatime 1 2

/dev/mapper/VolGroup-LogVol02 /opt ext4 defaults,noatime 1 2

/dev/mapper/VolGroup-lv_swap swap swap defaults 0 0

tmpfs /dev/shm tmpfs defaults 0 0

devpts /dev/pts devpts gid=5,mode=620 0 0

sysfs /sys sysfs defaults 0 0

proc /proc proc defaults 0 0

上述修改了 ext4 文件系统，由于 noatime 只对驻留在磁盘上的文件系统有帮助。为让这一修改生效，不须要从新引导；只需从新挂装每一个文件系统, 运行 mount / -o remount。

可使用 hdparm 命令查明和设置用来访问 IDE 磁盘的方法。hdparm -t /path/to/device 执行速度测试，能够将这个测试结果做为性能基准。为了使结果尽量准确，在运行这个命令时系统应该是空闲的.

在/dev/sda 上执行的速度测试

# hdparm -t /dev/sda

/dev/sda:

Timing buffered disk reads: 290 MB in 3.18 seconds = 91.27 MB/sec

这一测试说明，在这个磁盘上读取数据的速度是大约每秒 91.27 MB。

3) I/O调优

在/etc/grub.conf中加入相应的I/O调度算法.

I/O调度算法总共有4种.

1.deadline算法（适合小文件读写，跳跃式读写,零散读写，适合吞吐量很是大的运用）（数据库）

2. anticipatory算法（适合大文件读写，整块式，重复读写) (web server)

3. cfg算法（彻底公平算法)

4. noop算法 (没有算法)

将I/o调度算法改成deadline算法.

echo deadline > /sys/block/sda/queue/scheduler

4)将访问数超过150的ip加上防火墙

#!/bin/sh

status=`netstat -na|awk '5 ~ /[0-9]+:[0-9]+/ {print5}' |awk -F ":" -- '{print #1}' |sort -n|uniq -c |sort -n|tail -n 1`

NUM=`echo status|awk '{print1}'`

IP=`echo status|awk '{print2}'`

result=`echo "#NUM > 150" | bc`

if [ #result = 1 ]

then

echo IP:IPisoverIPisoverNUM, BAN IT!

/sbin/iptables -I INPUT -s #IP -j DROP

将该shell脚本加入crontab中，5秒运行一次.

5)查看apache的并发请求数及其tcp链接状态:

[root@weirenmai-dev ~]#netstat -nat|awk '{print $NF}'|sort|uniq -c|sort -n

1 established

1 State

3 LAST_ACK

4 FIN_WAIT2

11 SYN_SENT

14 LISTEN

19 CLOSE_WAIT

43 FIN_WAIT1

244 SYN_RECV

696 TIME_WAIT

1126 ESTABLISHED

上述参数的描述:

SYN_RECV : 表示正在等待处理的请求数.

ESTABLISHED : 表示正常数据传输状态

TIME_WAIT : 表示处理完毕，等待超时结束的请求数。

3. apache调优

1)MPM（多处理模块）配置（主要负责管理网络链接，调度请求）

Apache有3个MPM，分别是: event , prefork和worker。

event这个MPM是在Apache2.4后才有稳定版,比较适用于大量连续的状况。event为不一样的任务使用单独的线程池. KeepAlive的好处是,能够同一个tcp链接中响应多个请求,这种方式，可使一个包含大量图片和html文档的请求加速50％,在Apache配置文件httpd.conf中设置KeepAlive设置为On

prefork是一个非线程的MPM。它的特色:不快但很稳定.它可以隔离每一个请求，因此若是某个请求出现故障，不会影响其余请求.使用prefork最重要的一个参数是MaxClients。这个MaxClients足够大，这样能够在访问高峰时发挥很好的性能,可是同时又不能太大，导致Apache所需内存超过物理内存

worker这个MPM，速度比prefork快不少,因为使用多线程进行访问处理，因此可以处理相对海量的请求，而系统资源的占用要小于基于进程的服务器.work有2个比较重要的参数:ThreadPerChild和MaxClients.

ThreadPerChild是用来控制每一个子进程容许创建的线程数,

MaxClients用来控制容许创建的总线程数。

prefork MPM

StartServers 5

MinSpareServers 5

MaxSpareServers 10

MaxRequestWorkers 250

MaxConnectionsPerChild 0

</IfModule]]>

StartServers ：数量的服务器进程的开始
MinSpareServers : 最小数量的服务器进程
MaxSpareServers : 最大数量的服务器进程
MaxRequestWorkers : 最大数量的服务器进程容许开始
MaxConnectionsPerChild: 最大链接数的一个服务器进程服务

worker MPM

StartServers 3

MinSpareThreads 75

MaxSpareThreads 250

ThreadsPerChild 25

MaxRequestWorkers 400

MaxConnectionsPerChild 0

</IfModule>

StartServers ：数量的服务器进程的开始
MinSpareThreads : 最小数量的工做线程
MaxSpareThreads : 最大数量的工做线程
ThreadsPerChild : 每一个服务进程包含的固定数量的工做线程
MaxRequestWorkers : 最大数量的工做线程
MaxConnectionsPerChild: 最大链接数的一个服务器进程服务

event MPM

StartServers 3

MinSpareThreads 75

MaxSpareThreads 250

ThreadsPerChild 25

MaxRequestWorkers 400

MaxConnectionsPerChild 0

</IfModule>

StartServers ：数量的服务器进程的开始
MinSpareThreads : 最小数量的工做线程
MaxSpareThreads : 最大数量的工做线程
ThreadsPerChild : 每一个服务进程包含的固定数量的工做线程
MaxRequestWorkers : 最大数量的工做线程
MaxConnectionsPerChild: 最大链接数的一个服务器进程服务

经过/opt/apache/bin/httpd -l，咱们能够看到咱们的使用是event MPM

ServerLimit 10000

StartServers 8

MinSpareThreads 75

MaxSpareThreads 250

ThreadsPerChild 25

MaxRequestWorkers 4000

MaxConnectionsPerChild 2000

</IfModule>

2）Apache其余参数优化

1. ExtendedStatus Off 关闭对每一个请求链接的扩展状态信息跟踪.

2. KeepAlive On //使用keepalive能够在单一链接时进行多个请求.

MaxKeepAliveRequests 0 //最大保持链接数， 0为不限制.

KeepAliveTimeout 5 //每一个链接保持时间

3. HostnameLookups Off

//尽可能较少DNS查询的次数。若是你使用了任何”Allow fromdomain”或”Denyfrom domain”指令(也就是domain使用的是主机名而不是IP地址)，则代价是要进行两次DNS查询(一次正向和一次反向，以确认没有做假)。因此，为了获得最高的性能，应该避免使用这些指令.

4.使用mod_deflat模块,这个模块能够在用户访问网站时实时将内容进行压缩，而后再传给客户端.因此mod_deflat能极大地加速网站,节约带宽，固然压缩须要花费cpu时间.

LoadModule deflate_module modules/mod_deflate.so

DeflateCompressionLevel 9

SetOutputFilter DEFLATE

#DeflateFilterNote Input instream

#DeflateFilterNote Output outstream

#DeflateFilterNote Ratio ratio

#LogFormat '"%r" %{outstream}n/%{instream}n (%{ratio}n%%)' deflate

#CustomLog logs/deflate_log.log deflate

</ifmodule>

5.减小Timeout值 Timeout 30

6. UseCanonicalName on

打开UseCanonicalName是Web服务器的标准作法。这是由于客户发送的大部分请求都是对本服务器的引用，打开该项设置就能使用 ServerName和Port选项的设置内容构建完整的URL。若是将这个参数设置为Off，那么Apache将使用从客户请求中得到服务器名字和端口值，从新构建URL。

7. 取消符号链接 Options FollowSymLinks

FollowSymLinks容许使用符号链接，这将使用浏览器有可能访问文档根目录(DocumentRoot)以外的内容，而且只有符号链接的目的与符号链接自己为同一用户所拥有时(SymLinksOwnerMatch)，才容许访问，这个设置将增长一些安全性，但将耗费Apache大量的资源。

4. php调优

1) 使用APC模块(缓存opcodes)

安装APC模块

tar -zxvf APC-3.0.19.tar.gz

cd APC-3.0.19

/opt/php/bin/phpize

./configure

make

make install

APC模块配置参数:

apc.enabled=1

apc.shm_segmemnts = 1

apc.shm_size = 64

APC把数据缓存到内存里面，咱们就有必要对内存资源进行限定，经过这二个配置能够限定APC可使用的内存空间大小。

apc.shm_segments指定了使用共享内存块数，而apc.shm_size则指定了一块共享内存空间大小，单位是M。因此，容许APC使用的内存大小应该是 apc.shm_segments * apc.shm_size = 64M。

apc.num_files_hint = 1000

apc.user_entries_hint = 4096

这二配置指定apc能够有多少个缓存条目。apc.num_files_hint说明你估计可能会有多少个文件相应的opcodes须要被缓成，即大约能够有多少个apc_compiler_cache条目。另外apc.user_entries_hint则说明你估计可能会有多少个apc_userdata_cache条目须要被缓存。若是项目中不使用apc_store()缓存用户数据的话，该值能够设定得更小。也就是说apc.num_files_hint与apc.user_entries_hint之和决定了APC容许最大缓存对象条目的数量。准确地设置这二个值能够获得最佳查询性能.

apc.stat =1

apc.stat_ctime

这二个参数，只跟apc_compiler_cache缓存相关，并不影响apc_user_cache。apc_complier_cache,它缓存的对象是php源文件一一对应的opcodes(目标文件)。PHP源文件存放在磁盘设备上,与之相对应的Opcodes目标文件位置内存空间(共享内存)，那么当php源文件被修改之后,怎么通知更新内存空间的opcodes呢?每次接收到请求后，APC都会去检查打开的php源文件的最后修改时间,若是文件的最后修改时间与相应的内存空间缓存对象记录的最后修改时间不一致的话，APC则会认为存放在内存空间的Opcode目标文件(缓存对象)已通过期了，apc会将缓存对象清除而且保存新解析获得的Opcode。咱们关心的是，即使没有更新任何php源文件，每次接受到http请求后，APC都会请求系统内核调用stat()来获取php源文件最后修改时。咱们能够经过将apc.stat设置为0，要求APC不去检查Opcodes相对应的php源文件是否更新了。这样能够得到最佳的性能,咱们也推荐这么作。不过，这样作有一点很差的就是，一旦有PHP源文件更新了以后，须要重启httpd守护进程或者调用apc_cache_clear()函数清空APC缓存来保证php源文件与缓存在内存空间的Opcodes相一致。

apc.ttl =0

apc.user_ttl =0

apc.ttl做用于apc_compiler_cache。当apc.ttl大于0时，每次请求都会对比此次的请求时间与上一次请求时间之差是否是大于apc.ttl，若是大于apc.ttl，则会被认缓存条目过时了，会被清理。

推荐若是项目较为稳定，而且apc.stat设置为0。同时apc.shm_size、apc.num_files_hint设置合理的话，apc.ttl建议设置为0。即apc_compiler_cache永不回收，直到重启httpd守护进程或者调用函数apc_cache_clear()清缓存。至于apc.user_ttl，建议设置为0，由开发人员调用apc_store()函数的时候，设置#ttl来指定该缓存对象的生命周期。

apc.max_file_size = 1M

apc.filters = NULL

apc.cache_by_default=1

这三个配置放在一块儿，是由于他们都用于限制缓存。其中apc.max_file_size表示若是php源文件超过了1M，则与之对应的opcodes不被缓存。而apc.filters指定一个文件过滤列表，以逗号(,)隔开。当apc.cache_by_default等于1时，与apc.filters列表中指定的文件名相匹配的文件不会被缓存。相反，apc.cache_by_default等于0时，仅缓存与acp.filters列表中指定的文件相匹配的文件。

2)使用xhprof模块（性能分析工具)

xhprof安装:

wget http://pecl.php.net/get/xhprof-0.9.2.tgz

tar zxf xhprof-0.9.2.tgz

cd xhprof-0.9.2

cp -r xhprof_html xhprof_lib /www/www.hx.com/xhprof/

cd extension/

/opt/php/bin/phpize

./configure –with-php-config=/opt/php/bin/php-config

make

make install

在php.ini中添加：

extension=xhprof.so

xhprof.output_dir=/opt/xhprof

xhprof的调用，在index.php中添加以下代码：

if (#config->php->xhprof && mt_rand(1, 10000) == 1) {

xhprof_enable();

#xhprof_on = true;

}

if(config->php->xhprof &&xhprof_on){

#xhprof_data = xhprof_disable();

#xhprof_root = '/opt/xhprof'

include_once #xhprof_root."xhprof_lib/utils/xhprof_lib.php";

include_once #xhprof_root."xhprof_lib/utils/xhprof_runs.php";

#xhprof_runs = new XHProfRuns_Default();

runid=runid=xhprof_runs->save_run(#xhprof_data, "hx");

echo '<a href="http://www.test.com/xhprof_html/index.php?run='.#run_id.'&source=hx" target="_blank">统计信息</a>';

}

运行程序，底部出现统计信息字样，点过去就能够看到性能分析了。按运行时间排序，很容易找出花时间最长的函数。

Function Name	Calls	Calls%	Incl. Wall Time (microsec)	IWall%	Excl. Wall Time (microsec)	EWall%
mysql_query	165	0.6%	93,442	47.1%	93,442	47.1%
Memcache::get	32	0.1%	10,417	5.2%	10,417	5.2%
ezSQL_mysql::query	165	0.6%	117,153	59.0%	8,816	4.4%
fgets	10	0.0%	6,275	3.2%	6,275	3.2%
mysql_fetch_field	631	2.2%	2,692	1.4%	2,692	1.4%

表格中一些参数的解释：

Function_Name : 函数名
Calls : 调用次数
Calls % : 调用百分比
Incl.Wall Time : 调用包含子函数全部花费时间以微妙计算
Excl. Wall time : 函数执行自己所花费的时间，不包括子函数执行时间.

5. mysql调优

加快mysql服务器的运行速度的方法，按照效率从低到高的依次为：

1. 替换有问题的硬件

2. 对mysql进程的设置进行调优

3. 对查询进行优化

1) 记录慢查询

在一个 SQL 服务器中，数据表都是保存在磁盘上的。索引为服务器提供了一种在表中查找特定数据行的方法，而不用搜索整个表。当必需要搜索整个表时，就称为表扫描。一般来讲，您可能只但愿得到表中数据的一个子集，所以全表扫描会浪费大量的磁盘 I/O，所以也就会浪费大量时间。当必须对数据进行链接时，这个问题就更加复杂了，由于必需要对链接两端的多行数据进行比较。

配置mysqld将这些慢查询记录到指定的慢查询日志中,经过查看慢查询日志能够定位到可能有问题的sql语句.启用慢查询日志需在my.cnf文件中添加以下设置.

[mysqld]

; enable the slow query log, default 10 seconds

log-slow-queries=/opt/mysql/logs/mysql-slow.log

; log queries taking longer than 2 seconds

long_query_time = 2

; log queries that don't use indexes even if they take less than long_query_time

; MySQL 4.1 and newer only

log-queries-not-using-indexes

这3个设置一块儿使用，能够记录执行时间超过2秒和没有使用索引的查询. 慢查询日志会存放在 /opt/mysql/logs/mysql-slow.log

阅读慢查询日志使用mysqldumpslow的命令进行。指定日志文件的路径，就能够看到一个慢查询排序后的列表，而且显示它们在日志中出现的次数.一个很是有用的特性是mysqldumpslow在比较结果以前，会删除任何用户指定的数据，所以对同一个查询的不一样调用被记为一次，这样能够找出工做量最多的查询.

/opt/mysql/bin/mysqldumpslow -s c -t 20 mysql-slow.log //慢查询中访问次数最多的20条sql

/opt/mysql/bin/mysqldumpslow -s r -t 20 mysql-slow.log //返回记录结果集最多的20条sql

-s. 是order的排序,分别按照query的次数，时间，lock时间和返回的记录数来排序.

-t , 是top n 的意思，就是返回前面多少条数据。

显示结果以下:

Count: 1147605 Time=0.01s (7931s) Lock=0.00s (107s) Rows=0.0 (984), wcontact[wcontact]@[172.16.236.115]

select Fuid, Fcompany_id from relation_company where Ftime >= N and Ftime <= N order by Fuid limit N,N

Count: 108878 Time=0.03s (2792s) Lock=0.00s (5s) Rows=1.0 (108878), wcontact[wcontact]@2hosts

SELECT COUNT(*) FROM msg_index WHERE Fobj_uid=N AND Funread=N AND Fdel=N

Count: 23142 Time=0.04s (1012s) Lock=0.00s (1s) Rows=15.7 (363685), wcontact[wcontact]@[172.16.236.115]

select Fcompany_id, count(*) num from relation_company where Ftime > N and Ftime <= N group by Fcompany_id limit N,N

............

对相应的sql语句进行优化:

例如

SELECT COUNT(*) FROM msg_index WHERE Fobj_uid=N AND Funread=N AND Fdel=N

表结构:

CREATE TABLE `msg_index` (

`Fid` int(11) NOT NULL AUTO_INCREMENT COMMENT '短消息编号',

`Fmsg_id` int(11) NOT NULL DEFAULT '0' COMMENT '消息ID',

`Fuid` bigint(20) NOT NULL DEFAULT '0' COMMENT '发送者UID',

`Fobj_uid` bigint(20) NOT NULL DEFAULT '0' COMMENT '接收者UID',

`Ftype` tinyint(3) NOT NULL DEFAULT '0' COMMENT '0发送 1接收',

`Funread` tinyint(3) NOT NULL DEFAULT '0' COMMENT '新短消息',

`Ftime` bigint(20) NOT NULL DEFAULT '0' COMMENT '发送时间',

`Fdel` tinyint(3) NOT NULL DEFAULT '0' COMMENT '删除状态',

PRIMARY KEY (`Fid`),

KEY `ft` (`Fuid`,`Fobj_uid`),

KEY `taf` (`Ftime`,`Ftype`)

) ENGINE=MyISAM AUTO_INCREMENT=163376 DEFAULT CHARSET=utf8 ROW_FORMAT=DYNAMIC

经过explain查看索引使用状况

mysql> explain SELECT COUNT(*) FROM msg_index WHERE Fobj_uid=12 AND Funread=1 AND Fdel=0;

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

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

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

1 row in set (0.00 sec)

能够看到该sql语句未用到索引，致使了全表扫描. 故因将联合索引 `ft`,拆分红2个索引.

alter table msg_index drop index `ft`;

alter table msg_index add index `Fuid`(`Fuid`);

alter table msg_index add index `Fobj_uid`(`Fobj_uid`);

2).对mysqld进程参数进行调优

1.对查询进行缓存

在/opt/mysql/my.cnf添加以下的参数：

###query_cache###

query_cache_size = 64M //启用64M查询缓存

query_cache_type = 1

query_cache_limit = 2M

query_cache_min_res_unit = 4K

启用查询缓存以后，看它是否有效使用:

mysql> show status like 'qcache%';

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

| Variable_name | Value |

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

| Qcache_free_blocks | 7321 |

| Qcache_free_memory | 33249712 |

| Qcache_hits | 17036563 |

| Qcache_inserts | 15195159 |

| Qcache_lowmem_prunes | 3166865 |

| Qcache_not_cached | 370185 |

| Qcache_queries_in_cache | 28664 |

| Qcache_total_blocks | 64727 |

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

8 rows in set (0.00 sec)

上表中一些变量的解释:

Qcache_free_blocks	缓存中相邻内存块的个数。数目大说明可能有碎片。FLUSH QUERY CACHE 会对缓存中的碎片进行整理，从而获得一个空闲块。
Qcache_free_memory	缓存中的空闲内存。
Qcache_hits	每次查询在缓存中命中时就增大。
Qcache_inserts	每次插入一个查询时就增大。命中次数除以插入次数就是不中比率；用 1 减去这个值就是命中率。在上面这个例子中，大约有 87% 的查询都在缓存中命中。
Qcache_lowmem_prunes	缓存出现内存不足而且必需要进行清理以便为更多查询提供空间的次数。这个数字最好长时间来看；若是这个数字在不断增加，就表示可能碎片很是严重，或者内存不多。（上面的free_blocks 和 free_memory 能够告诉您属于哪一种状况）。
Qcache_not_cached	不适合进行缓存的查询的数量，一般是因为这些查询不是 SELECT 语句。
Qcache_queries_in_cache	当前缓存的查询（和响应）的数量。
Qcache_total_blocks	缓存中块的数量。

间隔几秒显示这些变量就能够看出区别，这能够帮助肯定缓存是否正在有效地使用。

2.强制限制

能够在mysqld中强制来确保系统负载不会致使系统资源耗尽

max_connections = 800

wait_timeout = 15

max_connect_errors = 200

max_connections 是设置链接最大数，确保只创建服务器容许数目的链接.

肯定目前创建的最大链接数,能够执行show status like 'max_used_connections'.

mysql> show status like 'max_used_connections';

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

| Variable_name | Value |

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

| Max_used_connections | 26 |

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

1 row in set (0.00 sec)

第 2 行告诉 mysqld 终止全部空闲时间超过 15 秒的链接。在 LAMP 应用程序中，链接数据库的时间一般就是 Web 服务器处理请求所花费的时间。有时候，若是负载太重，链接会挂起，而且会占用链接表空间。若是有多个交互用户或使用了到数据库的持久链接，那么将这个值设低一点并不可取！

最后一行是一个安全的方法。若是一个主机在链接到服务器时有问题，并重试不少次后放弃，那么这个主机就会被锁定，直到 FLUSH HOSTS 以后才能运行。默认状况下，10 次失败就足以致使锁定了。将这个值修改成 100 会给服务器足够的时间来从问题中恢复。若是重试 100 次都没法创建链接，那么使用再高的值也不会有太多帮助，可能它根本就没法链接。

3.表缓存.

数据库中每一个表均可以表示为磁盘上的一个文件,必须先打开，后读取。为了加快从文件中读取数据,mysqld会对这些打开的文件进行缓存。其最大数目的是由/opt/mysql/my.cnf中的table_cache指定.

###表缓存

table_cache= 1024

显示打开表的活动状况:

mysql> show status like 'open%tables';

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

| Variable_name | Value |

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

| Open_tables | 287 |

| Opened_tables | 12 |

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

2 rows in set (0.00 sec)

上述说明: 目前有287表是打开的，有12个表是须要打开的，由于缓存中已经没有可用的文件描述符了。若是Opened_tables随着运行show status命令而快速增长时,说明缓存的命中率不够.若是Opened_tables比table_cache设置小不少，就说明该值太大.

4. 线程的缓存

所说线程缓存,就是mysqld早接收链接时会根据须要生成线程.在一个链接变化很快的繁忙服务器上，对线程进行缓存有助于能够加快最初的链接.

显示线程使用的统计信息:

mysql> show status like 'threads%';

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

| Variable_name | Value |

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

| Threads_cached | 0 |

| Threads_connected | 68 |

| Threads_created | 1359226 |

| Threads_running | 1 |

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

上述中最重要的是 Threads_created值，每次mysqld须要建立一个新线程时,这个值都会增长。若是这个值随着show status命令而快速增长，就应该尝试增大线程缓存.

###线程缓存

Thread_cache 16

5.关键字缓存区（myisam）

关键字缓存区是保存myisam表的索引块.在联想状况下，对于这些块的请求应该来自于内存，而非磁盘.如何肯定有多少块是从磁盘读取，有多少块是从内存读取的.

mysql> show status like 'key_read%';

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

| Variable_name | Value |

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

| Key_read_requests | 2367514011 |

| Key_reads | 652489 |

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

2 rows in set (0.00 sec)

Key_reads表明命中磁盘的请求次数，key_read_requests是总数.命中磁盘的次数占总数的 652489 /2367514011 = 0.0002756. 大约在1000个请求中有0.3次不会命中内存.若是该值(0.3)超过1时，就应该考虑增大关键字缓存区.key_buffer = 2G会将缓存区设置为2G.

###MyISAM引擎参数###

key_buffer_size=2G

key_cache_block_size=1024

read_buffer_size=32M

read_rnd_buffer_size=32M

myisam_sort_buffer_size=2M

6.临时表的使用

临时表能够在高级查询中使用，其中数据在进一步进行处理（group by )以前, 都必须先保存在临时表中.理想状况下，在内存中建立临时表,若是临时表变的太大，就须要写入磁盘中.

mysql> show status like 'created_tmp%';

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

| Variable_name | Value |

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

| Created_tmp_disk_tables | 0 |

| Created_tmp_files | 746 |

| Created_tmp_tables | 0 |

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

3 rows in set (0.00 sec)

每次使用临时表都会增大 Created_tmp_tables；基于磁盘的表也会增大 Created_tmp_disk_tables。对于这个比率，并无什么严格的规则，由于这依赖于所涉及的查询。长时间观察 Created_tmp_disk_tables 会显示所建立的磁盘表的比率，您能够肯定设置的效率。 tmp_table_size 和 max_heap_table_size 均可以控制临时表的最大大小，所以请确保在 my.cnf 中对这两个值都进行了设置。

优化查询语句时候，要避免使用临时表,若是避免不了的话，必定要保证临时表存在内存中。若是你有不少group by语句，而且有不少内存的话，那就增大tmp_table_size和max_heap_table_size的值.

通常遵循的的公式：

Created_tmp_disk_tables/Created_tmp_tables<5%。

7.排序缓存区

当mysql进行排序时，就会在磁盘上读取数据时分配一个缓存区来存放这些数据行.若是要排序的数据太大,那么数据就要存放在磁盘上的临时文件中，并再次进行排序。若是sort_merge_passes状态量很大,这就指示磁盘的活动状况.

mysql> SHOW STATUS LIKE "sort%";

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

| Variable_name | Value |

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

| Sort_merge_passes | 1 |

| Sort_range | 79192 |

| Sort_rows | 2066532 |

| Sort_scan | 44006 |

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

4 rows in set (0.00 sec)

若是sort_merge_passes很大.就表示要注意sort_buffer_size。 sort_buffer_size=16M将排序缓存区设置为16M.

###排序缓存区

sort_buffer_size=16M

8.innodb参数

1) innodb_buffer_pool_size

对于innodb表来讲，innodb_buffer_pool_size的做用就至关于key_buffer_size相对于myisam同样.innodb使用该参数指定大小的内存来缓冲数据和索引.对于单独的mysql数据库服务器，最大能够把该值设置成物理内存的80%。

2）innodb_additional_mem_pool_size

该参数指定Innodb用来存储数据字典和其余内部数据结构的内存池大小。缺省值为1M。对于 2G内存的服务器推荐值为 20M.

3)innodb_log_buffer_size

推荐值为8M。

4）innodb_log_file_size

推荐值是 innodb_buffer_pool_size的25%.

5) innodb_flush_log_at_trx_commit

该值指定innodb记录日志的方式.若是设置为1，则每一个事务提交的时候,mysql都会将事务日志写入磁盘.若是设置为0或2，则每秒将日志写入磁盘一次.

6) innodb_file_per_table

将该值设置为1时，则innodb表将使用独立的表空间.

###Innodb引擎参数###

innodb_buffer_pool_size = 4G

innodb_additional_mem_pool_size = 20M

innodb_log_file_size = 256M

innodb_log_buffer_size = 8M

innodb_flush_log_at_trx_commit = 1

innodb_lock_wait_timeout = 100

innodb_open_files=800

innodb_file_per_table = 1

innodb_commit_concurrency = 4

3)使用mysqlreport调优性能

下载 :http://hackmysql.com/scripts/mysqlreport-3.5.tgz

解压 tar zxf mysqlreport-3.5.tgz

./mysqlreport -user test -password test -port 3306

Can't locate DBI.pm in @INC (@INC contains: /usr/local/lib64/perl5 /usr/local/share/perl5 /usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl /usr/lib64/perl5 /usr/share/perl5 .) at ./mysqlreport line 24.

BEGIN failed--compilation aborted at ./mysqlreport line 24.

解决该错误 : sudo yum install perl-DBI perl-DBD-MySQL -y

使用mysqlreport

[root@WRM_DB01 mysqlreport-3.5]# perl mysqlreport --host=127.0.0.1 --user=test --password=test

__ Key _________________________________________________________________

Buffer used 295.49M of 24.00G %Used: 1.20

Current 4.78G %Usage: 19.91

Write hit 65.12%

Read hit 99.97%

__ Questions ___________________________________________________________

Total 45.03M 19.2/s

DMS 22.87M 9.7/s %Total: 50.79

QC Hits 17.39M 7.4/s 38.63

Com_ 3.53M 1.5/s 7.85

COM_QUIT 1.41M 0.6/s 3.13

-Unknown 178.89k 0.1/s 0.40

Slow 2 s 2.93M 1.3/s 6.52 %DMS: 12.83 Log: ON

DMS 22.87M 9.7/s 50.79

SELECT 15.89M 6.8/s 35.28 69.48

INSERT 3.80M 1.6/s 8.44 16.63

UPDATE 1.41M 0.6/s 3.14 6.18

REPLACE 938.06k 0.4/s 2.08 4.10

DELETE 827.92k 0.4/s 1.84 3.62

Com_ 3.53M 1.5/s 7.85

set_option 2.03M 0.9/s 4.50

change_db 1.01M 0.4/s 2.25

show_status 366.23k 0.2/s 0.81

__ SELECT and Sort _____________________________________________________

Scan 2.51M 1.1/s %SELECT: 15.81

Range 3.98M 1.7/s 25.05

Full join 14.74k 0.0/s 0.09

Range check 0 0/s 0.00

Full rng join 0 0/s 0.00

Sort scan 1.68M 0.7/s

Sort range 251.33k 0.1/s

Sort mrg pass 371 0.0/s

__ Query Cache _________________________________________________________

Memory usage 35.67M of 64.00M %Used: 55.73

Block Fragmnt 9.92%

Hits 17.39M 7.4/s

Inserts 15.49M 6.6/s

Insrt:Prune 4.81:1 5.2/s

Hit:Insert 1.12:1

__ Table Locks _________________________________________________________

Waited 3.36k 0.0/s %Total: 0.01

Immediate 24.70M 10.5/s

__ Tables ______________________________________________________________

Open 287 of 1024 %Cache: 28.03

Opened 893 0.0/s

__ Connections _________________________________________________________

Max used 26 of 800 %Max: 3.25

Total 1.41M 0.6/s

__ Created Temp ________________________________________________________

Disk table 3.57k 0.0/s

Table 927.74k 0.4/s Size: 16.0M

File 748 0.0/s

__ Threads _____________________________________________________________

Running 3 of 7

Cached 13 of 16 %Hit: 100

Created 32 0.0/s

Slow 0 0/s

__ Aborted _____________________________________________________________

Clients 34 0.0/s

Connects 333 0.0/s

__ Bytes _______________________________________________________________

Sent 18.91G 8.1k/s

Received 9.19G 3.9k/s

__ InnoDB Buffer Pool __________________________________________________

Usage 1.00M of 4.00G %Used: 0.02

Read hit 92.17%

Pages

Free 262.08k %Total: 99.98

Data 64 0.02 %Drty: 0.00

Misc 0 0.00

Latched 0.00

Reads 166 0.0/s

From file 13 0.0/s 7.83

Ahead Rnd 1 0.0/s

Ahead Sql 0 0/s

Writes 0 0/s

Flushes 0 0/s

Wait Free 0 0/s

__ InnoDB Lock _________________________________________________________

Waits 0 0/s

Current 0

Time acquiring

Total 0 ms

Average 0 ms

Max 0 ms

__ InnoDB Data, Pages, Rows ____________________________________________

Data

Reads 26 0.0/s

Writes 3 0.0/s

fsync 3 0.0/s

Pending

Writes 0

fsync 0

Pages

Created 0 0/s

Read 64 0.0/s

Written 0 0/s

Rows

Deleted 0 0/s

Inserted 0 0/s

Read 0 0/s

Updated 0 0/s

6. apache ab 压力测试

/opt/apache/bin/ab -c 1000 -n 1000 http://www.baidu.com /

This is ApacheBench, Version 2.3 <Revision:655654Revision:655654>

Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking http://www.baidu.com (be patient)

Completed 100 requests

Completed 200 requests

Completed 300 requests

Completed 400 requests

Completed 500 requests

Completed 600 requests

Completed 700 requests

Completed 800 requests

Completed 900 requests

Completed 1000 requests

Finished 1000 requests

Server Software: Apache/2.4.3

Server Hostname: http://www.baidu.com

Server Port: 80

Document Path: /

Document Length: 0 bytes

Concurrency Level: 1000 //并发数

Time taken for tests: 19.280 seconds //整个测试持续的时间

Complete requests: 1000 //完成的请求数

Failed requests: 0 //失败的数量

Write errors: 0

Non-2xx responses: 1000

Total transferred: 669559 bytes // 整个传输量

HTML transferred: 0 bytes

//至关于 LR 中的每秒事务数，后面括号中的 mean 表示这是一个平均值

Requests per second: 51.87 [#/sec] (mean)

// 至关于 LR 中的平均事务响应时间，后面括号中的 mean 表示这是一个平均值

Time per request: 19279.633 [ms] (mean)

Time per request: 19.280 [ms] (mean, across all concurrent requests)

//平均每秒网络上的流量，能够帮助排除是否存在网络流量过大致使响应时间延长的问题

Connection Times (ms)

min mean[+/-sd] median max

Connect: 0 1699 3354.9 0 13403

Processing: 60 2356 2019.0 1918 15280

Waiting: 60 2354 2019.4 1918 15280

Total: 61 4055 4334.0 2584 19277

Percentage of the requests served within a certain time (ms)

50% 2584

66% 4267

75% 5154

80% 5807

90% 9886

95% 16438

98% 18259

99% 18298

100% 19277 (longest request)

整个场景中全部的用户请求的响应情况，每一个请求都有一个响应时间，其中50%的用户响应的时间小于2584ms,66％的用户响应时间小于4267，最大的响应时间为19277ms

优化后测试的结果:

[root@web ~]# /opt/apache/bin/ab -c 1000 -n 1000 http://www.baidu.com

This is ApacheBench, Version 2.3 <Revision:655654Revision:655654>

Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking http://www.baidu.com (be patient)

Completed 100 requests

Completed 200 requests

Completed 300 requests

Completed 400 requests

Completed 500 requests

Completed 600 requests

Completed 700 requests

Completed 800 requests

Completed 900 requests

Completed 1000 requests

Finished 1000 requests

Server Software: Apache/2.4.3

Server Hostname: http://www.baidu.com

Server Port: 80

Document Path: /

Document Length: 0 bytes

Concurrency Level: 1000

Time taken for tests: 11.070 seconds

Complete requests: 1000

Failed requests: 0

Write errors: 0

Non-2xx responses: 1000

Total transferred: 637429 bytes

HTML transferred: 0 bytes

Requests per second: 90.33 [#/sec] (mean)

Time per request: 11070.237 [ms] (mean)

Time per request: 11.070 [ms] (mean, across all concurrent requests)

Transfer rate: 56.23 [Kbytes/sec] received

Connection Times (ms)

min mean[+/-sd] median max

Connect: 0 745 1929.5 0 9012

Processing: 529 2289 1451.9 1818 9833

Waiting: 529 2287 1451.8 1818 9833

Total: 544 3033 2312.3 2333 10987

Percentage of the requests served within a certain time (ms)

50% 2333

66% 3002

75% 3811

80% 4183

90% 6512

95% 8925

98% 10694

99% 10809

100% 10987 (longest request)

根据测试结果进行对比 :

对于1000的并发数,总耗时从19.280s降低到11.070s

优化前:

Requests per second: 51.87 [#/sec] (mean)

Time per request: 19279.633 [ms] (mean)

Time per request: 19.280 [ms] (mean, across all concurrent requests)

Transfer rate: 33.91 [Kbytes/sec] received

优化后：

Requests per second: 90.33 [#/sec] (mean)

Time per request: 11070.237 [ms] (mean)

Time per request: 11.070 [ms] (mean, across all concurrent requests)

Transfer rate: 56.23 [Kbytes/sec] received

最能反应服务器性能的是 Request per second,即每秒完成的请求数从51.87提高到90.33。

每一个请求花费的时间从19.280ms降低到11.070ms.

每秒的网络流流量从33.91Kbytes提高到56.23Kbytes.

参考文章：http://www.cnblogs.com/kristain/articles/4127381.html