testing-04

简单生活

  • 概述与结论

    Oracle在去年引入了ECPU(相对于之前的OCPU),在前面介绍了什么是ECPU,本文则从性能的角度,看看ECPU与之前的OCPU的对比,以验证ECPU就是对应了其他云厂商vCPU的概念。

    这里选择了4 ECPU的规格MySQL.4(内存为32GB),以及 2 OCPU的规格MySQL.VM.Standard.E4.2.32GB进行对比。从如下的性能趋势图可以看到,两者表现出了几乎相同的性能。从价格上,两者的单价分别是SGD 0.050578 vs 0.055552 ( 计算0.052512+0.00304内存 ),即ECPU在该规格下,ECPU拥有几乎相同的CPU和内存,以及性能表现的情况下,ECPU规格要比OCPU规格价格要低8.9%

    (more…)
  • 一个Slide介绍中,在Sysbench测试中可以通过hook的方式对一些MySQL报错进行捕获,以避免测试中断。但是做了一些搜索,对该能力并没有文档描述,故做了一些测试,以验证该能力。

    在前面的文章“Sysbench压测MySQL中遇到的”Duplicate entry”问题”中,较为详细的分析了在使用了--skip_trx=on后 ,Sysbench(版本1.0.20)在测试中遇到的”Duplicate entry”问题。也提到了,可以在脚本中添加hook的方式解决,不过之前并没有对这个方案进行验证。

    在测试脚本中使用hook的方案,在sysbench的文档中并没有找到详细的说明,这里将对这个方案做一个使用说明,并验证其有效性。我们将分两组对比测试,验证新增hook的有效性,以及新增hook后,对测试结果是否对性能有影响。

    测试结果概述

    Sysbench的该能力并没有在文档中找到说明,只是在一个Slide中看到的。本文的测试验证了如下内容:

    • 在测试lua脚本中,可以使用hook有效的避免”Duplicate entry”等报错带来的测试中断问题
    • 使用了hook之后,测试前后性能并没有观测到差异(可以认为,一般来说,发生错误的情况并不多)

    所以,后续测试中,如果不可避免的会遇到”Duplicate entry”报错(或其他报错)时,将使用hook的方式来避免。

    如何修改测试脚本

    具体的,我们在原来的oltp_read_write(sysbench 1.0.20版本)脚本中新增如下代码片段:

    function sysbench.hooks.sql_error_ignorable(err)
      if err.sql_errno == 1062 then -- ER_DUP_ENTRY
        -- do nothing
        return true
      end
    end

    完整的代码可以参考:oltp_read_write_with_hooks.lua

    具体的diff文件参考如下:

    --- /usr/share/sysbench/oltp_read_write.lua
    +++ oltp_read_write_with_hooks.lua
    @@ -21,6 +21,13 @@
    
     require("oltp_common")
    
    +function sysbench.hooks.sql_error_ignorable(err)
    +  if err.sql_errno == 1062 then -- ER_DUP_ENTRY
    +    -- do nothing
    +    return true
    +  end
    +end
    +
     function prepare_statements()
        if not sysbench.opt.skip_trx then
           prepare_begin()

    测试说明

    这里依旧使用oltp_read_write负载进行测试,测试时使用了参数 --skip_trx=on --db-ps-mode=disable --rand-type=uniform ,其中参数--skip_trx=on会带来”Duplicate entry”报错,并导致测试被终止(详细原因分析参考:Sysbench压测MySQL中遇到的”Duplicate entry”问题)。测试分两组,一组是使用原始的oltp_read_write脚本进行测试;另一组,则在脚本中新增上述hook代码。

    而后观测:

    • 使用了hook后,sysbench是否还会因为”Duplicate entry”被终止;
    nohup ./sysbench_auto.sh -l ./oltp_read_write_with_hook.lua -hYOUR_HOST -uYOUR_USERNAME -pYOUR_PASSWORD > sysbench_with_hook_with_skip.log 2>&1 &
    • 使用hook,与不使用hook,对测试结果是否有影响。
    nohup ./sysbench_auto.sh -hYOUR_HOST -uYOUR_USERNAME -pYOUR_PASSWORD > sysbench_no_hook_with_skip.log 2>&1 &

    这里的sysbench_auto.sh是一个自己编写的自动化的sysbench测试脚本。会自动化的、顺序的进行多个不同并发下的性能测试。

    测试结果详情

    没有使用hook的测试中,注意到,在并发度为48、96、128、192时候,测试被终止,而观测日志也看到了是因为“Duplicate entry”所导致的。

    threads|transactions| queries| time |avg/Latency|95%/Latency
          4|       20311|  365598|300.05|      59.09|      66.84
          8|       38195|  687510|300.04|      62.84|      71.83
         16|       71296| 1283328|300.07|      67.33|      77.19
         24|      101911| 1834398|300.05|      70.65|      81.48
         32|      131859| 2373462|300.06|      72.81|      84.47
         48|           0|       0|  0.00|       0.00|       0.00
         64|      233840| 4209120|300.09|      82.12|     101.13
         96|           0|       0|  0.00|       0.00|       0.00
        128|           0|       0|  0.00|       0.00|       0.00
        192|           0|       0|  0.00|       0.00|       0.00

    具体报错:

    FATAL: mysql_drv_query() returned error 1062 (Duplicate entry '876663' for key 'sbtest3.PRIMARY') for query

    在使用了hook的测试中,注意到,测试顺利的完成了,并没有被终止,而观察日志,也可以看到,期间也是遇到了Duplicate entry报错的,但因为hook的处理,测试并没有终止。

    threads|transactions| queries| time |avg/Latency|95%/Latency
          4|       19547|  351846|300.06|      61.40|      71.83
          8|       37524|  675432|300.06|      63.97|      74.46
         16|       70847| 1275246|300.05|      67.76|      78.60
         24|      102541| 1845738|300.06|      70.22|      81.48
         32|      132424| 2383632|300.07|      72.50|      86.00
         48|      187065| 3367170|300.06|      76.98|      92.42
         64|      234717| 4224923|300.07|      81.81|      99.33
         96|      308744| 5557409|300.06|      93.28|     118.92
        128|      341177| 6141186|300.09|     112.57|     147.61
        192|      364561| 6562115|300.10|     158.03|     211.60

    两组测试性能的对比

    根据如上性能测试数据,对QPS(Queries Per Second)进行对比:

    可以看到,整体性能波动非常小,优势在较高并发时,性能差异都小于1%;从趋势图上也能够看出来,两者几乎是重合的。

    更多测试原始数据

    2024-03-26@Benchmark on sysbench with or without hook
    data on rds_m6i_xlarge_no_hook_with_skip
    instance configuration
    host : rds_m6i_xlarge_no_hook_with_skip 
    sub_dir : rds_m6i_xlarge_no_hook_with_skip 
    ins_code : m6i.xlarge 
    ha_type : ha 
    region : tokyo 
    storage_size : 100 
    iops : 3000 
    
    sysbench for host :multiaz.cjzowaj9vqpd.ap-northeast-1.rds.amazonaws.com
    threads|transactions| queries| time |avg/Latency|95%/Latency
          4|       20311|  365598|300.05|      59.09|      66.84 
          8|       38195|  687510|300.04|      62.84|      71.83 
         16|       71296| 1283328|300.07|      67.33|      77.19 
         24|      101911| 1834398|300.05|      70.65|      81.48 
         32|      131859| 2373462|300.06|      72.81|      84.47 
         48|           0|       0|  0.00|       0.00|       0.00 
         64|      233840| 4209120|300.09|      82.12|     101.13 
         96|           0|       0|  0.00|       0.00|       0.00 
        128|           0|       0|  0.00|       0.00|       0.00 
        192|           0|       0|  0.00|       0.00|       0.00 
    
    data on rds_m6i_xlarge_with_hook_with_skip
    instance configuration
    host : rds_m6i_xlarge_with_hook_with_skip 
    sub_dir : rds_m6i_xlarge_with_hook_with_skip 
    ins_code : m6i.xlarge 
    ha_type : ha 
    region : tokyo 
    storage_size : 100 
    iops : 3000 
    
    sysbench for host :multiaz.cjzowaj9vqpd.ap-northeast-1.rds.amazonaws.com
    threads|transactions| queries| time |avg/Latency|95%/Latency
          4|       19547|  351846|300.06|      61.40|      71.83 
          8|       37524|  675432|300.06|      63.97|      74.46 
         16|       70847| 1275246|300.05|      67.76|      78.60 
         24|      102541| 1845738|300.06|      70.22|      81.48 
         32|      132424| 2383632|300.07|      72.50|      86.00 
         48|      187065| 3367170|300.06|      76.98|      92.42 
         64|      234717| 4224923|300.07|      81.81|      99.33 
         96|      308744| 5557409|300.06|      93.28|     118.92 
        128|      341177| 6141186|300.09|     112.57|     147.61 
        192|      364561| 6562115|300.10|     158.03|     211.60 
    
  • 概述

    最近,组织了一个24点SQL编程的比赛,笔者是主办方,也是评委。既然是做评委,自己也先挑战了一下,因为对MySQL更为熟悉,故选择了MySQL作为编程SQL。周末花了一些时间挑战一下,这里记录一下自己的解法以及思路。

    24点问题,是一个有趣的问题。他的扩展问题(即把牌数/计算值进行更改),很可能也是一个NP-完全问题,他与subset sum problem问题有一些些类似。如果参考subset sum problem问题的解法(例如做一些动态优化解),则可以实现还比较优的解。

    不过,这一次的比赛,是要求在一条SQL里面实现,并且限制了SQL长度为10KB,所以就大大限制了实现的方式。不过最为直接的两个思路还是,“暴力的枚举”计算和“预计算结果再做哈希求解”。即便如此,在写SQL过程中,还是遇到了如下挑战需要解决:

    • 使用单条SQL进行暴力枚举的时候,如何在没有for/while等循环控制,如何遍历所有的可能性
    • 哈希数组的空间占用比较大,可能会超过10KB,如何去压缩或者减少需要构建的数组

    另外,实现过程中,可能涉及到浮点数计算、除数为零等问题的处理,也是非常容易出错的。

    另一个角度,这些,也是这道题,有趣的地方。

    “一条SQL算24点”的题目回顾

    这次的题目,与一般意义上24点略有一些不同:

    • 首先,要求一条SQL内完成;对于穷举、哈希的实现本身就有挑战了。需要对SQL比较熟悉,否则很难写出正确、高性能的SQL
    • SQL大小限制为10KB,所以,并不能简单的穷举,简单的CASE WHEN 10KB肯定是不够的
    • 4个数字,被限制为1~10,而不是13,所以搜索空间是相对来说少了一些的,让10KB以内哈希成为可能
    (more…)
  • Protected: Interview

    ·

    This content is password protected. To view it please enter your password below:

  • 杨梅树

    ·

    酸甜的杨梅,我是很喜欢吃的。这些年来到浙江后,注意到这里的杨梅比其他地方更多一写。这也算是中国,或者说江南的一大特色吧,北方人大概是吃得少的。不过因为有“望梅止渴”的故事,杨梅在中国的知名度是非常高的。

    根据Wikipeida的信息(参考),杨梅主要分布在中国的东南方地区、日本、菲律宾、朝鲜/韩国等地。在中国,又属浙江特别多,浙江又以仙居杨梅最为有名。

    杨梅酸中带甜,非常好吃。但是,杨梅的运输是非常困难的。从树上采摘下来,最佳的食用时间也就是1~3天,再长时间由于水分的流逝,味道就没那么鲜美了。再者,因为杨梅表面非常松软,而如果运输过程稍有颠簸挤压,则非常容易压坏,影响口感,也容易变质。

    所以,实际的情况就是,杨梅的上市几乎只有一个月时间,也就是说,每年只有一个月时间,也只在中国的东南方的一些城市能够吃到最好的杨梅。

    鲁彦曾经下过一篇散文《故乡的杨梅》,是啊,对于浙江人,身在外地,对于杨梅的怀念,大概就是故乡味道的怀念吧。

    前年底,妈妈离开了我们。当时,有几天闲在家里,我就和爸爸说,来年开春,我打算在后院种一颗杨梅树。去年,我们移植了一颗小的杨梅树,大概是因为种植的时候耽搁了几天。杨梅树没能够活下来。今年,我们又移植了一颗,这次的树更大一些,种植的时候我们也更小心,也了解了很多种植的知识,希望这颗杨梅树能够活下来,过几年能够吃上自己种的杨梅树。

    对于自己,对于孩子们,也希望让故乡,多一份味道。

    2022年,团队outing,在仙居的山上摘杨梅
    后院新种的杨梅树@共青城

  • Protected: 2024年春节

    ·

    This content is password protected. To view it please enter your password below: