MYSQL数据库网卡软中断不平衡问题及解决方案
原创文章,转载请注明: 转载自Erlang非业余研究
本文链接地址: MYSQL数据库网卡软中断不平衡问题及解决方案
最近公司在MySQL的数据库上由于采用了高速的如PCIe卡以及大内存,去年在压力测试的时候突然发现数据库的流量可以把一个千M网卡压满了。随着数据库的优化,现在流量可以达到150M,所以我们采用了双网卡,在交换机上绑定,做LB的方式,提高系统的吞吐量。
但是在最近压测试的一个数据库中,mpstat发现其中一个核的CPU被软中断耗尽:
Mysql QPS 2W左右
——– —–load-avg—- —cpu-usage— —swap— -QPS- -TPS- -Hit%-
time | 1m 5m 15m |usr sys idl iow| si so| ins upd del sel iud| lor hit|
13:43:46| 0.00 0.00 0.00| 67 27 3 3| 0 0| 0 0 0 0 0| 0 100.00|
13:43:47| 0.00 0.00 0.00| 30 10 60 0| 0 0| 0 0 0 19281 0| 326839 100.00|
13:43:48| 0.00 0.00 0.00| 28 10 63 0| 0 0| 0 0 0 19083 0| 323377 100.00|
13:43:49| 0.00 0.00 0.00| 28 10 63 0| 0 0| 0 0 0 19482 0| 330185 100.00|
13:43:50| 0.00 0.00 0.00| 26 9 65 0| 0 0| 0 0 0 19379 0| 328575 100.00|
13:43:51| 0.00 0.00 0.00| 27 9 64 0| 0 0| 0 0 0 19723 0| 334378 100.00|
针对这个问题,我们利用工具,特别是systemtap, 一步步来调查和解决问题。
Read more…
Post Footer automatically generated by wp-posturl plugin for wordpress.
systemtap如何跟踪libc.so
原创文章,转载请注明: 转载自Erlang非业余研究
本文链接地址: systemtap如何跟踪libc.so
下午和周忱同学折腾复杂程序的内存泄漏问题,用了valgrind, gogle perftools等工具都不大好用,很容易把应用程序搞死,于是打算用systemtap来在libc.so层面了解内存的使用情况。主要思路就是看malloc/realloc和free的调用次数的平衡。
首先准备下环境,系统是标准的RHEL 5u4:
$ uname -r
2.6.18-164.el5
$ stap -V
SystemTap translator/driver (version 1.3/0.137 non-git sources)
Copyright (C) 2005-2010 Red Hat, Inc. and others
This is free software; see the source for copying conditions.
enabled features: LIBRPM LIBSQLITE3 NSS BOOST_SHARED_PTR TR1_UNORDERED_MAP
$stap -L 'kernel.function("printk")'
kernel.function("printk@kernel/printk.c:533") $fmt:char const* $args:va_list
$ stap -L 'process("/lib64/libc.so.6").function("malloc")'
Missing separate debuginfos, use: debuginfo-install glibc-2.5-42.x86_64
内核的符号是OK的,glibc没有安装符号。系统提示用 debuginfo-install glibc-2.5-42.x86_64 命令安装符号信息,但是RHEL 5不交钱不能用这个服务的,只能自己下载包安装。
Read more…
Post Footer automatically generated by wp-posturl plugin for wordpress.
给你的Linux系统上点stress
原创文章,转载请注明: 转载自Erlang非业余研究
本文链接地址: 给你的Linux系统上点stress
《debug hacks》 这本书介绍了非常多的调试手段和工具, 其中提到了stress这个简单的压力测试工具,在我们的日常工作中很有用。利用它可以给我们的系统施加CPU,内存,IO和磁盘的压力,在模拟极端场景给应用系统造成的压力方面很有帮助。
主页见这里:http://weather.ou.edu/~apw/projects/stress/
这里还有一篇介绍如何使用的博客。
stress is a deliberately simple workload generator for POSIX systems. It imposes a configurable amount of CPU, memory, I/O, and disk stress on the system. It is written in C, and is free software licensed under the GPLv2.
这个stress实现非常的简单,所有的功能在一个.c文件里面实现, 系统运行的时候会fork多个子进程,分别进行CPU,内存,IO方面的折磨。
Read more…
Post Footer automatically generated by wp-posturl plugin for wordpress.
fio配合cgroup测试存储设备IOPS分配
原创文章,转载请注明: 转载自Erlang非业余研究
本文链接地址: fio配合cgroup测试存储设备IOPS分配
随着包括存储设备在内服务器的能力越来越高,特别是用上了PCIe存储卡后,IOPS能力通常有10几万,马上过剩。在这种情况下,一台服务器可以干很多事情,在上面跑很多服务。那么如何保证系统的服务质量是个很重要的事情了。
我们在下来的的项目中倾向于用cgroup来做资源的隔离和限制,原因是cgroup的开销很小,而且很易用。cgroup 可以参考这里
我们特别关心cgroup的blkio子模块,他有2种限制模式:
1. throttle,限制每个进程能使用的IOPS或者吞吐量。
2. weight,现在每个进程能使用的IOPS的能力的比例,必须通过CFQ调度器来实现。
文档和具体的参数可以看上面提到的cgroup文档。
Post Footer automatically generated by wp-posturl plugin for wordpress.
Flash存储设备在淘宝的应用实践(2011年iDevOps系统技术沙龙)
原创文章,转载请注明: 转载自Erlang非业余研究
Post Footer automatically generated by wp-posturl plugin for wordpress.
SSD在淘宝的应用实践
原创文章,转载请注明: 转载自Erlang非业余研究
本文链接地址: SSD在淘宝的应用实践
Post Footer automatically generated by wp-posturl plugin for wordpress.
大文件重定向和管道的效率对比
原创文章,转载请注明: 转载自Erlang非业余研究
本文链接地址: 大文件重定向和管道的效率对比
微博上的@拉风_zhang提出了个问题:
@淘宝褚霸 请教个问题,#1. cat huge_dump.sql | mysql -uroot ;#2. mysql -uroot < huge_dump.sql ;#1效率要高,在linux中通过管道传输 和 < 这种方式有什么差别呢?谢谢!#AskBaye#
这个问题挺有意思的,我的第一反应是:
没比较过,应该是一样的,一个是cat负责打开文件,一个是bash
这种场景在MySQL运维操作里面应该比较多,所以就花了点时间做了个比较和原理上的分析:
我们先构造场景:
首先准备一个程序b.out来模拟mysql对数据的消耗:
$ cat b.c
#include <stdio.h>
int main(int argc, char *argv[])
{
char buf[4096];
while(fread(buf, sizeof(buf), 1, stdin) > 0);
return 0;
}
$ gcc -o b.out b.c
$ ls|./b.out
编译好再顺手我们的程序功能是正确的:纯消耗流。
再来写个systemtap脚本用来方便观察程序的行为。
$ cat test.stp
function should_log(){
return (execname() == "cat" ||
execname() == "b.out" ||
execname() == "bash") ;
}
probe syscall.open,
syscall.close,
syscall.read,
syscall.write,
syscall.pipe,
syscall.fork,
syscall.execve,
syscall.dup,
syscall.wait4
{
if (!should_log()) next;
printf("%s -> %s\n", thread_indent(0), probefunc());
}
probe kernel.function("pipe_read"),
kernel.function("pipe_readv"),
kernel.function("pipe_write"),
kernel.function("pipe_writev")
{
if (!should_log()) next;
printf("%s -> %s: file ino %d\n", thread_indent(0), probefunc(), __file_ino($filp));
}
probe begin { println(":~") }
这个脚本重点观察几个系统调用的顺序和pipe的读写情况,
然后再准备个419M的大文件huge_dump.sql,在我们几十G内存的机器很容易在内存里放下:
$ sudo dd if=/dev/urandom of=huge_dump.sql bs=4096 count=102400 102400+0 records in 102400+0 records out 419430400 bytes (419 MB) copied, 63.9886 seconds, 6.6 MB/s
因为这个文件是用bufferio写的,所以它的内容都cache在pagecahce内存里面,不会涉及到磁盘。
好了,场景齐全了,我们接着来比较下二种情况下的速度:
Read more…
Post Footer automatically generated by wp-posturl plugin for wordpress.

Recent Comments