電網(wǎng)自動化主站計算機系統(tǒng)性能測試

陳 力 戴 亮 李紅文 李 灝

（甘肅省電力科學研究院，甘肅 蘭州730050）

1 計算機系統(tǒng)的性能

一個計算機系統(tǒng)所具有的能力和它在實際使用中所表現(xiàn)出來的性能并不是一回事。當我們說，我國的銀河機具有萬億次運算能力時，我們是指它的硬件可能達到的最高運算速度。這種與軟件無關(guān)的、由硬件決定的運算能力，可以通過標準的測試方法精確獲得。但當我們談一個系統(tǒng)的性能指標時，必須注意，這個指標的構(gòu)成要比運算能力復雜得多，因為構(gòu)成性能指標的要素大為增加。

性能是在執(zhí)行某一功能時表現(xiàn)出來的，脫離特定功能的性能指標毫無意義。功能是由軟件決定的，因此，性能與軟件緊密相關(guān)，而軟件在這方面的通用指標是代碼效率。因此，是系統(tǒng)的硬件能力提供運算基礎，而軟件則決定著系統(tǒng)的功能和性能。當我們測試一個系統(tǒng)的性能時，很大程度上我們是在測試這個系統(tǒng)由軟件決定的運算效率。這使問題一下子變得復雜。

既然我們必須在特定功能之下來談性能，那么對于計算機系統(tǒng)來說，同一行業(yè)的同類計算機系統(tǒng)，比較起來就更有可能找到相同的指標。大體上，我們可以把計算機系統(tǒng)分為實時系統(tǒng)、及時（準實時）系統(tǒng)等。

2 電網(wǎng)自動化主站系統(tǒng)性能

在電力行業(yè)內(nèi)部，存在多種功能各異的計算機系統(tǒng)。其中，電網(wǎng)自動化EMS／SCADA系統(tǒng)，是一個完全的實時系統(tǒng)，它必須在秒的數(shù)量級上反映電網(wǎng)實際工況。而電能計費TMS系統(tǒng)則是一個及時系統(tǒng)，因為電能數(shù)據(jù)是功率在時間軸上的積分，以秒為單位更新電能數(shù)據(jù)沒有什么意義。接下來是辦公（MIS）系統(tǒng)、企管（ERP）系統(tǒng)等等，這些系統(tǒng)基本上只傳送靜態(tài)數(shù)據(jù)，一般來說，像CPU負荷率、網(wǎng)絡流量、寫盤速度、內(nèi)存出錯概率等等，都是可以預期的，很少會有突發(fā)性事件使集束數(shù)據(jù)涌上網(wǎng)絡，堵塞通道，造成系統(tǒng)癱瘓等事件的發(fā)生。

為什么只有EMS系統(tǒng)具有網(wǎng)絡堵塞、系統(tǒng)崩潰的潛在風險呢？這是由它所監(jiān)控的電網(wǎng)的性質(zhì)決定的。

在電網(wǎng)的運行中，事故的發(fā)生往往具有局部正反饋的特征。雪崩的意思就是小的擾動引發(fā)連鎖反應，造成大范圍內(nèi)的坍塌。電網(wǎng)的這種特性，使得它的監(jiān)控系統(tǒng)就像坐落在一座死火山的腳下，也許幾百年內(nèi)不會遇上噴發(fā)，但這種噴發(fā)的可能性的存在，不得不使山村的居民對噴發(fā)的危險性保持警惕。

舉例說，如果主網(wǎng)架中有相當份量的潮流指向負荷區(qū)域，假如此時主供線路因為某種原因（比如污閃）跳閘，潮流瞬間轉(zhuǎn)向，通過后備線路迂回轉(zhuǎn)供，這種補償行為使后備線路逼近動穩(wěn)極限，任何風吹草動都會導致超限失穩(wěn)。如果系統(tǒng)局部解列，巨大沖擊會使電網(wǎng)強烈振蕩，頻率大幅跳變。在這尋找重新平衡的過程中，倘若偏又遇著保護拒動，斷供面積的進一步擴大開始威脅主網(wǎng)架的穩(wěn)定。部分孤島出現(xiàn)失壓，恢復過程甚至要進行黑起動！這就是局部事故引起系統(tǒng)崩潰的場景。

在此過程中，大量斷路器、刀閘跳變，遙信風暴涌入EMS系統(tǒng)，越限告警大批量產(chǎn)生，使系統(tǒng)應用層任務高度飽和，CPU不堪重負，網(wǎng)絡節(jié)點出現(xiàn)堵塞，系統(tǒng)反應越來越慢，最后干脆死機不動，需要重新引導系統(tǒng)。這就是EMS系統(tǒng)的崩潰過程。直接原因是因為EMS系統(tǒng)的能力不足以應對巨量信息的涌入，而產(chǎn)生這些信息的源頭，則是由于電網(wǎng)的大面積事故集中爆發(fā)所致。

