大鹏一日同风起

分类： linux

  • MySQL CPU使用率高情况的原因和解决

     

    1. 问题原因
    1.1 应用负载（QPS）高
    1.2. 查询执行成本（查询访问表数据行数 avg_lgc_io）高
    2. 解决方法
    2.1 应用负载（QPS）高
    2.2 查询语句执行成本（查询访问表数据行数）高
    3. 避免出现 CPU 使用率达到 100% 影响业务的一般原则

    1. 问题原因：

    应用提交的查询（包括数据修改操作）执行所需大量的逻辑读（逻辑IO，执行查询所需访问的表的数据行数），系统需要消耗大量的 CPU 资源用于维护从存储系统读取到内存中的数据一致性。

    注：本文不排除由于MySQL 其他原因（比如大量行锁冲突、行锁等待）或后台任务原因导致的实例 CPU 使用率高，但这种情况出现的概率是非常低的，在此不做讨论。

    通过一个简化的模型来说明 系统资源、语句执行成本 以及 QPS（Query Per Second 每秒执行的查询数）之间的关系：

    条件：应用模型恒定（应用没有修改），

    avg_lgc_io：每条查询执行需要的平均逻辑 IO

    total_lgc_io：实例 CPU 资源单位时间能够处理的 逻辑IO 总量

    公式：

    total_lgc_io = avg_lgc_io x QPS -- 单位时间 CPU 资源 = 查询执行平均成本 x 单位时间执行的查询数量

    下面列出 2 种典型 CPU 使用 100% 的场景：

    1.1 应用负载（QPS）高

    特征：实例的 QPS（每秒执行的查询次数）高，查询比较简单、执行效率高、优化余地小。

    表现：没有出现慢查询（或者慢查询不是问题主要原因），QPS 和 CPU 使用率曲线变化吻合。

    常见于应用优化过的在线事务交易系统（比如订单系统）、高读取率的热门Web网站应用、第三方压力工具测试中（比如 Sysbench）等。

    1.2. 查询执行成本（查询访问表数据行数 avg_lgc_io）高

    特征：实例的 QPS（每秒执行的查询次数）不高；查询执行效率低、执行需要扫描大量表中数据、优化余地大。

    表现：存在慢查询，QPS 和 CPU 使用率曲线变化不吻合。

    查询执行效率低，为了获得预期的结果集需要访问大量的数据（平均逻辑IO高），在 QPS 并不高的情况下（例如网站访问量不大），也导致实例的 CPU 使用率高。

    注：由于查询执行效率低（查询访问表数据行数多）而导致实例 CPU 使用率高是RDS MySQL非常常见的问题。

    2 解决方法

    DMS 工具提供了几种不错的功能来辅助排查解决实例性能问题，主要有：

    • 实例诊断报告

    • SQL窗口提供的查询优化建议 和 查看执行计划

    • 实例会话

    其中实例诊断报告，是排查和解决 RDS MySQL 实例性能问题的最佳和最快捷工具。无论何种原因导致的性能问题，建议首先参考下实例诊断报告，尤其建议关注诊断报告的 “SQL优化”、”会话列表”、”慢SQL汇总”  部分。

    2.1 应用负载（QPS）高

    这种情况 SQL 查询优化的余地不大，建议考虑从应用架构、实例规格等方面来解决：

    • 升级实例规格，增加 CPU 资源。

    • 增加只读实例，将对数据一致性不敏感的查询（比如商品种类查询、列车车次查询）转移到只读实例上，分担主实例压力。

    • 使用京东云缓存产品，常用的查询结果尽量从缓存中获取，减轻数据库实例压力。

    • 对于查询数据比较静态、查询重复度高、查询结果集小于 1 MB 的应用，考虑开启查询缓存（Query Cache）。

    • 定期归档历史数据、采用分库分表或者分区的方式减小查询访问的数据量。

    • 尽量优化查询，减少查询的执行成本（逻辑IO，执行需要访问的表数据行数），提高应用可扩展性。

      注：能否从开启查询缓存（Query Cache）中获益需要经过测试。

    2.2 查询语句执行成本（查询访问表数据行数）高

    解决的原则：定位效率低的查询，优化查询的执行效率，降低查询执行的成本。

    Step 1

    如果当前 CPU 使用率比较高，可以通过 show processlist; 、show full processlist;

    对于查询时间长、运行状态（State 列）是”Sending data”，”Copying to tmp table”、”Copying to tmp table on disk”、”Sorting result”、”Using filesort” 等都是可能有性能问题的查询（SQL）。

    可以通过执行类似 kill 101031643; 命令来终止长时间执行的会话。

    注1：在 QPS 高导致 CPU 使用率高的场景中，查询执行时间通常比较短，show processlist; 或实例会话中可能会不容易捕捉到当前执行的查询。

    注2：也可以通过命令

    explain select b.* from perf_test_no_idx_01 a, perf_test_no_idx_02 b where a.created_on >= 2015-01-01 and a.detail = b.detail

    来获取该查询 SQL 的执行计划，或者在 SQL 窗口的”执行计划”子标签页获取。

    对于CPU使用率高的问题，建议关注诊断报告的 “SQL优化”、”会话列表”、”慢SQL汇总”  部分（再次强调下）。

    注1：诊断报告同样适用于排查历史实例 CPU 使用率高的问题。

    注2：对于 QPS 高和查询效率低的混合模式导致的 CPU 使用率高问题，建议从优化查询入手。

    3 避免出现 CPU 使用率达到 100% 影响业务的一般原则

    • 设置 CPU 使用率告警，实例 CPU 使用率保证一定的冗余度。

    • 应用设计和开发过程中，要考虑查询的优化，遵守 MySQL 优化的一般优化原则，降低查询的逻辑 IO，提高应用可扩展性。

    • 新功能、新模块上线前，要使用生产环境数据进行压力测试。

    • 新功能、新模块上线前，建议使用生产环境数据进行回归测试。

    • 建议经常关注和使用 DMS 中的诊断报告。

  • DEADLOCK（死锁）

    • mysql 在发现事务中的普通语句存在死锁后，将仅保留一个事务并允许其操作，同时清除其它死锁事务，退出事务状态。
    • 若事务更新语句一次仅涉及一个分区，死锁的行存在于两个分区，那么死锁过程不会立即被检测出来。多个事务的死锁更新会请求锁，直到锁超时，然后由 mysql 通知更新 error。这个 error 结果不会令分区退出事务状态，后续的操作与普通事务相同，分布式数据库将向用户返回锁超时错误。
    • 若事务更新语句一次仅涉及一个分区，死锁的行存在于一个分区，那么死锁过程会立即被检测出来。多个事务的死锁更新，仅有一个被保留，其它事务将被立即回滚。由于事务更新历史中存在跨分区的可能，因此分布式数据库将强行锁定所有未通过 mysql 死锁检测且被清除的事务，强制用户只能进行 rollback 而不得进行其它任何操作。对于那个通过 mysql 死锁检测的事务，后续的操作与普通事务相同，分布式数据库将向用户返回死锁错误，后续非 rollback 语句将向用户返回仅支持 rollback 错误。
    • 若事务更新语句一次涉及多个分区，死锁的行存在于两个分区，那么死锁过程不会立即被检测出来。多个事务的死锁更新会请求锁，直到锁超时，然后由 mysql 通知更新 error。这个 error 结果不会令分区退出事务状态，后续的操作与普通事务相同，分布式数据库将向用户返回数据不一致错误。
    • 若事务更新语句一次涉及多个分区，死锁的行存在于一个分区，那么死锁过程会立即被检测出来。多个事务的死锁更新，仅有一个被保留，其它事务将被立即回滚。由于事务更新历史中存在跨分区的可能，因此分布式数据库将强行锁定所有未通过 mysql 死锁检测且被清除的事务，强制用户只能进行 rollback 而不得进行其它任何操作。对于那个通过 mysql 死锁检测的事务，后续的操作与普通事务相同，分布式数据库将向用户返回数据不一致错误，后续非 rollback 语句将向用户返回仅支持 rollback 错误。

  • Mysql最大连接数

    内存 最大连接数
    1G 300
    2G 600
    4G 1200
    8G 2000
    16G 4000
    32G 8000
    64G 16000
    96G 24000
    128G 32000
    220G 64000

  • Linux 下 MySQL 无法访问问题排查步骤

    Linux 下 MySQL 无法访问问题排查基本步骤
    1 查看 Linux 操作系统是否已经安装了 MySQL
    2 检查状态
    2.1 检测 MySQL 运行状态： service mysqld status
    2.2 启动服务：
    方法一：使用 service 命令启动 MySQL： service mysqld start
    方法二：使用 mysqld 脚本来启动 MySQL：/etc/init.d/mysql start
    方法三：使用 safe_mysqld 实用程序启动 MySQL 服务，此方法可以使用相关参数： safe_mysqld& //使用&表示将safe_mysqld放在后台执行。
    3 修改密码
    mysqladmin -u root password 这里的“密码”为我们欲新设的密码。系统会提示我们输入旧密码（若是 MySQL 刚安装，则默认密码为空）
    4 如果本机可以登陆了，但是其他机器的客户端登陆报错。比如：
    ERROR 1130 (00000): Host ‘xxx.xxx.xxx.xxx’ is not allowed to connect to this MySQL server
    则首先查看了 iptables 的设置，确认开放了 3306 端口：
    iptables -A INPUT -p tcp -m tcp –sport 3306 -j ACCEPT
    iptables -A OUTPUT -p tcp -m tcp –dport 3306 -j ACCEPT
    service iptables save
    5 如果还是无法访问，则可能是 MySQL 的权限问题。则可以通过如下步骤排查：
    在本机登录 mysql -h localhost -u root -p
    show databases;
    use mysql;
    select Host, User, Password from user;
    +———————–+——+——————————————-+
    | Host | User | Password |
    +———————–+——+——————————————-+
    | localhost | root | *18F54215F48E644FC4E0F05EC2D39F88D7244B1A |
    | localhost.localdomain | root | |
    | localhost.localdomain | | |
    | localhost | | |
    +———————–+——+——————————————-+
    可以看到如上结果，只有 localhost 才设置了访问的权限。
    进入 MySQL ，创建一个新用户 user ：
    格式：grant 权限 on 数据库名.表名 用户@登录主机 identified by “用户密码”。
    grant select,update,insert,delete on test.* to test@ip identified by “test”;
    查看结果，执行：
    use mysql;
    select host,user,password from user;
    可以看到在user表中已有刚才创建的user用户。host字段表示登录的主机，其值可以用IP，也可用主机名，将host字段的值改为%就表示在任何客户端机器上能以user用户登录到mysql服务器，建议在开发时设为%。
    修改了权限后需要执行如下语句生效：
    update user set host = ‘%’ where user = ‘test’;
    flush privileges;

  • 国内可用的时间同步服务器

    试了很多，目前能用的基本也就是ntp.api.bz。其他网络上公布的各高校的时间服务器基本不可用

    服务器与时间服务器同步的步骤如下（ubuntu14.0.4）：
    1.安装ntpdate工具
    # sudo apt-get install ntpdate
    2.设置系统时间与网络时间同步
    # ntpdate ntp.api.bz

  • ubuntu14.0.4通过apt-get安装软件时错误问题解决

    ubuntu14.0.4通过apt-get安装软件包时，报以下错误：

    E: 有未能满足的依赖关系。请尝试不指明软件包的名字来运行“apt-get -f install”(也可以指定一个解决办法)。

    经过查找，原来ubuntu系统在新安装好后需要进行一些包的升级和清理工作，不然的话，后续安装各种软件都不顺畅，会出现各种各样的问题。

    需要进行的包升级和清理工作其实很简单，只需要执行以下两条命令即可：

        apt-get -f install #用来升级一些相互依赖的包  
    apt-get autoremove #用来删除一些过时的包

    但是在执行：

    apt-get -f install

    报以下错误：

    Could not calculate the upgrade

