orczhou.com

MySQL

  • 加速scp传输速度

    ·

    admin

    当需要在机器之间传输400GB文件的时候，你就会非常在意传输的速度了。默认情况下(约125MB带宽，网络延迟17ms，Intel E5-2430，本文后续讨论默认是指该环境)，scp的速度约为40MB，传输400GB则需要170分钟，约3小时，如果可以加速，则可以大大节约工程师的时间，让攻城师们有更多时间去看个电影，陪陪家人。

    1. 结论：使用如下命令可以让scp速度提升50~150%

    scp -r -c arcfour128 ...
scp -r -c aes192-cbc ...
scp -r -c arcfour128 -o "MACs umac-64@openssh.com" ...

    原因概述：

    • 通常，更弱的加密算法，scp传输速度更快。这里的测试看到加密算法-c arcfour128或-c aes192-cbc可以大大加速scp传输
    • 用于完整性校验的MAC( message authentication code)算法，对性能约有10%-20%的影响。这里的测试看到-o "MACs umac-64@openssh.com"是不错的选择。
    • 这里测试看到，scp内置的传输压缩并没有什么效果。事实上，合理的使用压缩工具是可以进一步降低传输时间的，具体的参考：使用tar+lz4/pigz+ssh更快的数据传输。你可以通过参数-o "Compression yes"来启用压缩来观察实际案例中的情况。

    声明：测试与数据本身特性有很大关系，本文使用InnoDB的redo log作为测试数据。

    2. 测试数据：加密算法和压缩的影响

    这里对比了12种ssh中实现的加密算法和是否使用压缩的传输效率，测试文件使用的是InnoDB的1GB*4的日志文件(注意：不同类型的文件测试结果会很不同)，这里纵坐标单位为MB/s，数据分为压缩传输和不压缩传输两组：

    screen-scp-compare-cipher-compression

    原始数据：scp_speed.txt

    (more…)

  • Linux如何统计进程的CPU利用率

    ·

    admin

    0. 为什么写这篇博客

    Linux的top或者ps都可以查看进程的cpu利用率，那为什么还需要了解这个细节呢。编写这篇文章呢有如下三个原因：

    * 希望在脚本中，能够以过”非阻塞”的方式获取进程cpu利用率
* ps无法获得进程当前时刻的CPU利用率;top则需要至少1秒才能获得进程当前的利用率
* * 好奇

    (more…)

  • 编译tcprstat

    ·

    orczhou

    在RHEL6.1(Red Hat Enterprise Linux Server)上静态编译并不容易。tcprstat编译也有这个问题。

    源码下载：tcprstat@Launchpad 命令：bzr branch lp:tcprstat

    编译命令：./bootstrap && ./configure && make

    如果顺利的话，就结束了。不过在我的发行版会报如下错误： (more…)

  • 如何从MySQL/InnoDB数据文件中的恢复数据

    ·

    orczhou

    在上上周给下厨房做过一次数据恢复(故障回顾：故障发生的技术总结 致歉信)，恢复使用了开源工具Percona Data Recovery Tool for InnoDB(后面简称PDRTI)，这里分享一下期间的注意事项，和遇到MySQL数据丢失的一些应对。

    本文主要介绍在使用Percona Data Recovery Tool for InnoDB时候的一些注意事项，并不包括具体的step by step的使用步骤，使用文档可以参考：Reference Manual and Documentation。 (more…)

  • 《高性能MySQL》第三版

    ·

    orczhou

    本文是一篇写给《HPM 3rd 中文版》的软文，慎入。《HPM 3rd 中文版》已经开始正式发售了，不是预售：亚马逊 china-pub 当当网

    从去年5月开始，与宁海元、翟卫祥、彭立勋、刘辉一起利用业余时间，经历了翻译，校对，校对，再校对，交叉校对，再交叉校对，到前两天亚马逊上正式开售(不是预售了)，前前后后也历经了大概一年。

    在过去的两三年，MySQL的生态圈发生了很大的变化，出现了MariaDB，Percona/XtraDB等等分支，与官方的版本产生了一些竞争。目前为止这些竞争还是比较良性的，都大大推动了MySQL在各个方面的改进，包括MySQL的性能和新的功能，这期间在社区对于InnoDB的改进(例如XtraDB)，推进了MySQL/Oracle快速的推进了InnoDB Plugin的发展；MariaDB在优化器方面也做了很多工作，对应的MySQL/Oracle在5.6之后的版本也做了很多Server层(例如优化器、Group Commit等)的改进。

    虽然经历了收购的风波，但在竞争压力下，过去两三年仍然是MySQL/MariaDB快速发展的时期。08年High Performance MySQL(简称HPM)发布第二版，时隔四年发布了第三版，第三版中新增了分区、视图、存储过程方面的改进，高可用、集群和复制方面的改进，优化器全文索引等改进，SSD和多核CPU利用方面的改进，在线备份和恢复的工具等。是一本非常值得阅读的MySQL书籍。

    对于专注数据库领域的人来说，如果习惯阅读英文版本的，依旧推荐阅读英文版本，在亚马逊上可以买到HPM 3rd影印版的。如果不太习惯阅读英文版本的，我仍然强烈推荐阅读影印版，虽然这样可能会花更多的时间，但是可以大大锻炼一下自己的英文能力，相信你不会因为这个”浪费”时间而后悔的。

    如果，你喜欢阅读中文书籍，或者希望能够快速阅读，那么这次翻译的HPM 3rd会是很好的选择。这次译者都是专业/一线的MySQL DBA或者开发人员，并进行了多次(交叉)校对，是一次高要求、高质量的翻译，不会让你失望。 (more…)

  • 案例：MySQL优化器如何选择索引和JOIN顺序

    ·

    orczhou

    本文通过一个案例来看看MySQL优化器如何选择索引和JOIN顺序。表结构和数据准备参考本文最后部分”测试环境”。这里主要介绍MySQL优化器的主要执行流程，而不是介绍一个优化器的各个组件(这是另一个话题)。

    我们知道，MySQL优化器只有两个自由度：顺序选择；单表访问方式；这里将详细剖析下面的SQL，看看MySQL优化器如何做出每一步的选择。

    explain 
select * 
from 
  employee as A,department as B 
where 
      A.LastName = 'zhou' 
  and B.DepartmentID = A.DepartmentID 
  and B.DepartmentName = 'TBX';

    1. 可能的选择

    这里看到JOIN的顺序可以是A|B或者B|A，单表访问方式也有多种，对于A表可以选择：全表扫描和索引`IND_L_D`(A.LastName = ‘zhou’)或者`IND_DID`(B.DepartmentID = A.DepartmentID)。对于B也有三个选择：全表扫描、索引IND_D、IND_DN。

    2. MySQL优化器如何做

    2.1 概述

    MySQL优化器主要工作包括以下几部分：Query Rewrite(包括Outer Join转换等)、const table detection、range analysis、JOIN optimization(顺序和访问方式选择)、plan refinement。这个案例从range analysis开始。

    2.2 range analysis

    这部分包括所有Range和index merge成本评估(参考1 参考2)。这里，等值表达式也是一个range，所以这里会评估其成本，计算出found records(表示对应的等值表达式，大概会选择出多少条记录)。

    本案例中，range analysis会针对A表的条件A.LastName = ‘zhou’和B表的B.DepartmentName = ‘TBX’分别做分析。其中： (more…)