新游戏上线，表现各种慢.根据当前数据量、执行的SQL(慢查询日志)、show status 状态。可以排除是DB的问题。但MySQL 现在响应时间是多少，没有具体数值是没有什么说服力的。今天实战一下：（原理文章可以参考 MySQL响应时间监测）
由于在server上直至执行提示：
FATAL: kernel too old
Segmentation fault
后来干脆直接先用tcpdump抓包，在用 tcprstat分析；
利用原先的脚本是这样的：
tcpdump -i eth1 -s 65535 -l -w ./tfile dst port 3306
其实，做过的人都知道以上是错误的，因为 只抓 dst中的包 没有src 对于tcprstat 是无法计算响应时间的。tcprstat分析的时候 结果全部是0.
后来脚本改为：
tcpdump -i eth1 -s 65535 -l -w ./tfile port 3306
./tcprstat -l 10.204.218.97 -r tfile
结果为：
timestamp count max min avg med stddev 95_max 95_avg 95_std 99_max 99_avg 99_std 1351239571 3359 9083 38 84 47 164 162 74 45 246 79 49 1351239581 1714 828 41 84 49 62 179 75 45 257 81 51 1351239591 1949 490 40 80 48 53 162 73 42 247 78 47 1351239601 1910 7194 40 83 48 172 160 72 40 242 77 46 1351239611 932 467 40 85 50 59 183 76 45 283 82 52 1351239621 1206 328 40 80 48 52 172 73 41 235 78 48 1351239631 1166 4868 40 87 49 152 177 75 43 264 80 52 1351239641 1774 866 40 82 49 57 166 74 43 231 79 47 1351239651 753 326 35 79 48 51 165 72 41 228 77 47 1351239661 788 390 33 82 48 55 186 75 45 244 80 52 1351239671 2467 2739 32 81 47 79 170 72 43 262 78 48 1351239681 1470 4128 33 81 47 130 173 70 40 251 75 48 1351239691 2256 451 33 78 46 55 172 71 44 248 76 50
简单说明： 最大的响应时间是 9毫秒 , 最小响应时间是33微妙， 其中 95%的查询响应时间是 72微妙，最大为160微妙
状态比较良好，对于9毫秒的，可以利用pt-query-digest 进行 processlist 分析。
简单记录下！
本文转自 位鹏飞 51CTO博客，原文链接：http://blog.51cto.com/weipengfei/1038281，如需转载请自行联系原作者