A unresolvable problem occurred while calculating the upgrade.

Please report this bug against the 'update-manager' package and include the following error message:
'E:错误，pkgProblemResolver::Resolve 发生故障，这可能是有软件包被要求保持现状的缘故。

    这个问题可能是源的问题导致的，可以通过换源解决
    我把源更换成了sohu的，如下：

    #vi /etc/apt/source.list
#在文件最后添加内容如下：
deb http://mirrors.sohu.com/ubuntu/ trusty main restricted universe multiverse
deb http://mirrors.sohu.com/ubuntu/ trusty-security main restricted universe multiverse
deb http://mirrors.sohu.com/ubuntu/ trusty-updates main restricted universe multiverse
deb http://mirrors.sohu.com/ubuntu/ trusty-proposed main restricted universe multiverse
deb http://mirrors.sohu.com/ubuntu/ trusty-backports main restricted universe multiverse
deb-src http://mirrors.sohu.com/ubuntu/ trusty main restricted universe multiverse
deb-src http://mirrors.sohu.com/ubuntu/ trusty-security main restricted universe multiverse
deb-src http://mirrors.sohu.com/ubuntu/ trusty-updates main restricted universe multiverse
deb-src http://mirrors.sohu.com/ubuntu/ trusty-proposed main restricted universe multiverse
deb-src http://mirrors.sohu.com/ubuntu/ trusty-backports main restricted universe multiverse

  • [转]zookeeper应用场景

    分布式系统的运行是很复杂的，因为涉及到了网络通信还有节点失效等不可控的情况。下面介绍在最传统的master-workers模型，主要可以会遇到什么问题，传统方法是怎么解决以及怎么用zookeeper解决。

    场景1：Master节点管理
    集群当中最重要的是Master，所以一般都会设置一台Master的Backup。

    Backup会定期向Master获取Meta信息并且检测Master的存活性，一旦Master挂了，Backup立马启动，接替Master的工作自己成为Master，分布式的情况多种多样，因为涉及到了网络通信的抖动，针对下面的情况:

    Backup检测Master存活性传统的就是定期发包，一旦一定时间段内没有收到响应就判定Master Down了，于是Backup就启动，如果Master其实是没有down，Backup收不到响应或者收到响应延迟的原因是因为网络阻塞的问题呢？Backup也启动了，这时候集群里就有了两个Master，很有可能部分workers汇报给Master，另一部分workers汇报给后来启动的Backup，这下子服务就全乱了。
    Backup是定期同步Master中的meta信息，所以总是滞后的，一旦Master挂了，Backup的信息必然是老的，很有可能会影响集群运行状态。
    解决问题:

    Master节点高可用，并且保证唯一。
    Meta信息的及时同步

    zookeeper Master选举

    zookeeper会分配给注册到它上面的客户端一个编号，并且zk自己会保证这个编号的唯一性和递增性，N多机器中只需选出编号最小的Client作为Master就行，并且保证这些机器的都维护一个一样的meta信息视图，一旦Master挂了，那么这N机器中编号最小的胜任Master，Meta信息是一致的。

    场景2：配置文件管理

    集群中配置文件的更新和同步是很频繁的，传统的配置文件分发都是需要把配置文件数据分发到每台worker上，然后进行worker的reload，这种方式是最笨的方式，结构很难维护，因为如果集群当中有可能很多种应用的配置文件要同步，而且效率很低，集群规模一大负载很高。还有一种就是每次更新把配置文件单独保存到一个数据库里面，然后worker端定期pull数据，这种方式就是数据及时性得不到同步。

    解决问题:

    统一配置文件分发并且及时让worker生效

    zookeeper发布与订阅模型
    发布与订阅模型，即所谓的配置中心，顾名思义就是发布者将数据发布到ZK节点上，供订阅者动态获取数据，实现配置信息的集中式管理和动态更新。例如全局的配置信息，服务式服务框架的服务地址列表等就非常适合使用。

    场景3：分布式锁

    在一台机器上要多个进程或者多个线程操作同一资源比较简单，因为可以有大量的状态信息或者日志信息提供保证，比如两个A和B进程同时写一个文件，加锁就可以实现。但是分布式系统怎么办？需要一个三方的分配锁的机制，几百台worker都对同一个网络中的文件写操作，怎么协同？还有怎么保证高效的运行？
    解决问题:

    高效分布式的分布式锁

    zookeeper分布式锁

    分布式锁主要得益于ZooKeeper为我们保证了数据的强一致性，zookeeper的znode节点创建的唯一性和递增性能保证所有来抢锁的worker的原子性。

    场景4：集群worker管理

    集群中的worker挂了是很可能的，一旦workerA挂了，如果存在其余的workers互相之间需要通信，那么workers必须尽快更新自己的hosts列表，把挂了的worker剔除，从而不在和它通信，而Master要做的是把挂了worker上的作业调度到其他的worker上。同样的，这台worker重新恢复正常了，要通知其他的workers更新hosts列表。传统的作法都是有专门的监控系统，通过不断去发心跳包(比如ping)来发现worker是否alive，缺陷就是及时性问题，不能应用于在线率要求较高的场景
    解决问题:

    集群worker监控

    zookeeper监控集群

    利用zookeeper建立znode的强一致性，可以用于那种对集群中机器状态，机器在线率有较高要求的场景，能够快速对集群中机器变化作出响应。

    转自：http://www.cnblogs.com/likehua/p/3999600.html

  • Linux ssh无法登陆

    安装了一个centos，设置好了网络，配好了dns，可以ping同其它机器，其他机器也可以ping通该机器，当我通过ssh连接到这个机器上时，提示：
    Connecting to 192.168.100.151:22…
    Could not connect to ‘192.168.100.151’ (port 22): Connection failed.

    第一反应是网络不通，又重新进行测试，可是，发现网络没有问题。继续排查其他问题，

    chkconfig –list | grep ssh
    发现全部是off，一下子知道问题的所在了，原来是ssh服务没有启动

    service sshd start

    再通过客户端ssh连接，登陆成功。

    通过这个事情可以知道，能ping通和是否SSH是没关系的。好多人都有这个误区。
    ssh和ping协议不同，是不同的服务。两者不在一个网络层级，两者使用的协议不一样。
    ping通不一定可以SSH，可以SSH不一定能ping通。ping通仅代表目标主机可以对icmp包做出响应。网络设置禁ping了，一样可以ssh。

    有点拗口，但是事实

Copyright © 2014-2025 奋奋的愤愤 | 京ICP备14029030号-1