刷卡機的區(qū)域代碼對不對

網(wǎng)上關(guān)于刷卡機的區(qū)域代碼對不對的刷卡知識比較多，也有關(guān)于刷卡機的區(qū)域代碼對不對的問題，今天第一pos網(wǎng)(www.ting2000.com)為大家整理刷卡常見知識，未來的我們終成一代卡神。

本文目錄一覽：

1、刷卡機的區(qū)域代碼對不對

刷卡機的區(qū)域代碼對不對

排查不一樣的問題，往往會有不一樣的難點。有的問題難在重現(xiàn)，但只要能重現(xiàn)一次，那么問題就會迎刃而解；有的問題難在調(diào)試，比如排查一個刷卡機內(nèi)的SD卡，通過數(shù)據(jù)線連接到電腦上出現(xiàn)文件系統(tǒng)不可見的問題。這可能需要研究刷卡機嵌入式操作系統(tǒng)，和桌面操作系統(tǒng)的文件系統(tǒng)，存儲系統(tǒng)，以及設(shè)備管理三層的實現(xiàn)，才能最終定位到問題。

對于阿里云技術(shù)支持的同學(xué)來說，還有另外一種比較特別的技術(shù)難題。這類問題的難度來源于客戶的堅持：當(dāng)我們的客戶對一個我們自己看起來無關(guān)緊要的問題盤根問底的時候，這個問題就會變得非常棘手。今天就跟大家分享一例這樣的問題。

是誰動了我的Cpu資源！

首先我簡單解釋一下客戶所看到的問題。如下圖第三行，top統(tǒng)計Cpu總體使用情況，使用了八個指標(biāo)。這八個指標(biāo)分別是，用戶空間進程（us），內(nèi)核空間進程（sy），高nice值的用戶空間進程（ni），空閑（id），空閑等待io（wa），中斷上半部（hi），中斷下半部（si），以及steal時間（st）。理論上來講這八個指標(biāo)之和，應(yīng)該是100%。這八個指標(biāo)當(dāng)中，id和wa是Cpu空閑時間的統(tǒng)計，這兩個值之和越小，說明Cpu越忙碌。客戶這臺服務(wù)器的id與wa之和是0，所以這臺服務(wù)器的Cpu使用率是100%，其中占比最大的是ni。

除了第三行Cpu總體統(tǒng)計指標(biāo)之外，top會對Cpu的使用率，從進程維度上進行統(tǒng)計，也就是CPU這一列。因為這臺服務(wù)器是16核的，所以每個進程（多線程）的Cpu使用率可以超過100%，同時所有進程Cpu使用率之和不能超過上線1600%（平均到每個核是100%）。

這個問題的“見鬼”之處在于，雖然這個系統(tǒng)里運行著787個進程，但這些進程使用Cpu之和，卻遠(yuǎn)小于1600%這個值。

晴天霹靂：問題現(xiàn)場丟失

剛準(zhǔn)備深入探究這個問題的時候，不幸的事情發(fā)生了。客戶這臺機器重啟了。重啟之后問題消失！雖然問題現(xiàn)場丟失了，但客戶的質(zhì)疑沒有改變。客戶強烈要求我們提供這臺服務(wù)器Cpu打滿的原因。

備注：很多時候，我們在遇到難以解釋的問題的時候，往往傾向于把問題歸結(jié)到和這個問題相關(guān)的“黑盒”的部分。這也是為什么，很多客戶在遇到不容易解釋的現(xiàn)象的時候，會懷疑原因在虛擬化層，或在物理機層，有時候甚至?xí)岩砂⒗镌频漠a(chǎn)品是不是“缺斤短兩”了。

nice！

作為技術(shù)支持工程師，在沒有重現(xiàn)環(huán)境的情況下，為了滿足客戶的需求，我這邊做的第一件事情是，搞清楚ni這個指標(biāo)的計算方法，跟客戶溝通這個指標(biāo)背后的理論知識，然后期望客戶能夠理解，這個指標(biāo)跟物理機沒有任何關(guān)系，純粹是虛擬機內(nèi)部行為。

nice是什么

在第一部分，我介紹Cpu八個統(tǒng)計指標(biāo)的時候，提到了ni是高nice值的用戶空間進程的Cpu使用率。nice值是什么呢，簡單來講，nice值代表著一個進程使用Cpu資源的優(yōu)先程度。每個進程都會有一個與之對應(yīng)的nice值，nice值越高，那么這個進程使用Cpu的優(yōu)先級就越低，獲得的處理器的時間相比較而言就會越少。而ni這個指標(biāo)，統(tǒng)計的是系統(tǒng)中，所有nice值大于0的用戶空間進程的Cpu的使用率。

一般情況下進程默認(rèn)的nice值是0，而當(dāng)有些進程需要更高的執(zhí)行優(yōu)先級的時候，我們會減小這些進程的nice值。當(dāng)然有一些并不需要在高優(yōu)先級運行的進程，例如我們跑編譯程序gcc，去編譯一個內(nèi)核，這個操作預(yù)計會花幾個小時，那么我們可以增加這個gcc進程的nice值。

linux會把真正的用戶模式Cpu使用率拆分成兩部分顯示，nice值大于0的顯示為ni，小于等于0的顯示為us。

自己動手跑高ni

這里我們做一個簡單的測試去驗證上邊的理論。我們使用for語句寫一個簡單的死循環(huán)程序loop，然后用objdump看代碼編譯之后的匯編程序。這段匯編非常簡單，前兩行準(zhǔn)備堆棧指針；第三行初始化一個變量，這個變量位于堆棧上rpb-0x4這個位置；然后第四第五行重復(fù)遞增這個變量。

00000000004004ed <main>:

4004ed: 55 push %rbp

4004ee: 48 89 e5 mov %rsp,%rbp

4004f1: c7 45 fc 00 00 00 00 movl $0x0,-0x4(%rbp)

4004f8: 83 45 fc 01 addl $0x1,-0x4(%rbp)

4004fc: eb fa jmp 4004f8 <main+0xb>

4004fe: 66 90 xchg %ax,%ax

loop進程一旦被調(diào)度到一個Cpu上，那么這個Cpu就會被打滿。如下兩張圖，左邊是nice值為0的情況，右邊是nice值為19的情況。進程nice值可以在圖下邊NI這一列看到。

下邊是Cpu使用率拆分到每個核上的情況。

不滿意的客戶

我跟客戶溝通ni這個指標(biāo)背后的理論知識和我的結(jié)論：這個問題和物理機沒有什么關(guān)系。對于我的結(jié)論，客戶是不接受的。客戶強調(diào)，在機器重啟之前，他檢查了系統(tǒng)里所有進程的Cpu的使用情況，他非常確定沒有發(fā)現(xiàn)任何異常。雖然當(dāng)時系統(tǒng)里有一百多個java進程，但是這些java進程的Cpu使用率都非常低。

時間大法，好！

以前處理系統(tǒng)夯機問題的時候，偶爾會走投無路。想象一下，一個復(fù)雜的系統(tǒng)中，運行著上千甚至上萬的進程。而夯機則意味著，系統(tǒng)里的這些進程，像一團亂麻一樣，糾纏在了一起。這個時候，只有從這些進程中整理出依賴關(guān)系，才能知道哪些進程是夯機問題的trouble maker，而哪些進程又是夯機問題的受害者。理清這些關(guān)系，大部分情況下，我們是靠理清資源的持有與等待關(guān)系。

可惜的是，這種分析方法并不是萬能的。系統(tǒng)為了節(jié)省管理成本，只會有選擇的維護其中某些資源的持有與等待關(guān)系。

在我們不能用這種方法分析問題的時候，另外一種方法就派上了用場。這種方法就是分析進程進入等待狀態(tài)的先后順序。我們稱這種方法叫“時間大法”。

挖礦程序

在因為無法重現(xiàn)問題而“走投無路”的時候，“時間大法”給了我希望。首先，在sa日志里我找到了Cpu達(dá)到100%的開始時間是4月29日凌晨6點40。接著，我翻遍了系統(tǒng)里幾乎所有的文件，發(fā)現(xiàn)有兩個配置文件在6點39被創(chuàng)建。而存放這兩個配置文件的目錄，則有兩個非常可疑的庫文件libxmr-stak-c.a和libxmr-stak-backend.a。Google這兩個文件，發(fā)現(xiàn)這是門羅幣挖礦程序使用的名字。