我們可以理解到，這是EMS／DMS這類實時系統(tǒng)特有的情況。辦公系統(tǒng)也會時忙時閑，但不會有數(shù)據(jù)風暴產(chǎn)生；及時系統(tǒng)的數(shù)據(jù)，必須通過累積才能發(fā)生變化，也不會出現(xiàn)信息風暴。

EMS系統(tǒng)的運行經(jīng)驗告訴我們，信息源的火山爆發(fā)，雖然措不及防，卻是經(jīng)年難遇的，但這種可能性的存在，使我們不得不考慮消防措施，這就是在系統(tǒng)設計中，必須考慮遙測遙信風暴來襲時，系統(tǒng)的承受能力問題。

根據(jù)2012年度的EMS系統(tǒng)設計指標，在正常工況下，CPU負荷率必須低于15%；在風暴來襲的異常情況下，CPU負荷率也不能超過30%。就是說，在設計上必須保證系統(tǒng)在任何情況下都有足夠的安全裕度。

3 風暴壓力下電網(wǎng)自動化主站性能測試

EMS系統(tǒng)建成以后，我們?nèi)绾潍@得上述性能指標的數(shù)據(jù)呢？實際系統(tǒng)不可能提供這樣的樣態(tài)，我們必須人為設計出這樣一種信息源，專門用來測試EMS／DMS系統(tǒng)主站的性能。

這樣的測試設備，其功能就是通過軟件仿真，模擬數(shù)千上萬個軟件遠方終端（RTU），每個RTU提供數(shù)千遙測變化數(shù)據(jù)和遙信變位信息，對系統(tǒng)主站形成巨大的信息處理壓力，在此工況下，觀察系統(tǒng)性能指標的變化，是否符合設計要求。

下面是2個現(xiàn)場測試的樣本：

3.1 案例1

對一新投運的省會城市的DMS主站系統(tǒng)進行上述測試，基本設置如下：（1）RTU數(shù)量2 000臺；（2）每臺RTU遙測數(shù)據(jù)32點，遙信開關(guān)量數(shù)據(jù)64點；（3）遙測數(shù)據(jù)和遙信數(shù)據(jù)每2 s變化一次；（4）測試時間：持續(xù)15 min。

測得系統(tǒng)性能指標如下：（1）CPU負荷率最高64%，最低38%，加權(quán)平均51%，越過設計指標；（2）內(nèi)存交換使用率，最大18%，最小16%，加權(quán)平均17%，低于設計指標；（3）網(wǎng)絡使用率，峰值54%，谷值14%，平均使用率34%，與設計指標基本持平。

縱觀上述3大指標，只有CPU負荷率無法通過。接下來，在RTU臺數(shù)降為1 000以后，重新進行測試，測得CPU平均負荷率為21%，低于30%的設計指標，獲得通過。

3.2 案例2

對一新投運的省級EMS主站系統(tǒng)進行同樣的壓力測試，基本設置如下：（1）RTU數(shù)量10臺；（2）每臺RTU遙測數(shù)據(jù)點1 000點，遙信數(shù)據(jù)點1 200點；（3）每個遙測點和遙信點數(shù)據(jù)每2 s變化一次；（4）測試時間：持續(xù)15 min。

測得系統(tǒng)性能指標如下：（1）CPU負荷率最高36%，最低3%，加權(quán)平均19.5%；符合設計指標；（2）內(nèi)存使用率，最大8%，最小3%，加權(quán)平均5.5%；獲得通過；（3）網(wǎng)絡使用率，最高峰36%，最低谷12%，平均24%，符合設計指標。

上面測得的全部指標都優(yōu)于設計指標，說明系統(tǒng)安全裕度足夠大。

從以上2個例子我們看到，一般系統(tǒng)的網(wǎng)絡使用率和內(nèi)存交換率都有很大的裕度，容易獲得通過。而CPU負荷率這個指標，不同的測試設置，對CPU的負荷率影響很大。

4 對CPU多核多線程任務分配的思考

由于CPU負荷率是各種指標中較難通過的一項，這里重點對其任務分配的內(nèi)在機制作進一步的探討。

目前電網(wǎng)EMS／SCADA系統(tǒng)主站的服務器，普遍采用多芯多核CPU組件。比如1臺曙光A840r－G服務器，配置為4芯、8核，共32顆AMD的CPU，在測試中可以看到，無論系統(tǒng)任務多忙，大部分CPU的負荷曲線始終躺在地板上不動，任務分配嚴重失衡。系統(tǒng)工程師也看到了這一點，但是束手無策，因為對于芯片內(nèi)核有關(guān)任務分配的底層設置，系統(tǒng)供應商尚且輕易不去動它，用戶就更加望而卻步了。因為改動這個層面的東西，弄不好會出大問題。

但從經(jīng)濟角度看，如果系統(tǒng)忙得要垮機了，服務器中的大部分CPU卻從未被使用過一次，這就顯得很不合理。一臺價值20萬元的服務器，其實在其壽命周期內(nèi)，最多只使用了它的資源能力的1／3，這無疑是對設備資源的巨大浪費，而在一個主站系統(tǒng)中，這樣的服務器有幾十臺。

