Skip Navigation Links首頁 > 產品與服務 > 技術分享

技術分享

HP NonStop系統之Pathway Shutdown模式研究(下)

作者/王宜倫


前言

繼前期《HP NonStop系統之Pathway Shutdown模式研究(上)》中介紹過Pathway Shutdown的各種方式,接下來筆者將針對各種shutdown模式作業系統實際運作過程作說明,讓讀者能了解系統實際運作方式,避免因遇到系統處理限制,造成shutdown失敗,或引發其他問題。

Messenger Process Senduse說明

隨著客戶Pathway環境日趨龐大,shutdown時會有大量close/death訊息在系統間傳遞,此狀況可能會達到系統資源 - Messenger process的極限,以下先說明Messenger process功能以及使用達到極限後可能引發之問題。

所有process都有一個outstanding message的限制,此限制為1024;而每個CPU上的Messenger process (pin 2),限制為4095,此稱為Senduse limit。在H版本和J版本作業系統,Senduse limit已放大為16383,但是仍建議以4095為限制。Messenger process會處理death message和close message,若一CPU上有一process停掉,death message會經由該CPU上的Messenger process負責傳遞;若一process呼叫close procedure或停止,其close訊息也是經由該process所在CPU上的Messenger process負責傳遞,每個close和death訊息會在Messenger process的Senduse佔一個slot(總共有4095個slot,也就是Senduse limit),若要接收此close或death message的process沒有去讀取他自己的$RECEIVE,則Messenger process不會釋放該slot,最終Messenger process可能會到達Senduse limit;若要接收此close或death message的process已經停止了,則該process所在CPU的Monitor process (pin 0)會處理,會告知Messenger process將傳遞給此process的close或death message丟掉(discard),釋放該slot。

當發生Senduse limit狀況,新產生的close或death message將會被Messenger process丟掉,也就是當某CPU的Messenger process達到Senduse limit時,若有close或death message要交給該Messenger process,這時Messenger process不會處理該message,且不會回應對方;更進一步說明send端不需要等待Messenger process給他ack,但是receive process需要等Messenger process送close/death message到其$RECEIVE,他去$RECEIVE讀取此close/death message後會通知Messenger process,這時Messenger process會release此close/death message佔用的Senduse slot。若Messenger process尚未將此close/death message送給receive process,receive process就停掉,當這個訊息送到該CPU時,找不到receive process,這時Messenger process會直接release此訊息佔用的Senduse slot。

當達到Senduse limit時可能會引發後續一些問題,尤其是Pathway環境,如果Pathway server沒有取得所有的close message,他不會把自己停掉,如果Pathmon沒有取得他底下process的death message,他會認為這些process仍在執行;若TACL沒有收到process的death message,他並不會知道要wake up,而是hang在那邊;例如:使用FUP interactive模式,當下exit後,FUP process會結束,並送death message給TACL,若TACL沒收到此death message,他並不知道要wake up,會一直hang住,直到user按break鍵。

在G06.23版本作業系統之前,並沒有任何警告訊息顯示系統有此問題發生,且Messenger process不會送出錯誤訊息。直到SPR T9050API版本開始,有一個warning message - GUARDLIB Message 110,當Messenger process有3000 outstanding message也就是Senduse slot被佔用3000個(73% of the max),他會刷出警示訊息,此訊息會列出佔用Messenger Senduse slot最多的前10個process,會顯示這些process的System number、CPU、PIN和他佔用多少個slot(或是稱為Senduse share)。 此訊息每5分鐘會刷一次,直到Senduse使用低於73%,或是達到Senduse limit,無法再處理新的close和death message時也會刷出訊息。

Messenger (pin 2)除了負責處理close/death message外,也負責與message傳遞相關的工作,當一個process需要將一個message傳遞給其他process,這個訊息實際上是經由Messenger傳遞;它負責link的動作,並盡一切努力將此message傳給接收者(listener),而發送端(linker)這時可以去繼續做他的工作。Messenger同時也負責將interrupt handlers產生的status message發送給要求此message的process,例如:CPU up/down、Disk up/down、網路狀態改變、SETTIME、power on,Messenger也負責將IOP的訊息傳送給$ZLOG process。