還是不滿意的客戶

當(dāng)把上邊的發(fā)現(xiàn)同步給客戶的時候，客戶還是覺得證據(jù)不足。而且客戶再次強調(diào)，他當(dāng)時看了所有系統(tǒng)里運行的進程，如果有可疑的進程使用Cpu異常的話，他肯定早發(fā)現(xiàn)了。因為客戶的堅持，壓力再次回到了我們這一邊。

隱藏linux進程方法一二三

如果客戶所說的是真實情況的話，那么有什么方法可以隱藏linux進程，讓客戶不能從ps或top的輸出中，讀到進程信息呢？比較常用的三種方法是：創(chuàng)建進程的時候，把pid設(shè)置成為0；直接修改ps和top代碼；或者h(yuǎn)ook libc里readdir和opendir等函數(shù)（因為ps和top的實現(xiàn)，直接使用了readdir和opendir等libc庫函數(shù)，來讀取/proc文件及其子目錄）。

這個時候我突然想起自己之前曾經(jīng)看到過的，在6點39被更改的另外一個文件ld.so.preload。第一次檢查這個文件的時候，看到這個文件里被寫了一條libjdk.so，想當(dāng)然的以為這個文件和java有關(guān)，所以忽略了這條信息。

我知道事情的真相了！

這個時候，事情的全貌就顯現(xiàn)出來了。在6點39分，有人給ld.so.preload增加了一個庫文件。從那以后，所有的進程，啟動的時候都會首先加載這個庫，然后再加載其他庫。這就產(chǎn)生一個效果，如果進程調(diào)用一個外部函數(shù)，這個函數(shù)的實現(xiàn)本來在其他庫文件里，但是這個預(yù)先加載的庫實現(xiàn)了同樣的函數(shù)，那么動態(tài)鏈接會先使用預(yù)先加載的這個庫里定義的這個函數(shù)。

記得上一次使用這個技巧的時候，還是多年前在寫opengl trace工具的時候。后來轉(zhuǎn)投微軟系，linux上這些技巧就淡忘了。基本上來說，使用ld.so.preload，我們可以實現(xiàn)filter類工具，在filter工具中實現(xiàn)過濾，追蹤，參數(shù)檢查等功能。當(dāng)然為了保證進程正常運行，我們的同名過濾函數(shù)，最終還是會調(diào)用原來的函數(shù)。

驗證了一下，系統(tǒng)里所有的進程，因為重啟，都加載了libjdk這個庫文件到自己的地址空間里。下圖是讀bash進程/proc/<pid>/maps內(nèi)容的輸出。

libjdk的雕蟲小技

這個庫libjdk和java沒有什么關(guān)系，他非常小，實現(xiàn)也非常簡單。以致于我們甚至可以通過讀匯編來理解它的行為。就如之前猜測的一樣，這個庫hook了readdir之類的函數(shù)，對讀取/proc文件夾的操作做了過濾，所以客戶在使用top或者ps命令的時候，得到的結(jié)果都是被過濾過的結(jié)果。這里不會對libjdk匯編代碼進行深入分析，但是提供一個strings輸出的這個庫文件里包含的串。從這些串中，我們也能對這個庫的行為猜個大概。

后記

回顧這個問題的處理過程，憑良心講，這個問題本來并不算是什么疑難雜癥。可能抓個core dump，分分鐘就能搞定。但兩件事情極大的增加了這個問題的排查難度，一個是問題環(huán)境丟失，一個是客戶的堅持。

當(dāng)然如果不是問題環(huán)境丟失，那么我也不會去嘗試其他的排查思路，如果不是客戶的堅持，我也不會做到把匯編代碼都拿出來做證據(jù)的這種程度。客戶的高要求，不斷的敦促，是我們不斷提升服務(wù)能力的重要驅(qū)動力。

以上就是關(guān)于刷卡機的區(qū)域代碼對不對的知識，后面我們會繼續(xù)為大家整理關(guān)于刷卡機的區(qū)域代碼對不對的知識，希望能夠幫助到大家！

轉(zhuǎn)載請帶上網(wǎng)址：http://www.ting2000.com/shuakatwo/209221.html