Re: [新聞] 戶政系統大塞車 內政部請IBM抓錯

[ggg12345 (ggg)]

※ 引述《mephiliu (Mephi)》之銘言：
: : 只負擔200個, 確實很鳥! 但不深究, 表面的解法就是增加機器避免超載.
: : 不買 cpu 買 SSD 加速 disk access 就是減輕 access delay 也是一解.
:   如果在當機時memory 使用 20%, CPU 使用40%, Disk I/O 使用不到1%
:   加再多的機器也不會解. 詳參考BEA-000337

這個error message在google網上看見的就類似這種訊息:
<WebLogicServer> <BEA-000337> <[STUCK] ExecuteThread: '4' for queue:
即使是 2014 2月 照樣有這種訊息在發問.

這個message說法就是某個thread 在queue 呆太久, 超過設定的default 時限.
這現象就是接近教科書說的 dead lock. 最簡單解法就是 "人工進入"宰掉重跑.
對系統管理員是這樣子靠他來救.
這種錯是系統分析者的失誤沒考慮到. 但若是太大塊的分工, 寫程式的負責這個
功能與算法, 那就是寫程式的寫出錯誤的狀況.

再怎麼說, 這就是通稱不知何時何處會冒出問題的 爛code.

從2月之後的報導, 都是這現象. 申請者與戶政服務人員等得天荒地老還不來!

: : Queue 拉長了, 再進來的不被drop行嗎?
: : 研考會的 "向上集中" 應該是 "集中式單一管理, 分散式平行處理", 但太
: : 容易被誤會倒退回 "全集中管制處理". 戶役政的資料庫應該還是分散在各
: : 戶政所的. 程式架構不分析好, 算法不想好, 自然就怪網路與儲存不夠快.
:   我倒不覺得架構有問題, 戶役政系統的Bussiness Logic 也不會牽涉到算法的問題
:   純粹是PM 不OK 沒有進行適當的風險規避以及沒有足夠的經驗判斷問題點.

新系統與舊系統的差別就反應在最近一系列新公布的規章上.

以結婚/離婚為例, 兩造帶了證件, "同時人到" "任一個戶政所" 都可辦理.
在人工的時代, 女方會先拿證件就其地遷出戶籍, 再拿到夫家戶政所入籍, 同
時依結婚證書登錄雙方關係, 同時更新戶口謄本與身份證.

在電子化之後, 各地形成了分散式資料庫. 理論上, 人工的遷移戶口用男方所
在地的戶政區公所的電子公文對女方所在地請求遷出, 並傳送戶籍謄本, 就能
遠地辦到. 但不論是否集中避免遠近的通訊延遲, 按地區建檔的資料庫還是可
以分區做data parallel的分queue各自處理.

不過, 這涉及請求與批准的權限, 直白一點就涉及"越權"與"入侵". 因此, 由
內政部統一發號施令是可避免一堆點對點的來往.

新系統顯然是集中單一權限的概念. 婚姻的登錄規章顯然因新的戶警分立與外
配而改了. 事情變成在任何戶政所都能登錄與更改身份證, 但最近新婚的需要
雙方同時到場驗證. 在某種程度上, 可能這是防止一夫配多妻的狀況發生.
手工時代, 本來從任何一方戶政所憑結婚證書與戶籍謄本, 就可以請求更改身
份證的配偶欄位記錄.

那時是很單純的.譬如女方, 1.查證 男女證書/原謄本記錄. 2.調出女戶籍原本
更新. 3.更新女謄本/身份證.

底下這是猜測的一個可能沒分析寫好造成dead lock的一個可能情形.

1.查證男女證書 2.向內政部發出配偶欄更新申請. 3.內政部通知更新男女方.
3a-1.男方戶政機查閱男方, 女方資料庫戶籍, 並企圖鎖住更新.3a-2.更新男方.
3b-1.女方戶政機查閱女方, 男方資料庫戶籍, 並企圖鎖住更新.3b-2.更新女方.

最明顯的dead lock 就是互相先等待對方發不了的信息.
3a-1開了男方,尚未拿到女方. 但同時3b-1卻已開了女方, 正等待男方. 雙方僵持
直到 default time-limit, 再由3.內政部 重新發出通知.

因為資料集中, 無法怪罪網路延遲, 通知更新的雙方很快又同時發生, 就等
time-out 再重來.
如果 男女方戶政機因不同負載有一方延遲, 就有可能不會互鎖, 就可能過關.

這就形成了time-dependent error, 時有時無, 很難正確查覺.

人工時代需要調閱戶籍謄本, 這是一個read-only 的 copy, 所以分散各地的戶政
所可以透過 預取的 read-only copy 各自平行處理, 不容易出這種錯.

以上純屬想像狀況. 目前的新系統顯然是有 許多新法規 要求要配合. 問題應該是
由這些新狀況引發的.
========
再說, 如果一個系統寫得很好, system admin 可能就沒事彰顯其重要性, 在這裁
員精簡的時代, BEA-000337 message 的發生, 可以保證增加幾個重要職缺.

:   至於分散式平行處理, 坦白說, 基本上台灣都是在local site處理, 沒有人在
:   metro-wide做分散式平行處理. 光network latency就會造成不輸給這次事件的delay

→ lovdkkkk:Thread.sleep(99999999); <-- dead lock?
→ saitoh:如果不知道wls判斷stuck thread的條件是什麼就不要亂猜了
→ alan3100:..我覺得直接找原文書來貼都比你在那解釋還清楚
stuck 未必來自dead lock, 但只要呆太久超過default值都會出此訊息.
那堆戶政機, 在新規範要求相互查核驗證下, 是會互動回饋的, 機會就有.

推 asdfghjklasd:問題你想拿學分還要他簽名..
→ gogohata:thread呆太久跟deadlock情況不一樣吧
※ 編輯: ggg12345        來自: 114.43.229.178       (03/18 15:56)
→ Lordaeron:WL的thread stuck只表示它的THREAD停很久,致於哪個
→ Lordaeron:thread為何停這麼久,要看寫的人在寫什麼.跟WL無關.
→ Lordaeron:簡單的說,你愛寫一個SLEEP/WAIT 100分鐘的,WL也管不著
推 luciferii:沒用過WebLogic但是看一行訊息就能斷古論今，不愧是教授