Skip to content

Progress Report 2019.01.13

Jump to bottom
TimHe edited this page Feb 10, 2019 · 1 revision

1.阅读论文Understanding Real-World Timeout Problems in Cloud Server Systems

  • 会议：IC2E-2018（IEEE International Conference on Cloud Engineering CCF列表里没有，好像不是顶会）
  • 作者：Xiaohui Gu组, Shan Lu

这篇文章专门去调研了分布式软件（MapReduce、HDFS、Spark、Yarn...共11个）中和Timeout有关系的bug（156个，来源：jira，关键词搜索法：‘timeout’）。主要是从这些bug的root cause、对系统造成的影响、timeout bug诊断的难易程度这三个方面进行调研。

一、root cause：分了5个大类：

  1. misused timeout value（47%）
    指timeout的值设定的不合适、配置文件中的timeout没有被读入到代码中去等这种仅和值的大小有关系的bug

这一种在我调研的性能bug中有遇到过，一般是timeout的值是hard-code的，发现hard-code的值在某些用户那里影响性能，所以变为configurable

  1. missing timeout checking（31%）
    指该有timeout检查的地方却没有设置，比如一个可能会产生死锁的地方没有设置timeout、一个网络通信没有设置timeout等

  2. unnecessary timeout protection（12%）
    指本不需要进行timeout检查却多做了timeout检查

这一种在我调研的性能bug中有遇到过，多余的timeout检查会造成性能问题，例如：通过flag检查就能做到的事情却非要用timeout检查实现就会造成客户busy waiting一个timeout的时间。

  1. improper timeout handling（5%）
    指timeout&retry反复次数过多或过于频繁，或当timeout后进行了不正确的handling操作

  2. clock drifting（5%）
    分布式系统独有的一种bug，是由于分布式系统中使用了‘异步时钟’导致timeout出现的时间比预想中的早或晚

二、影响

屏幕快照 2019-01-13 下午6.07.44.png

只是单纯做了上图这个分类，没有更深入的分析什么rootcause更容易导致什么影响。

三、timeout类bug诊断的难易程度

屏幕快照 2019-01-13 下午6.12.41.png

得出结论：“we found only 40 out of 156 timeout bugs report the correct error message, which makes it difficult to diagnose the timeout bugs.”

也只是从这些bug报出来的error message这个角度来调研的。

这篇文章后面比较单薄，连分析一下哪里可以进一步做工作以更好的诊断timeout类型的bug都没有。不过主要的贡献还是让人们学习到了timeout bug的root cause。这篇文章大量的篇幅都是举例子说明每种root cause

**2.**又看了apache httpd & apache tomcat的总共20个性能issue，根据这篇文章“An Empirical Study on Crash Recovery Bugs in Large-Scale Distributed Systems”调研的方法，补全了一些以前遗漏的没有统计的信息；重新审视、refine以前总结的那些root cause

每次多看一些bug，对以前总结出得那些root cause都要重新精化。

tomcat 也可以理解成为是web服务器

Clone this wiki locally