Eisen's Blog

© 2022. All rights reserved.

记录 nvidia gpu 报错处理

2022 May-10

又发现了集群里出现了挂掉的 nvidia gpu 这里记录下如何屏蔽掉它以保证其他 GPU 可以继续被使用。

首先是监控告警,告知 nvidia-smi 命令出错了,去机器上看一下有这么个错误:

$ nvidia-smi
Unable to determine the device handle for GPU 0000:89:00.0: Unknown Error

感觉是这块卡 0000:89:00.0 出问题了。然后去执行下 dmesg 看看情况:

$ dmesg -T
[Mon May  9 20:37:33 2022] xhci_hcd 0000:89:00.2: PCI post-resume error -19!
[Mon May  9 20:37:33 2022] xhci_hcd 0000:89:00.2: HC died; cleaning up
[Mon May  9 20:37:34 2022] nvidia-gpu 0000:89:00.3: i2c timeout error ffffffff
[Mon May  9 20:37:34 2022] ucsi_ccg 6-0008: i2c_transfer failed -110

看不懂,搜了搜也有点懵逼。这台机器已经运行了挺久了,驱动也在短期内没有出过问题,那么就感觉是硬件出问题了。重启机器后,nvidia-smi 恢复了。不过如果有其他任务使用了 GPU 就又会出现这个问题了。所以考虑使用 nvidia-smi 的命令先屏蔽掉这块报错的 GPU 。

$ nvidia-smi drain  -p 0000:89:00.0 -m 1
Successfully set GPU 00000000:89:00.0 drain state to: draining.

然后再执行命令 nvidia-smi 就看不到这块卡了。


配置 jacoco 以提供更合理的测试覆盖率

2022 May-07

最近在做一些代码的重构和基础库的迁移,这样的工作绝大部分时候不产生新的功能点,每次更换了类库后也都会将原来对应的测试同步迁移过来,保证新的代码和原来的代码一样工作。不过在迁移的过程中我发现 jacoco 所提示的代码覆盖率越来越低,让我很慌。为了搞明白这是啥原因,做了一些调研,这里把一些结论记录在这里加深印象,也便于后续查看。

screenshot for openbayes server code converage before

代码测试覆盖率是什么意思

Intro to JaCoCo 这里讲的非常明白了,代码测试覆盖率(或者说代码覆盖率)讲的是在跑测试的时候,到底有多少代码被执行了。按照粒度来分可以有以下几种:

  1. Line coverage 按照字节码统计的多少 instruction 被执行了
  2. Branch converage 按照 if/else switch 等分支统计多少分支被执行了

由于代码确实会有很多防御性的 if/else 导致其实每一个分支并不是很对等,所以我个人感觉 Line coverage 会稍微好一些。

不过要注意,测试覆盖率只反映你多少代码在测试的时候被执行了,执行了一次就算是执行了,但事实上不同的参数会导致不同的结果,很多边界条件是否被测试到也表现不出来。因此 100% 测试覆盖率不表示所有代码都是对的了。如何写测试本身是一件极其复杂的事情,有些编程思路如 TDD 都是围绕测试进行的,我也讲不明白。

是什么导致覆盖率越来越低

为了搞明白为什么我的测试覆盖率一降再降,我需要用 JaCoCo 给我生成一下报告,我去看一下到底哪些地方的哪些代码测试出了问题。

我的项目是用 gradle 管理的,执行如下命令重新跑一下测试并生成报告:

./gradlew cleanTest test jacocoTestReport

然后去项目目录 build/reports/jacoco/test/html 打开 index.html 看看情况,发现核心为题在于很多生成的代码被纳入了代码测试覆盖中。具体来讲有两个方面的内容:

  1. Lombok 生成的很多代码
  2. 引入 QueryDSL 后其和对应的 Entity 生成的 Q + Entity 的名称的代码

那问题就显而易见了,尤其是后者,每次迁移一个 JPA 的 Entity 类型就会对应生成一段 Q + Entity 的代码,这部分代码统统成了测试覆盖率的分母,覆盖率能不低么。

User 对应的 QUser 文件
User 对应的 QUser 文件

如何改进