此處舉實際範例說明Message process處理close message的流程:

1.CPU 2的process A要發close message給在CPU 8的process B,process A會呼叫FILE_CLOSE_,close message會先經由CPU 2的Messenger process,而它會透過message system與CPU 8的Messenger溝通,再將此close message放進process B的 $RECEIVE。而在同一時間,process A會將其對process B的open從它的FCB拿掉,process A不需要接收process B或Messenger的reply。

2.若process B還沒去讀取它 $RECEIVE的close message就被停掉,則Messenger process會自動將此close message丟掉;同樣的若process B尚未收到Messenger送來的close message前就被stop,則Messenger process會自動將此close message丟掉。

使用MODE ORDERLY停止Pathway

當執行"SHUTDONW2, MODE OR"時,Pathmon會依序停止該Pathway所控管的TERM、TCP、SERVER,且會通知TCP,請其close對該Pathway server process的open。

◎當TCP(包含local、external TCP)收到Pathway要shutdown訊息後,便不會再傳送新的request給server,但是未完成的還是會繼續做完。

◎等到所有request都完成後,Pathmon就會stop其控管的TERM。

◎TERM都被stop後,Pathmon會依序開始停local TCP,順序是由Pathmon決定,停local TCP時是一個接著一個,不是全部一起停;此時TCP會先呼叫FILE_CLOSE_將server的open給close,每一個FILE_OPEN_ 都要對應到一個FILE_CLOSE_,如果TCP有open 1000個server process,他就需要呼叫1000次FILE_CLOSE_將這1000個open給close掉,所有open都close後,TCP就會stop。須注意的是TCP呼叫FILE_CLOSE_動作不需要等待對方reply,所以TCP不會等前一個FILE_CLOSE_結束後才呼叫下一個FILE_CLOSE_,是連續呼叫FILE_CLOSE_ 執行的。

舉例說明:若TCP A在CPU 2,所open的server B在CPU 8,這時候A會呼叫FILE_CLOSE_去close這個open,此時會有一close message經由CPU 2的Messenger process(Pin 2)與CPU 8的Messenger process(Pin 2),再傳送給位於CPU 8的B,而此close message會佔用CPU 2的Messenger process的Senduse的一個slot,當B去其$RECEIVE讀取此close message後,Messenger process便會釋放佔用的Senduse slot。當TCP A所有的open都close後,也就是當A針對所有的open都呼叫完成FILE_CLOSE_,不會管B有沒有收到此close message,就會被停掉,而此時TCP A的death message經由CPU 2的Messenger process與Pathmon所在CPU的Messenger process,再傳送給Pathmon,同樣的此death message也會佔用CPU 2 Messenger process的Senduse的一個slot,當Pathmon去讀取其$RECEIVE的death message後,Messenger process便會釋放佔用的Senduse slot。

◎external TCP的行為如下:external TCP會呼叫FILE_CLOSE_ 將server的open給close,每一個FILE_OPEN_ 都要對應到一個FILE_CLOSE_,如果external TCP有open 1000個server process,他就需要呼叫1000次FILE_CLOSE_將這1000個open給close掉,所有open都close後,針對此shutdown動作便告完成,external TCP不會被stop。須注意的是TCP呼叫FILE_CLOSE_動作不需要等待對方reply,所以TCP不會等前一個FILE_CLOSE_結束後才呼叫下一個FILE_CLOSE_,是連續呼叫FILE_CLOSE_ 執行的。

舉例說明:若external TCP C在CPU 2,所open的server B在CPU 8,這時候C會呼叫FILE_CLOSE_ close這個open,此時會有一close message經由CPU 2的Messenger process(Pin 2) 與CPU 8的Messenger process(Pin 2),再傳送給位於CPU 8的B,而此close message會佔用CPU 2的Messenger process的Senduse的一個slot,'B'去其$RECEIVE讀取此close message後,Messenger process便會釋放佔用的Senduse slot。