因此筆者覺得，應該在主站系統(tǒng)管理崗位中，設立一個計算機系統(tǒng)診斷崗位，專門從事系統(tǒng)優(yōu)化的工作，跨部門兼職也可以，進行特別技術(shù)培訓。此崗位除了執(zhí)行日常維護工作外，專門授權(quán)執(zhí)行計算機系統(tǒng)配置方面的優(yōu)化設計和修改操作。當然，這個崗位的工作具有一定深度的技術(shù)要求，對CPU內(nèi)部的邏輯架構(gòu)、線程調(diào)度、進程推移模式應該有相當?shù)牧私猓绕鋵萌蝿赵诜掌魃系牟⑿袌?zhí)行要有清楚的認識和實用性的感性經(jīng)驗。

下面我們來宏觀地分析一下多核CPU的資源利用問題。

在Windows下執(zhí)行多個任務的CPU，在單核時代是采用多線程調(diào)度、虛擬進程、分時執(zhí)行策略，但從酷睿二代起，CPU內(nèi)部控制策略就對現(xiàn)有的操作系統(tǒng)提出了尖銳的挑戰(zhàn)。以前是要把CPU資源切碎了分給各個應用，現(xiàn)在，原理上可以把整個CPU分配給一個應用了，操作系統(tǒng)能適應這種變化嗎？上到服務器級別，物理CPU有幾十個，應用任務反而少于CPU數(shù)，這時候系統(tǒng)是要把應用切碎了分配給各個CPU，操作系統(tǒng)還能適應嗎？

其次，服務器的應用對象比PC有很大的不同：比如EMS系統(tǒng)中，通常把不同的應用功能分配到各個節(jié)點的服務器上，這時侯各個服務器面對的是單個應用的巨量數(shù)據(jù)，而應用的類型卻不多，現(xiàn)在的典型要求是把應用切碎后在各個CPU上進行排程。Windows在這里無能為力了。不過服務器大多在LINUX下運行，靈活性大大增加，如前述這種倒過來的要求，也可以通過編程的設計在服務器上實現(xiàn)，但卻對傳統(tǒng)的程序設計提出了巨大的挑戰(zhàn)：過去在銀河機上才會碰到的問題，現(xiàn)在要由普通的PC程序員來解決。

不過請注意，程序都是模塊化的，對于最小的功能單元，通過編程來調(diào)度也是可能的：事實上你不必修改程序，只須選擇定義項即可，前提是，你對多核結(jié)構(gòu)的CPU執(zhí)行流程，對操作系統(tǒng)的潛在功能，以及對面向?qū)ο笳Z言的邏輯要有深刻的理解。

目前最切實可行的思路應該是：（1）默認服務器一定是多芯多核多物理CPU的，比如4芯X8核＝32個CPU；（2）默認應用任務數(shù)少于CPU數(shù)，但單個應用要處理的信息量巨大；（3）軟件必須面向多核多任務，線程可交叉調(diào)度、統(tǒng)一組裝；（4）任務分配策略的調(diào)整無需修改源代碼，只須通過修改定義來實現(xiàn)；（5）策略調(diào)整的依據(jù)不是通過預先的設計，而是根據(jù)執(zhí)行經(jīng)驗來獲得資源最優(yōu)分配原則。

比如說，初始投入運行的系統(tǒng)，你并不知道有多少個應用需要同時執(zhí)行，也不清楚單個應用所要處理信息的數(shù)量級，那就先在缺省狀態(tài)下運行一段時間，不斷積累CPU資源分配的經(jīng)驗。可以肯定，經(jīng)過一段時間，你會發(fā)現(xiàn)任務分配極不合理，資源被大量閑置，而少數(shù)CPU卻負荷過重，于是通過調(diào)整任務分配策略來改善資源利用效率。這個過程反復多次以及在系統(tǒng)各種工況下的實際需求都出現(xiàn)過以后，你對資源分配策略應該向哪個方向傾斜，也就心中有數(shù)了。

顯然，這一過程無法通過預先設計來實現(xiàn)，而要在運行實踐中反復權(quán)衡不斷優(yōu)化。

5 結(jié)語

電網(wǎng)自動化主站的計算機系統(tǒng)，因面向的應用對象不同而有其特殊性。其中最關(guān)鍵的性能指標是CPU負荷率。測試這一指標必須借助于專門的技術(shù)手段，才能獲得真實可信的數(shù)據(jù)。針對CPU資源被閑置浪費的現(xiàn)實，努力提高系統(tǒng)的資源利用水平，應該成為今后系統(tǒng)管理的重要目標，這種管理具有相當?shù)募夹g(shù)深度，必須通過專人專崗納入到系統(tǒng)管理的體系之中。

［1］劉文穎.電網(wǎng)黑起動案例分析［A］.全國高校自動化專業(yè)第十九屆年會論文集［C］，2001

［2］陳天洲等.多核程序設計［M］.清華大學出版社，2007

［3］孫驍強，范越，白興忠，等.電網(wǎng)調(diào)度典型事故處理與分析［M］.中國電力出版社，2011