这部分的很多信息在 Exclusions from Jacoco Report 可以找到。

修改 JaCoCo 配置,保证代码覆盖率统计的合理性

我们只需要测试自己写的代码,生成的代码不应纳入统计范围。这里直接粘贴下 gradle 里面 jacocoTestReport 的配置:

jacocoTestReport {
    // rule from https://bottom-to-top.tistory.com/36
    // 过滤 QA-QZ 开头的所有类,对应了 querydsl 生成的 Q + Entity 的格式
    def Qdomains = []
    for(qPattern in "**/QA" .. "**/QZ"){
        Qdomains.add(qPattern + "*")
    }
    afterEvaluate {
        classDirectories.setFrom(files(classDirectories.files.collect {
            fileTree(dir: it, exclude: [
                    'com/openbayes/graphql/**',          // 所有 graphql 生成的代码
                    'com/openbayes/application/data/**', // 所有的 DTO 所在的包
                    'db/migration/**',                   // 所有的数据库 migration 代码
                    '**/*Exception*',                    // 所有包含 Exception 的异常类
                    '**/*Mixin*',                        // 所有 Jackson Mixin 
                    '**/*Command',                       // 所有带 Command 的类,也是 DTO
            ] + Qdomains)
        }))
    }
    reports {
        csv.required = true
    }
}

可以看到,我这里主要是按照 classDirectory 对类进行了过滤,包括了以下内容:

  1. 各种生成的代码:graphql 生成代码、querydsl 生成代码
  2. 各种 DTO 和 Exception:*Command data/**
  3. 实在不太好测试的东西,比如 migration 脚本、比如 Jackson 的 Mixin

对 querydsl 这部分的过滤比较 tricky ,因为其默认生成的名字是 Q + Entity,本身过滤就有点难,如果采用 **/Q* 的形式会导致个别以 Q 开头但不是 querydsl 生成的类也被纳入过滤的范围,这里我采用的是 https://bottom-to-top.tistory.com/36 的方法,过滤掉由 QA-QZ 开头的所有的类。

这里过滤 querydsl 的方法其实官方还有其他方案,但目前 gradle 这边支持不是很好,我目前用的 querydsl 版本为 5.0 有一些 PR 还没有纳入进来,后续如果官方有了更好支持会考虑做相应的调整。

通过注解过滤 Lombok 的代码

JaCoCo 本身是考虑了要过滤掉生成的代码的,它提供了一个规则:

Starting from JaCoCo 0.8.2, we can exclude classes and methods by annotating them with a custom annotation with the following properties:

  • The name of the annotation should include Generated.
  • The retention policy of annotation should be runtime or class.

简单的翻一下,就是在 JaCoCo 0.8.2 后,通过提供一个带有 Generated 名称的 RetentionPolicyCLASS 或者 RUNTIME 的注解,JaCoCo 会帮你自动过滤这些类。

Lombok 也对这部分做了支持,只要提供一个配置 lombok.config 就能让 Lombok 给自己生成的代码添加上相应的注解了:

lombok.addLombokGeneratedAnnotation = true

最后

在做了上述两方面的修改后,测试覆盖率重回 70% 了。

openbayes server code coverage after


使用 Automa 抓取少量微博数据

2022 April-14

最近需要抓一点点微博的数据,于是又开始做爬虫的老行当了。不过这次抓的数据相对比较少,本来是觉得会很快,可惜还是因为种种原因多折腾了两个小时。这里对这部分工作做一个记录。

我个人一直觉得爬虫是个很重要的东西,尤其是针对机器学习应用的研发,好的数据、新的数据、源源不断的新的数据是好的模型的前提。甚至不用做什么机器学习模型,仅仅从好的数据发掘的一些规则都很有帮助。所以,可以快速的抓数据、快速的抓各种各样的数据是一个很重要的能力。这里就不展开讲了,还是控制篇幅,以这次任务为主。

任务

从自己的微博首页或者随便一个主题下面抓点纯文本的微博数据,用于测试命名实体识别模型。

以前的方案

很久以前(大约还在读研究生的时候)那个时候的微博有一个移动版本,这个版本里面各种静态 html 非常好爬,所以难点基本就是发现 m.weibo.com 的存在...

