testing-04

Linux

  • 虽说标题是“Alibaba Cloud Linux”,不过对于Amazon Linux、华为云EulerOS/openEuler、TencentOS等都均适用。

    1. 添加自己的密钥对,方便本地快速登录:

    vi .ssh/authorized_keys

    2. 修改 sshd 配置,防止ssh会话经常断开:

    vim /etc/ssh/sshd_config
    
    ...
    ClientAliveInterval 30
    ClientAliveCountMax 3
    ...
    
    service sshd restart

    3. 修改本地的环境变量,包括语言、vim配置等

    vi .bash_profile 
    # 很多程序的错误提示,还是希望能够是英文的
    export LANG=en_US.UTF-8
    export LANGUAGE=en_US
    
    # root账号下,经常使用vi,其实想要vim
    # 当然,用root账号是非常不好的习惯
    alias vi="vim"
    
    
    # 配置一些vim的初始化的配置
    vi ~/.vimrc
    set number
    set tabstop=4
    set shiftwidth=4
    set expandtab
    syntax on

    4. 个人使用的省钱大法:在主机不使用的时候,可以使用“节省停机模式”关闭ECS。这样ECS最贵的计算和内存资源将不再收费。可以大大降低个人在测试使用的时候成本。目前,AWS、华为云、腾讯云等基本都支持该能力。缺点在于,每次重启后,可能会重新分配新的公网IP,使用上略有不便。不过,如果你已经有99块的ECS的话,每次以此为跳板机,使用内网IP跳转也是一个办法。

  • 在你的程序(或者工程)中,如果编译阶段需要检测当前环境中是否存在MySQL客户端相关的库文件时,你可以使用Autoconf来帮你完成这个工作,轻盈、优雅、无痛。阅读本文需要了解简单GNU Autoconf使用。

    1. 本文的目标

    目的:编译时,根据configure参数(如果有–with-mysql),选择性编译对应的MySQL相关的功能。

    实现:使用已经写好的m4脚本:ax_lib_mysql.m4

    2. 如何利用Autoconf实现

    大部分你想到的事情都已经有人做过尝试了。这件事情也不例外,Autoconf中有很多脚本和指令帮你做事情。这里,需要使用ax_lib_mysql.m4来帮助我们。先把该文件放到程序/工程目录中,并在configure.ac中新增如下指令来检测MySQL库文件和版本:

    m4_include(ax_lib_mysql.m4)
    AX_LIB_MYSQL()
    AM_CONDITIONAL(BUILD_MYSQL_SUPPORT, test x$MYSQL_VERSION != x)

    说明:AX_LIB_MYSQL()设置了三个变量,可以在Makefile.am中直接使用,分别是MYSQL_CFLAGS、MYSQL_LDFLAGS、MYSQL_VERSION,另外还会在config.h中预定义宏HAVE_MYSQL;AM_CONDITIONAL(…)则会根据是否需要开启MySQL支持,来设置变量BUILD_MYSQL_SUPPORT,这个变量可以在Makefile.am中使用。

    在程序源代码中一般有两种方式可以获取HAVE_MYSQL宏的方式:一个是直接包含config.h;另一个是在你程序的CFLAGS中新增-DHAVE_MYSQL。(注意:有的变量是可以在Makefile.am中使用,有的则是可以在C源代码中使用) (more…)

  • 前面一篇介绍了如何最大限度的榨取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…)

  • TCP/IP重传超时–RTO

    ·

    概述:本文讨论主机在发送一个TCP数据包后,如果迟迟没有收到ACK,主机多久后会重传这个数据包。主机从发出数据包到第一次TCP重传开始,RFC中这段时间间隔称为retransmission timeout,缩写做RTO。本文会先看看RFC中如何定义RTO,然后看看Linux中如何实现。本文旨在分享:当遇到了TCP层问题改如何去查找、阅读文档,该如何去在Linux源码中寻求答案。

    1. 起源

    在分析MySQL Semi-sync故障时,我们用Tcpdump+Wireshark(感谢淘宝雕梁)抓住当时的网络包传送细节,观察到了一次TCP重传最终导致了Semi-sync超时:

    第一次传输 13:55:11.893291 master => slave Binlog pos:319890197 重传: 13:55:12.094596 master => slave Binlog pos:319890197

    看到两次传送间隔约201毫秒,即第一次传输201毫秒后,还没有收到ACK响应,TCP认为传输超时,开始重传。

    疑问:host和host之间的RTT大约是0.5毫秒,为什么第一次重传需要等200毫秒?(我希望是<20ms)socket程序可以配置吗RTO吗?TCP有参数可配置RTO吗?

    2. Google/书籍/RFC

    翻开TCP/IP详解找到关于TCP Retransmission章节,较详细的介绍TCP的超时机制,书中是个概述,于是又找到RFC1122。

    RFC1122的4.2.2.15和4.2.3.1都介绍了Retransmission Timeout的处理(说来惭愧,这是第一次阅读TCP相关RFC)。

    RFC中搜索Retransmission发现RFC 793 1122 2988 6298都有对重传算法、和初次重传超时的描述。于是开始阅读这个四个RFC,耗时约2小时,了解了大致的重传超时算法。 (more…)