MySQL

  • 前面一篇介绍了如何最大限度的榨取SCP的传输速度,有了这个基础,就可以进一步的使用压缩来加速传输速度了。只使用scp,传输速率最快约90MB,本文通过压缩将把最快传输速率提升到约250MB/s(包括解压的过程)。

    1. 结论

    使用tar+lz4+ssh的方式能够获得最大的传输性能:

    time tar -c sendlog/|pv|lz4 -B4|ssh -c arcfour128 \ -o"MACs umac-64@openssh.com" 10.xxx.xxx.36 "lz4 -d |tar -xC /u01/backup_supu" 3.91GiB 0:00:16 [ 249MiB/s] real 0m16.067s user 0m15.553s sys 0m16.821s

    249MB/s,妥妥的。是最原始scp(40MB/s)的6倍,原来400GB传输需要约3小时,现在只需要27分钟了。

    注1:lz4在解压方面的优异表现,使得他在本案例中非常重要。如果无需解压的传输,则可以考虑使用pigz/pbiz2

    注2:使用pv观察,网络流量约80MB,所以使用nc替换ssh并不会有明显的性能提升

    注3:lz4压缩使用-B4(64KB块大小),解压使用-B7(4MB块大小),是本案例的测试最优值 (more…)

  • 加速scp传输速度

    ·

    当需要在机器之间传输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…)
  • 0. 为什么写这篇博客

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

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

    (more…)

  • 编译tcprstat

    ·

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

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

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

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

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

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

  • 《高性能MySQL》第三版

    ·

    本文是一篇写给《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…)