不过很遗憾,现在不论是 weibo.com 还是 m.weibo.com 都不再是纯 html 了,都会动态获取数据了,需要有 js 的运行时环境才能以比较自然的方式抓取数据,毕竟目前 weibo 的数据动态加载策略、参数啥的有点复杂了,去解析它更麻烦。

Headless Chrome

对于动态获取数据的页面来说,可以采用 headless browwser 配合 puppeteer 来模拟页面的操作以加载并获取数据。不过我觉得这样做很明显有这么几个缺点:

  1. puppeteer 需要用 nodejs 编写,本身难度会比较大
  2. 这种 headless 的脚本相对来说都挺脆弱的,页面展示稍微慢一点,或者元素稍微做了点变化,整个脚本就凉凉了,这个问题不是在有 puppeteer 之后采用的,在以前用 selenium 或者 casperjs 的年代也同样发生

针对这个问题,我觉得有两个思路可以大大缓解:

  1. 建立一个组件库,包含在浏览器实现各种行为的最佳实践,尽量规避自己写代码所引入的缺陷
  2. 有一些类似于工作流的可视化界面,可以快速的建立一套爬取流程,虽然页面经常会发生变化,但由于我每次建立爬虫的成本大大降低了,所以我就不会那么在乎了

而 webscraper 则恰恰提供了以上两个东西。

webscraper

webscraper 是一个 chrome 扩展,其实它的内部依然是类似与 puppeteer 的东西,不过它做成了一个扩展,并提供了一些非常强大的封装,可以让你通过点点点就能实现一个数据爬虫的流程。

webscraper screenshot

封装程度高到如下的样子:

1. 提供丰富的组件,对应不同的抓取模式

webscraper element type

包括:

  1. 滚动到底部的瀑布加载
  2. 各种类型的分页
  3. 表格

2. 内置 element selector 可以在可视化界面完成页面元素的筛选

element selector

通过点点点,就能简历一个 css selector 来定位所要抓取的 html 元素路径。

3. 建立层级数据结构

在步骤 2 定位了想要抓取的具体数据后,可以在该数据上建立层级结构,标记具体想要抓取的数据结构,非常方便数据的结构化。

webscraper structure

有关这个东西有一个 卤蛋工作室 很详细的对它做了系列教程,感兴趣的话推荐一看,我这里就简单说说。不过很遗憾,这个东西在如今的微博也不太能用了。虽然现在的微博很符合它所提供的「滚动到底部」的抓取模式,但目前的微博出于性能的考虑,对自己的这个微博列表做了元素重用,导致不论怎么滚动,最多就只有这么多个元素了。那么套用 webscraper 的「滚动到底部」就只能获取这么多个微博而已了。

dynamic content refresh

Automa

Automa 也是一个 chrome 的扩展,相对于 webscraper 只用来做爬虫,automa 可以用来做各种流程自动化的东西,比 webscraper 灵活不少。除此之外,很多思路和 webscraper 一脉相承。简单看了看教程我就做出来如下一个流程:

weibo scrape in automa

其中的 javascript code 内容如下:

function inViewport (element) {
  if (!element) return false;
  if (1 !== element.nodeType) return false;

  var html = document.documentElement;
  var rect = element.getBoundingClientRect();

  return !!rect &&
    rect.bottom >= 0 &&
    rect.right >= 0 && 
    rect.left <= html.clientWidth &&
    rect.top <= html.clientHeight;
}

setTimeout(() => {
  var elements = document.querySelectorAll("article");

  elements.forEach(e => {
    if (inViewport(e)) {
      const text = e.querySelector('.detail_wbtext_4CRf9').innerText;
      console.log(text);
      automaNextBlock({ text: text }, true);
    }
  });
}, 1000);

和 webscraper 一直滚动到满意的个数的元素后再开始解析数据不同,我做的 automa 的流程是每次滚动一点点页面,然后就获取当前视图中的微博元素并把其内容存下来。而获取当前视图的元素就是用的上面的 javascript code 了。

小结

Automa 相对 webscraper 来说更加灵活,可以更加灵活的定制自己的抓取流程,后续可能还会有其他场景的使用吧。