![头图.png](https://intranetproxy.alipay.com/skylark/lark/0/2021/png/21956387/1624506460505-c280f488-f157-4ece-9664-3f1b4d67aec6.png#clientId=u89863d68-75af-4&from=ui&id=u6e95978e&margin=%5Bobject%20Object%5D&name=%E5%A4%B4%E5%9B%BE.png&originHeight=502&originWidth=960&originalType=binary&ratio=2&size=349505&status=done&style=none&taskId=u75522ac7-50da-4ef6-ac7d-3a42959c725)
作者 ｜ 蚂蝗

## 背景

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

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

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

![image.png](https://intranetproxy.alipay.com/skylark/lark/0/2021/png/309280/1623832050356-44c05b79-5b34-4dfb-89e4-56c5eae453bf.png#clientId=u6cd201d6-3641-4&from=paste&height=833&id=u87cc5f42&margin=%5Bobject%20Object%5D&name=image.png&originHeight=1666&originWidth=2878&originalType=binary&ratio=2&size=646195&status=done&style=none&taskId=ucebe0917-1913-42a3-8b18-9f4cca4d521&width=1439)

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

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

```bash
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
```
![image.png](https://intranetproxy.alipay.com/skylark/lark/0/2021/png/309280/1622450750609-e457d1bd-436a-427f-a219-7a30c6ea6860.png#clientId=u283e685e-760e-4&from=paste&height=876&id=e7A9L&margin=%5Bobject%20Object%5D&name=image.png&originHeight=1752&originWidth=2880&originalType=binary&ratio=1&size=890358&status=done&style=none&taskId=ub5278a11-c3c6-45e7-8742-b1424663328&width=1440)

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

```go
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文件”
没办法，只能看看这个开源库的代码了。
```go
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 压缩起来的东西。解压后的它长这样：

![image.png](https://intranetproxy.alipay.com/skylark/lark/0/2021/png/309280/1622452133470-b0fe5eea-216a-49f1-b79e-7f9d8dc0445c.png#clientId=u283e685e-760e-4&from=paste&height=448&id=oaclQ&margin=%5Bobject%20Object%5D&name=image.png&originHeight=896&originWidth=642&originalType=binary&ratio=1&size=139066&status=done&style=none&taskId=u09aced0b-faeb-41f6-bc0a-8cf02db4253&width=321)

根据代码的逻辑，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 时消耗了很多内存和时间。

![image.png](https://intranetproxy.alipay.com/skylark/lark/0/2021/png/309280/1622454071278-cd1810a2-ff12-49b9-8bcf-95957b89dcef.png#clientId=u283e685e-760e-4&from=paste&height=893&id=u8c3b7d03&margin=%5Bobject%20Object%5D&name=image.png&originHeight=1786&originWidth=2286&originalType=binary&ratio=1&size=1115541&status=done&style=none&taskId=u4b24428f-73ee-43d2-8ea3-0c0f716a7e5&width=1143)
## 解决方案

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

> **issue**: [_https://github.com/tealeg/xlsx/issues/700_](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_](https://github.com/erda-project/erda)
- **Erda Cloud 官网：**[_https://www.erda.cloud/_](https://www.erda.cloud/)

ITPub博客

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

最新文章