與local TCP依序停止不同的是,若有100個external TCP,則此100個external TCP會同時執行上述動作。

◎Server process會等待所有的open(包含local、external TCP、LINKMON的open)都被close後,便會stop,而此時Server的death message經由該server process所在CPU的Messenger process與Pathmon所在CPU的Messenger process,再傳送給其Pathmon,同樣的此death message也會佔用該CPU的Messenger process的Senduse的一個slot,Pathmon去其$RECEIVE讀取此death message後,Messenger process便會釋放佔用的Senduse slot。

◎當Pathway下的TERM、TCP、server都停止後,Pathmon便會把自己停掉,完成shutdown作業。

◎此方式shutdown Pathway時,因為是依序停止TERM、TCP、SERVER,所以並不會造成該Pathway環境所在CPUs非常busy,尤其是Pathmon process所在CPU。當然,Primary Pathmon process所在CPU仍有可能會因為沒有其他request,造成Pathmon搶走CPU time而100% Busy,但這屬正常行為,不會影響整個shutdown進行。

◎因為委託TCPs會同時去close所open的server process,但是因為server process所在CPU不會像MODE IM那麼busy,有較多的資源可以去讀取close message,釋放委託TCP所在CPU的Messenger process的Senduse slot,所以不易達到Senduse limit。

使用MODE ABORT停止Pathway

執行"SHUTDONW2, MODE AB"時,Pathmon會依序停止該Pathway所控管的TERM、TCP、SERVER,且會通知TCP,請其close對該Pathway server process的open。

此方式與MODE ORDERLY大致相同,唯一差異是當local TCP收到Pathway要shutdown訊息後,就會直接stop其控管的TERM,其於與MODE ORDERLY相同,此處不再重複。

使用MODE IM停止Pathway

當執行"SHUTDONW2, MODE IM"時,Pathmon會呼叫PROCESS_STOP_停止他所管理的TCP再停止server,且會通知external TCP,請external TCP close對該Pathway server process的open。

◎Pathmon直接呼叫PROCESS_STOP_停止所有的local TCP,而PROCESS_STOP_ procedure會呼叫FS_FILE_CLOSEALL_ procedure去停止該TCP所有的open,實際上FS_FILE_CLOSEALL_會針對每個open呼叫FILE_CLOSE_去停止該open。如果TCP有open 1000個server processes,FS_FILE_CLOSEALL就會連續呼叫1000次FILE_CLOSE_將這1000個open給close掉。

跟MODE OR不同的,TCP並不會處理這些close動作,是由file system負責處理,因為Pathmon呼叫PROCESS_STOP_ procedure去停止local TCP,這時PROCESS_STOP_ procedure會呼叫FS_FILE_CLOSEALL_,而FS_FILE_CLOSEALL_ 再針對每一個open呼叫FILE_CLOSE_,差別在於MODE OR是TCP主動呼叫,MODE IM則不是由TCP處理,由PROCESS_STOP_處理;感覺像是MODE OR是TCP負責打掃環境完成後離開,MODE IM則是PROCESS_STOP_幫TCP打掃環境,TCP可以先走,也就是TCP可能在close動作尚未完成前就被stop。

舉例說明:若TCP A在CPU 2,所open的server B在CPU 8,這時候Pathmon會呼叫PROCESS_STOP_ procedure去停止A,這時候PROCESS_STOP_ procedure會呼叫FS_FILE_CLOSEALL_ close A所有的open,針對每個open,FS_FILE_CLOSEALL_都會呼叫一個FILE_CLOSE_去停止該open,此時會有一close message經由CPU 2的Messenger process(Pin 2) 與CPU 8的Messenger process(Pin 2),再傳送給位於CPU 8的B,而此close message會佔用CPU 2的Messenger process的Senduse的一個slot,B去其$RECEIVE讀取此close message後,Messenger process便會釋放佔用的Senduse slot。若A有open 1000個server process,FS_FILE_CLOSEALL_就會連續呼叫1000次FILE_CLOSE_去停止這1000個open。

