2014年10月30日星期四

系统性能排查命令及优化思路

本邮件内容由第三方提供,如果您不想继续收到该邮件,可 点此退订
系统性能排查命令及优化思路  阅读原文»

用户名:兰心hui性
文章数:18
评论数:17
访问量:8990
无忧币:1351
博客积分:286
博客等级:2
注册日期:2013-07-06

系统性能排查命令及优化思路

最近笔者经常处理了一些线上的问题机器。特抽空写一篇文章将处理系统性能问题和优化思路进行总结,方便后续工作中系统故障的排查。作为运维,收到网管系统性能报警应该是常有的事情。而快速进行问题定位并解决则是工作的关键。我们在排查或者优化一个系统的时候无外乎从以下几个方面考虑:

1.CPU的使用率异常,如某个核心的使用率过高,而其它核心则处于空闲的状况。

2.内存的使用状况:通常需要注意是否程序内存泄漏导致的。

3.磁盘IO性能:通常磁盘IO不正常时我们需要判断程序是否处在顺序读写的状态。

4.网络IO负载:如web服务要考虑time_wait状态的连接数;如代理服务器,检查系统打开的socket连接数。

5.程序性能问题:缓存和DB类注关注写的性能,web服务类关注内存的使用

6.系统BUG:一般都是在某些高并发场景才体现出来问题。

常用的判断工具和命令的用法总结如下:

1.系统性能综合判断工具vmstat

当系统出现性能瓶颈后可以使用vmstat命令简单判断一下进程的运行状况及系统资源的使用率,详细输入情况如下:

wKiom1RPu8-SG-2EAAESfgFVKJs023.jpg

注意事项:

1.rb的数量,一般r小于CPU的核心数,b表示阻塞的队列长度。如果r并未达到最大值而b的数量较多,我们就需要观察进程所需要的资源状况。

2.注意incs的比例和数量,in表示中断的请求数,而cs才代表CPU对中断的处理状况。如果有较多的上下文切换则可以结合top命令观察CPU性能。

选项解释:

rrunning状态进程个数,小于CPU核心数(CPU时间片+所需要的资源)
b被阻塞的进程队列的长度(等待I/O完成即进程所需要的资源未到位或者未拿到CPU时间片)
swpd从物理内存交换至交换分区的数据量
buffbuffercache的空间大小,即IO处理时的缓冲。(结果)
cachepagecache的空间大小,缓存的是linux中的具体文件。进程运行时所需要的资源。(过程)
si从内存转到swap分区
so从swap到内存(kb/s)
bi从块设备读入内存的数据量(kb/s),如select
bo从内存保存至块设备的数据量(kb/s),如update,insert
in中断发生的速率,通常意味每秒多少次中断请求发生产生原因:时间片轮转,IO(磁盘/网络)
cs对中断的响应,即上下文切换(进程切换)个数

2.LinuxCPU使用状况排查命令top(htop)

wKioL1RPvsORaZj4AAFs9qsfxy8951.jpg

注意事项:

1.键入1观察各CPU使用状况,可能会出现某些核心使用率较高而某些核心却处于空闲状态。如果运行类似于nginx这样的web应用可以将核心与进程绑定,这样既能将用户请求负载均衡也能减小CPU上下文切换的消耗。

2.使用该命令一般会查看每个CPU的使用率。如果发现id资源较少,也可以观察wa状态百分比,该状态高百分比也有可能是程序未能拿到运行时所需要的资源或者时间片。所以有的时候我们发现系统load较高,而cpu use较少的情况。都是因为进程在等待所运行资源的到位。

3.可以键入M基于内存使用大小排序观察各进程内存使用大小。

选项解释:

wKiom1RPvvbwtaZzAAEFtv95sVQ827.jpg

3.内存信息展示free

keepalived+amoeba+mysql-mmm+mysql实现mysql读写分离及高可用  阅读原文»

用户名:quenlang 文章数:5
评论数:2
访问量:636无忧币:130:102:1 注册日期:2012-04-10

keepalived+amoeba+mysql-mmm+mysql实现mysql读写分离及高可用

最近尝试了一下mysql的读写分离和高可用的搭建。搭好之后体验了一下,效果还不错。这里跟大家分享一下。

1、首先介绍一下mysql-mmm这个工具是干嘛使的?

众所周知,mysql自身提供了AB复制。我们也可以很轻松的实现master-master双向复制,同时再为其中的一个master节点搭建一个slave库。这样就实现了master1与master2之间的双向复制,同时master1与slave1之间主从复制这样的架构。这样整个体系中就存在两个master,正常情况下只有一个master对外提供服务。如果对外提供服务的master意外宕机了,这时mysql本身并不具备failover切换的能力,这样尽管系统中还有一个正常的master节点,但应用仍不可用,这个正常的master尽管存在,但无疑是个摆设。mysql-mmm就是在这样的条件下诞生的。

