![頭圖.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/)

緊張 + 刺激，源自一次 OOM 歷險

相關文章