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

1. 结论

声明：这里给出的测试数据不具有一般性，仅供参考。测试与数据本身特性有很大关系，本文使用InnoDB的redo log作为测试数据。

* 改变ssh加密算法，可以让速度更快；通常，越弱的加密算法，速度越快

* 通常压缩会降低scp速度，但这与数据类型有很大关系，对压缩率非常高的数据启用压缩，可以加速

* 压缩级别对传输效率影响很小

* 用于完整性校验的不同MAC( message authentication code)算法，对性能约有10%-20%的影响。

所以，简单尝试如下，让你的SCP速度double一下：

注：启用压缩使用参数： -o "Compression yes"

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

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

原始数据：scp_speed.txt

[......]

Read more

0. 为什么写这篇博客

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

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

[......]

Read more

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

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

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

如果顺利的话，就结束了。不过在我的发行版会报如下错误：[......]

Read more

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

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

Read more

从那次Z9来杭州，快四年了，最近有两个老同学都问我杭州好不好，去杭州工作怎样之类的，这里说说这四年对杭州的感受吧。都是些主观认识，谨慎参考。

在北京念书七年，因为种种“机缘巧合”，最终来了杭州。之前从不曾想过会因为工作来杭州，不过也没有想到这个城市给了我这么多惊喜。

1. 工作在杭州

先说工作，毕竟是因为这个原因来到这里的。相比北京，杭州的公司是要少很多的，所以工作机会也相对较少。一线的互联网公司，主要就是阿里巴巴和网易杭州研究院，不像北京几乎所有的公司都会在北京有办公地点，阿里在北京也有很大的办公地点。很少有人能够一辈子只在一家公司服务的，所以当打算换工作的时候，这就成为一个劣势了，选择较少，机会也较少。不过如果是电子商务的话，杭州的氛围还是很好的，我所知道的很多人/公司都在做围绕此创业(例如我不喜欢，但是很看好的蘑菇街)。

当然，杭州工作机会少，这是相对而言，如果不跟北上广深，杭州的工作环境应该也算是非常好的。

2. 生活在杭州

在生活方面，如果再跟北京比的话，杭州是分分钟就秒杀了北京。杭州城区不算大，周末如果朋友想聚会的话，一般不会超过半小时的车程，打个牌、吃个饭什么的非常方便。记得刚到杭州那会儿，每隔周五晚上都是有小赌怡情的牌局，现在一个个都结婚生小孩了，聚会的时间少了很多。以前在北京，同学聚会还是比较麻烦的，东西三环就很远了，更别说石景山了，所以北京的同学聚会貌似也基本上跟我去北京出差的频率差不太多，所以总能赶上。杭州周末聚会有更多的选择，可以去龙井/梅家坞/青之坞，环境都非常好，而且离城西也非常近，七八个好友玩个三国杀、吃个饭、爬个山都很惬意。

如果你喜欢运动，杭州也不会让你失望。西湖几乎四面环山，山不是很高，不过很长，适合周末慢慢爬。登山的路线也有很多，春秋季都很漂亮，很多杭州久住的人都喜欢爬山。[......]

Read more

本文是一篇写给《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或者开发人员，并进行了多次(交叉)校对，是一次高要求、高质量的翻译，不会让你失望。[......]

Read more