使用大數(shù)據(jù)時(shí)，別忘了關(guān)注Linux內(nèi)存管理器
聲明：我們常常以為，一旦我們（的代碼）出了什么狀況，那肯定是操作系統(tǒng)在作祟，而在99%的情況下，結(jié)果都會是別的原因。因此我們會謹(jǐn)慎地作出是操作系統(tǒng)導(dǎo)致了某個(gè)問題這樣的假設(shè)，除非你遇到了與下面的例子類似的情況。
一切從我們的一個(gè)客戶報(bào)告了他們的CitusDB集群的性能問題開始。這個(gè)客戶設(shè)計(jì)的集群使得他們的工作數(shù)據(jù)集合可以放進(jìn)內(nèi)存，但是他們的查詢次數(shù)顯示他們的查詢已經(jīng)需要訪問磁盤。這自然會導(dǎo)致查詢效率下降10倍到100倍。
我們開始著手研究這個(gè)問題，首先檢查CitusDB的查詢分發(fā)機(jī)制，然后再檢查機(jī)器上安裝的PostgreSQL實(shí)例。發(fā)現(xiàn)都不是導(dǎo)致該問題出現(xiàn)的原因。接下來的一些發(fā)現(xiàn)：
- 客戶的工作數(shù)據(jù)是某一天的查詢?nèi)罩?。一旦他們看完了某一天的?shù)據(jù)，他們會開始查詢下一天的數(shù)據(jù)。
- 他們的查詢大都是連續(xù)的I/O操作，使用索引的情況并不多。
- 某一天的數(shù)據(jù)會占用一個(gè)節(jié)點(diǎn)超過60%的內(nèi)存(但還是大大小于整個(gè)可用的內(nèi)存)。他們實(shí)例上沒有別的使用內(nèi)存的程序。
我們假設(shè)，因?yàn)槊恳惶斓臄?shù)據(jù)可以容易的放進(jìn)內(nèi)存，Linux 內(nèi)存管理器最終會把那一天的數(shù)據(jù)都放進(jìn)頁緩存,一旦客戶開始查詢下一天的日志時(shí)，新的數(shù)據(jù)會進(jìn)入頁緩存，至少，這是一個(gè)使用LRU退化策略的簡單緩存（管理器）會做的事情。
但是LRU在用作頁替換策略算法時(shí)有兩個(gè)缺陷。***，精確的LRU實(shí)現(xiàn)在一個(gè)系統(tǒng)環(huán)境下成本太高了；第二，內(nèi)存管理器還需要把數(shù)據(jù)使用的頻率考慮在內(nèi)，讀入一 個(gè)大文件時(shí)并不會馬上清除整個(gè)cache，因此。Linux使用了比 LRU 更復(fù)雜的算法，而這個(gè)算法與我們之前描述過的問題協(xié)作的效果并不好。
舉例說明。假設(shè)你的內(nèi)核版本號高于2.6.31 ，而你在使用一個(gè)內(nèi)存為68GB的EC2集群，比如你有兩天的點(diǎn)擊流數(shù)據(jù)。每一天的數(shù)據(jù)都能超過60%的總的內(nèi)存，單個(gè)來看，都很容易能放進(jìn)內(nèi)存。
- $ ls -lh clickstream.csv.*
- -rw-rw-r-- ec2-user ec2-user 42G Nov 25 19:45 clickstream.csv.1
- -rw-rw-r-- ec2-user ec2-user 42G Nov 25 19:47 clickstream.csv.2
現(xiàn)在，我們通過對點(diǎn)擊流文件運(yùn)行多次 wc 命令來將該天的數(shù)據(jù)裝進(jìn)內(nèi)存。
注意這兩次所用的時(shí)間差。
***次我們運(yùn)行該命令時(shí)，Linux內(nèi)存管理器會將該文件頁放進(jìn)頁緩存，下一次運(yùn)行時(shí)，會直接從內(nèi)存里面讀取。
- $ time wc -l clickstream.csv.1
- 336006288 clickstream.csv.1
- real 10m4.575s
- ...
- $ time wc -l clickstream.csv.1
- 336006288 clickstream.csv.1
- real 0m18.858s
現(xiàn)在我們切換到第二天的點(diǎn)擊流文件。我們再多次運(yùn)行 wc 命令來把文件裝進(jìn)內(nèi)存。使用一個(gè)類LRU的策略會將***天的數(shù)據(jù)淘汰，并將第二天的數(shù)據(jù)裝進(jìn)內(nèi)存。不幸的是，在這種情況下，不管你運(yùn)行多少次，Linux 內(nèi)存管理器都不會把第二天的數(shù)據(jù)裝進(jìn)內(nèi)存。
- $ time wc -l clickstream.csv.2
- 336027448 clickstream.csv.2
- real 9m50.542s
- $ time wc -l clickstream.csv.2
- 336027448 clickstream.csv.2
- real 9m52.265s
事實(shí)上，如果你遇到這種情況，唯一能把第二天的數(shù)據(jù)裝進(jìn)內(nèi)存的辦法就是手動清除掉頁緩存，很明顯，這個(gè)做法會比問題帶來的危害更大，但單就我們的這個(gè)小測試而言，確實(shí)湊效了。
- $ echo 1 | sudo tee /proc/sys/vm/drop_caches
- $ time wc -l clickstream.csv.2
- 336027448 clickstream.csv.2
- real 9m51.906s
- $ time wc -l clickstream.csv.2
- 336027448 clickstream.csv.2
- real 0m17.874s
回到上一步，這兒的問題在于Linux如何管理自己的頁緩存。Linux內(nèi)存管理器會將文件系統(tǒng)的頁面放到兩種類型的隊(duì)列里面。一個(gè)隊(duì)列（臨近訪問內(nèi)存隊(duì)列，下面簡稱：臨近隊(duì)列）放了最近訪問到的頁面。另一個(gè)隊(duì)列（頻率訪問內(nèi)存隊(duì)列，下面簡稱：頻率隊(duì)列）保留了那些被多次訪問到的頁面。
在***的內(nèi)核版本中，內(nèi)存管理器將可用的內(nèi)存公平的分發(fā)給兩個(gè)隊(duì)列，盡量在保護(hù)頻繁訪問的頁面和探測最近使用的頁面之間達(dá)到一個(gè)折衷的平衡。換言之，內(nèi)核為頻率隊(duì)列保留了50%的可用內(nèi)存。
在之前的例子里，兩個(gè)列表一開始都是空的。當(dāng)***天的數(shù)據(jù)被引用的時(shí)候，會先進(jìn)入臨近隊(duì)列。在第二次被引用的時(shí)候，被提升到了頻率隊(duì)列。
接下來，當(dāng)用戶想使用第二天的數(shù)據(jù)進(jìn)行工作時(shí)，數(shù)據(jù)文件大于可用內(nèi)存的50%，但是臨近隊(duì)列的空閑空間卻沒那么大。因此，對這個(gè)文件的順序掃描就導(dǎo)致了內(nèi)存的置換震蕩。 第二個(gè)文件中的***個(gè)文件系統(tǒng)的頁面會先進(jìn)入臨近隊(duì)列，但是一旦臨近隊(duì)列空間被占滿了以后，這個(gè)頁就被從隊(duì)列中置換出來了。因此，第二個(gè)文件中沒有兩個(gè)頁面會在臨近隊(duì)列中停留足夠長的時(shí)間，因?yàn)樗麄兊囊脭?shù)一直在遞增。
幸運(yùn)的是，這個(gè)問題只有在當(dāng)你滿足以上我們列出的三點(diǎn)要素時(shí)才會發(fā)生。當(dāng)我們在這里討論的時(shí)候，問題正在被修復(fù)中。如果感興趣的話，你可以在Linux郵件列表下閱讀更多關(guān)于原始問題報(bào)告以及提議的一些修復(fù)辦法。
對于我們來說，真正利索的是很容易就定位到了問題所在。因?yàn)镃itus繼承自PostgreSQL，一旦我們發(fā)現(xiàn)了這個(gè)問題，就可以很快的在Postgres上復(fù)現(xiàn)，之后我們向linux郵件組提交了我們的發(fā)現(xiàn)，從此社區(qū)開始接手。
想發(fā)表評論？請加入hacker news的討論。
原文鏈接： Metin Doslu 翻譯： 伯樂在線 - 高磊
譯文鏈接： http://blog.jobbole.com/52898/
