紧张 + 刺激，源自一次 OOM 历险

作者 ｜ 蚂蝗

背景

​

Erda 是集 DevOps、微服务治理、多云管理以及快数据管理等多功能的开源一站式企业数字化平台。其中，在 DevOps 模块中，不仅有 CI/CD、项目协同等功能，同时还支持自动化测试、测试用例管理等。

本文讲述的是一次源于 Erda 平台的测试用例导入发生的事故。一个只有 2M，看起来人畜无害的 excel 测试用例文件，把我们的 qa 服务（DevOps 模块里的一个组件）直接干 OOM 了。

Tips：OOM 即 Out Of Memory，指程序使用内存过多，超过限制，被中止掉了。

​

​

排查过程

线索

打开上述 excel 文件，感觉一切正常，数据不多，格式也很规范。但仍然对它存有疑虑，话不多说，我们直接在开发环境进行一个重试，重启，但它依旧稳定 OOM。我想了很久，逐渐开始慌了，是不是我又做错了什么？不会吧不会吧，我们不会真出大 Bug 了吧？！

​

出来吧，debug 大杀器 go pprof ，由于现场比较好复现，所以我们选择了开始导入和导入中两个点的 inuse_space 内存来进行对照。通过工具，我们可以看到：使得内存飙升的方法，一个是 xlsx 解析的开源库；一个是 golang 解析 xml 的标准库。

go tool pprof -inuse_space http://qa:3033/debug/pprof/heap > base.hepa
go tool pprof -inuse_space http://qa:3033/debug/pprof/heap > current.hepa
go tool --base base.hepa current.hepa

标准库和 star 4k+ 的开源库怎么可能会出现这种问题呢？我们首先怀疑是不是调用这个 xlsx 解析库的时候出了问题，但是这一共 14 行的代码，不管怎么看，感觉都不会出错。

​

func Decode(r io.Reader) ([][][]string, error) {
	tmpF, err := ioutil.TempFile("", "excel-")
	if err != nil {
		return nil, err
	}
	if _, err := io.Copy(tmpF, r); err != nil {
		return nil, err
	}
	data, err := xlsx.FileToSlice(tmpF.Name())
	if err != nil {
		return nil, err
	}
	return data, nil
}

了解“受害者-xlsx文件”

没办法，只能看看这个开源库的代码了。

func FileToSlice(path string, options ...FileOption) ([][][]string, error) {
	f, err := OpenFile(path, options...)
	if err != nil {
		return nil, err
	}
	return f.ToSlice()
}

// OpenFile will take the name of an XLSX file and returns a populated
// xlsx.File struct for it.  You may pass it zero, one or
// many FileOption functions that affect the behaviour of the file.
func OpenFile(fileName string, options ...FileOption) (file *File, err error) {
	var z *zip.ReadCloser
	wrap := func(err error) (*File, error) {
		return nil, fmt.Errorf("OpenFile: %w", err)
	}

	z, err = zip.OpenReader(fileName)
	if err != nil {
		return wrap(err)
	}
	file, err = ReadZip(z, options...)
	if err != nil {
		return wrap(err)
	}
	return file, nil
}

// ReadZip() takes a pointer to a zip.ReadCloser and returns a
// xlsx.File struct populated with its contents.  In most cases
// ReadZip is not used directly, but is called internally by OpenFile.
func ReadZip(f *zip.ReadCloser, options ...FileOption) (*File, error) {
	defer f.Close()
	file, err := ReadZipReader(&f.Reader, options...)
	if err != nil {
		return nil, fmt.Errorf("ReadZip: %w", err)
	}
	return file, nil
}

// ReadZipReader() can be used to read an XLSX in memory without
// touching the filesystem.
func ReadZipReader(r *zip.Reader, options ...FileOption) (*File, error) {
    ······
    ······
	for _, v = range r.File {
		_, name := filepath.Split(v.Name)
		switch name {
		case `sharedStrings.xml`:
			sharedStrings = v
		case `workbook.xml`:
			workbook = v
		case `workbook.xml.rels`:
			workbookRels = v
		case `styles.xml`:
			styles = v
		case `theme1.xml`:
			themeFile = v
		default:
			if len(v.Name) > 17 {
				if v.Name[0:13] == "xl/worksheets" || v.Name[0:13] == `xl\worksheets` {
					if v.Name[len(v.Name)-5:] == ".rels" {
						worksheetRels[v.Name[20:len(v.Name)-9]] = v
					} else {
						worksheets[v.Name[14:len(v.Name)-4]] = v
					}
				}
			}
		}
	}
    ······
    ······
	return file, nil
}