因為A的close動作是由file system所處理,所以他可能會在close動作處理完成前就被stop。同樣的,當A被停掉時,會有一death message經由CPU 2的Messenger process與Pathmon所在CPU的Messenger process,再傳送給其Pathmon,同樣的此death message也會佔用CPU 2的Messenger process的Senduse的一個slot,Pathmon去其$RECEIVE讀取此death message後,Messenger process便會釋放佔用的Senduse slot。

◎因為Pathmon是直接停TCP,所以,所有的TERM都會直接ABORT,所有當時的transaction狀態都不確定。

◎當所有local TCP都被停止後,Pathmon會呼叫PRCOESS_STOP_ procedure去停止所有的server,此時,與MODE OR不同的,即使external TCP仍然open該server,該server還是會被停掉。此時會有一death message經由該server process所在CPU的Messenger process與Pathmon所在CPU的Messenger process,再傳送給其Pathmon,同樣的此death message也會佔用該CPU的Messenger process的Senduse的一個slot,Pathmon去其$RECEIVE讀取此death message後,Messenger process便會釋放佔用的Senduse slot。

◎而external TCP的行為如下:external TCP會呼叫FILE_CLOSE_ 將server的open給close,每一個FILE_OPEN_ 都要對應到一個FILE_CLOSE_,如果external TCP有open 1000個server process,他就需要呼叫1000次FILE_CLOSE_將這1000個open給close掉,所有open都close後,針對此shutdown動作便告完成,external TCP不會被stop。須注意的是TCP呼叫FILE_CLOSE_動作不需要等待對方reply,所以TCP不會等前一個FILE_CLOSE_結束後才呼叫下一個FILE_CLOSE_,是連續呼叫FILE_CLOSE_ 執行的。

舉例說明:若external TCP C在CPU 2,所open的server B在CPU 8,這時候C會呼叫FILE_CLOSE_ close這個open,此時會有一close message經由CPU 2的Messenger process(Pin 2) 與CPU 8的Messenger process(Pin 2),再傳送給位於CPU 8的B,而此close message會佔用CPU 2的Messenger process的Senduse的一個slot,B去其$RECEIVE讀取此close message後,Messenger process便會釋放佔用的Senduse slot。若此時B已經被停掉了,這時候CPU 8的Monitor process(Pin 0)會負責告知CPU 2的Messenger process,此server已經停掉了,Messenger process便會釋放佔用的Senduse slot。若有100個external TCP,則此100個external TCP會同時執行上述動作。

◎此方式shutdown Pathmon時,因為是Pathmon直接呼叫PROCESS_STOP_去停止TCP、SERVER,所以會造成Pathway環境所在CPU非常busy,尤其是Pathmon process所在CPUs非常busy,因為這時候要處理很多close和stop作業。

◎因為Pathmon直接呼叫PROCESS_STOP_ 停止server process,所以server process不會理會是否有TCP仍然open他,就會被stop,在這種情況下,可能會發生沒有足夠資源去回應TCP的close message的問題,很容易造成TCP所在CPU的Messenger process的Senduse slot被佔滿,很容易達到Senduse limt。

結語

本文主要是透過File system和Message system的實際運作來說明Pathway shutdown過程中,系統如何停止整個Pathway環境,以及會使用哪些系統資源以及Pathway各object間彼此關聯,有哪些訊息會在系統內傳遞,希望藉由這些經驗的分享,讓系統管理人員、Pathway維護人員與應用程式開發人員更清楚了解Pathway shutdown時系統核心的運作。

資料來源

一、原廠使用手冊:

Pathway/iTS SCREEN COBOL Reference Manual
Pathway/iTS System Management Manual
TS/MP System Management Manual
NonStop S-series Server Description Manual
Pathway System Management
NonStop Kernel Principle
NonStop Kernel Architecture

二、HP Knowledge Database:

GUARDLIB Message 110
Halt %004106 in Messenger MAUX^LINK^SUBPROC
Question about Pathway shutdown behaviour
Question about Messenger process

 

回上一頁