Mysql-MMM是Master-Master Replication Manager for MySQL(mysql主主复制管理器)的简称,该项目来自于Google,旨在用来监控mysql主主复制和做失败转移。其原理是将真实数据库节点的IP映射为虚拟IP集,在这个虚拟的IP集中,有一个用于write的IP,多个用于read的IP,这个用于write的虚拟IP映射着数据库集群中的两台master的真实IP,以此来实现failover的切换,如果觉得不是很明白,没有关系,后边具体配置部分还会再做说明。

Mysql-MMM是一个开源的项目,官网:http://mysql-mmm.org

2、接着来说amoeba是个什么物件?

可能您听说过mysql-proxy,这个mysql官方维护的一个实现mysql读写分离的工具,曾经测试使用过,但没有在生产中使用。网上大家讨论比较多的是mysql-proxy的配置比较麻烦,其实不是的,单说mysql-proxy的配置的话是比较简单的,不比amoeba麻烦多少,主要是mysql-proxy自身不带有启动脚本,如果你想实现像mysql服务那样的启动方式就需要自己来编写服务脚本。这里实现mysql读写分离,使用淘宝开源出来的amoeba,amoeba是用java开发出来的一款软件,其配置文件为xml格式。选择amoeba是因为amoeba是淘宝在生产环境中使用过的,经过实践测试的,相比mysql-proxy来说,风险性要小一些。

3、最后来说keepalived

keeplived是用来实现服务的高可用的一款优秀的工具,需要说明的是keepalived会为代理的服务虚拟一个IP,用于外部访问,正常情况下,这个虚拟IP是绑定在master上的。master通过脚本来周期性判断服务是否正常运行,如果发现服务异常,就会停掉keepalived服务,这时原本绑定在master上的虚拟IP就会浮动到backup上,由于这个虚拟IP仍然存在,所以外部仍旧可以访问这个服务。

实验环境:

hadoop0.updb.com192.168.0.100

hadoop1.updb.com192.168.0.101

hadoop2.updb.com192.168.0.102

hadoop3.updb.com192.168.0.103

hadoop4.updb.com192.168.0.104

hadoop5.updb.com192.168.0.105

mysql 5.6

所有节点的系统均为centos,使用自带网络yum源,扩展epel源,保证你的各节点均能访问公网,因为我们的mysql-mmm和keepalived均使用epel源进行网络安装。

最终架构:

wKiom1RPUDaj0rJ7AAHVNrZd8pM728.jpg

为了尽可能简洁而清楚的表达,上图中并没有显示mysql-mmm的部署规划。mysql-mmm分为monitor端和agent端,实验中在所有的mysql节点(192.168.0.102-192.168.0.105)上安装agent端,在192.168.0.101上安装monitor端。

好了,到这里相信你的心中已经有了丘壑,下面我们将一步一步来实现

1、搭建mysql集群,基本的mysql安装这里不再介绍(这里主主复制、主从复制的搭建是在全新安装的数据库的基础上,所以在设置同步参数时,binlog为mysql-bin.000001

a、mysql 主主复制

首先停掉hadoop2、hadoop3上的mysql服务,修改配置文件,hadoop2配置如下:

[root@hadoop2~]#cat/etc/my.cnf
log-bin=mysql-bin.log
log-slave-updates
innodb_buffer_pool_size=512M
innodb_flush_log_at_trx_commit=1
sql_mode=STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION,NO_AUTO_VALUE_ON_ZERO
lower_case_table_names=1
log_bin_trust_function_creators=1
character-set-server=utf8
default-character-set=utf8

hadoop3配置文件,注意server-id不能重

[root@hadoop3~]#cat/etc/my.cnf
log-bin=mysql-bin.log
log-slave-updates
innodb_buffer_pool_size=512M
innodb_flush_log_at_trx_commit=1
sql_mode=STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION,NO_AUTO_VALUE_ON_ZERO
lower_case_table_names=1
log_bin_trust_function_creators=1
character-set-server=utf8
default-character-set=utf8

重启hadoop2、hadoop3上的mysql服务

hadoop2、hadoop3上都执行添加同步用户的操作

mysql>grantreplicationslaveon*.*to'rep'@'192.168.0.%'identifiedby'123456';

hadoop3上设置同步参数

没有评论:

发表评论