​

看完之后，我突然就 get 到了新的知识点：xlsx 文件原来是一个由很多不同的 xml 文件通过 zip 压缩起来的东西。解压后的它长这样：

​

​

根据代码的逻辑，worksheets/sheet1.xml 是单元格里主要的数据，里面的具体数据是指向 sharedStrings.xml 里的一个个索引；sharedStrings.xml 里存储的就是索引和实际文本内容的对应关系；theme/theme1.xml 和 styles.xml 顾名思义就是 excel 的格式和主题。

破案

由于 go pprof 指向的问题是 xml 解析耗费了大量的内存，所以我们第一时间怀疑：是不是主题或格式太复杂导致解析慢，但是当我们点进去发现内容啥的都非常正常。

​

直到点到 worksheets/sheet1.xml 后，我的 IDE 突然就没了反应，电脑风扇也响了起来，这时我的内心兴奋中夹杂着一点小不安，兴奋的是好像要破案了，不安的是它该不会要把我的电脑干爆吧。

​

千呼万唤始出来，在加载了非常久之后，我们看到这个文件里有大量这样的字段，总共大约有 70w+ 行，他们的意思就是这些单元格的值都是 null，而有的值下面都会有 <c r="A1" s="13" t="s"><v>15</v></c> 这样的字段。这个 15 就是 sharedStrings.xml 里的索引了，我们通过 excel 工具去定位空值也是定位到了大量的 null，而且都是表格外的、无意义的。到这里，我们基本确认了问题就是用户的这个文件有大量的 null 导致 xml.Decode 解析大量无意义的 null 时消耗了很多内存和时间。

解决方案

​

本着开源精神，我们向社区提交了一个 issue，在和热心的负责人聊完之后，具体的讨论可以看下这个 issue，里面还有一些其他的解决办法。比如使用 Disk 存储，但是这个办法对我们来说还是太慢；里面也有一个 RowLimit 的 option，这个也解决不了我们的场景，因为我们无法确定需要限定成多少个行，而且列里的 null 还是会被解析。

​

​issue: https://github.com/tealeg/xlsx/issues/700

​

所以我们提供了一个 valueOnly 的 option，在这个 option 被选中时，我们会在 xml.Decode 对其进行解析之前简化这个 xml 文件，也就是删掉这些 null 值的单元格，从而可以节省大量的内存和解析时间。但是这个选项也有一定风险，因为 null 不一定就是没意义，它也有可能代表是空的意思，但也符合这是一个 option 的定义并且我们对它加了风险提示的注释。

​

相关 PR 链接：https://github.com/tealeg/xlsx/pull/701

​

思考

不得不说，开源社区也太好玩了！对于自己使用的项目有什么想要的功能，想修的 Bug，完全不用反馈完再等排期，自己直接写完提交 PR 就好了，现杀现吃。更重要的是可以和大家一起分享、完善自己的想法或创意，甚至还可以提高自己 2.5 级的英语水平。

​

最后非常欢迎大家加入我们的开源项目 Erda，一起打造这个企业级一站式 PaaS 平台，不管是好的创意、需求还是 Bug，都欢迎提交 issue 来讨论嗷！（有 PR 当然就更好更欢迎咯，Talk is cheap. Show me the code），这里的人个个都超有才，说话又好听，我超爱这里的。

​

如果对于 Erda 项目你有其它想要了解的内容，欢迎添加小助手微信（Erda202106）加入交流群！

​

欢迎参与开源

Erda 作为开源的一站式云原生 PaaS 平台，具备 DevOps、微服务观测治理、多云管理以及快数据治理等平台级能力。点击下方链接即可参与开源，和众多开发者一起探讨、交流，共建开源社区。欢迎大家关注、贡献代码和 Star！

​

• Erda Github 地址：https://github.com/erda-project/erda
• Erda Cloud 官网：https://www.erda.cloud/