看板 Soft_Job 關於我們 聯絡資訊
※ 引述《ggg12345 (ggg)》之銘言: : ※ 引述《mephiliu (Mephi)》之銘言: : : 其實不是版本不相容, 我的推測(沒實際看到log就只能推測)基本上是weblogic內含的 : : JVM 在AIX 6.1 上面有一個bug, 在concurrent session 超過200個的時候會 : : crash. 如果壓力測試沒測到當然就再見. : : 這件事分別有weblogic端的patch與aix端的patch, 要看看log分析結果來決定上哪一種 : : 不過我覺得從weblogic這邊看比較有效.事實上這問題應該是解掉了. : : 最後, 大型商用系統是不會亂上patch的, 更不要說是上到最新. : : 常常這樣幹的人通常很快就要換工作了. : ======== : 超過 200 個會當, 這是那個檢驗報告說到的. : 這問題是超載? 還是 race dead-lock 或是 類似recursive stack overflow : 是能被區分的. 以System P 的狀況來說, 每機最小的配置都有64GB Memory以上, 再加上記憶體壓縮 所以200Client 是不可造成記憶體超載的. 這個其實是BUG, 他會在connection 到達200-250個時發生I/O socket錯誤, 導致所有 的Thread 都被block/pending : 只負擔200個, 確實很鳥! 但不深究, 表面的解法就是增加機器避免超載. : 不買 cpu 買 SSD 加速 disk access 就是減輕 access delay 也是一解. 如果在當機時memory 使用 20%, CPU 使用40%, Disk I/O 使用不到1% 加再多的機器也不會解. 詳參考BEA-000337 : 但請測試公司再測就知 SSD 是否有效? 顯然是無效, 可能就懷疑IBM AIX : 鎖了process/thread 數, 所以才去求 IBM ? 但顯然也沒解套. 其實是PM 沒有系統經驗所以沒辦法在第一時間判斷問題點, 僅猜測是資源不足造成 才會選擇加資源. 以EMC CX system 使用15 Disks 做成的Array, IOPS 在最佳狀態 是超過SSD 的IOPS的, 加SSD(而且沒買Disk Cache Lic)對系統運行是完全沒有幫助的. 求IBM 是因為本來就有軟體維護, 資拓自己的PM 找不到問題又不能分析core dump 當然是找IBM 處理. 不過在這方面我個人認為IBM support team 不如 Oracle support team專業. : Queue 拉長了, 再進來的不被drop行嗎? : 研考會的 "向上集中" 應該是 "集中式單一管理, 分散式平行處理", 但太 : 容易被誤會倒退回 "全集中管制處理". 戶役政的資料庫應該還是分散在各 : 戶政所的. 程式架構不分析好, 算法不想好, 自然就怪網路與儲存不夠快. 我倒不覺得架構有問題, 戶役政系統的Bussiness Logic 也不會牽涉到算法的問題 純粹是PM 不OK 沒有進行適當的風險規避以及沒有足夠的經驗判斷問題點. 至於分散式平行處理, 坦白說, 基本上台灣都是在local site處理, 沒有人在 metro-wide做分散式平行處理. 光network latency就會造成不輸給這次事件的delay -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 1.34.160.27
luciferii:你要知道ggg12345老師只是為了發文而發文,並沒有認真查 03/16 19:59
luciferii:所以也不用太認真跟他解釋 03/16 19:59
chester06:未看先猜G老師大概又會多開一個不知所云的thread 03/16 20:12
hopashin:推認真解釋 03/16 20:12
freeunixer:其實我是覺得很奇怪,曾老師想知道什麼,隨便找都能問到, 03/16 20:17
freeunixer:認識的有一卡車,又不是全死光.光在板上丟煙霧彈為那樁? 03/16 20:18
Lordaeron:會認識到資拓去?我是存疑的. 03/16 20:30
freeunixer:唉,你太淺了,這種話就麻煩你別在說了. 03/16 20:57
freeunixer:學界國科會資策會隨便拉,線就上百條. 03/16 20:58
freeunixer:別的不說,打從中央在公元前搞軟體工程搞沒出來,iii接去 03/16 20:59
freeunixer:這關係就可以從兩千多年講起... 03/16 20:59
freeunixer:難不成真有人以為在台灣,學界,公家跟業界還有護城河? 03/16 21:00
ggg12345:mephiliu的分析很有道理也很好.但這問題依然是透過socket 03/16 21:12
ggg12345:連線,連線數當然涉及queue buffer數.驗收的公司知道過200 03/16 21:14
ggg12345:會當,但沒說這是已知的BUG,還是故意設限.出問題的報導都 03/16 21:17
ggg12345:集中在跨區身份證這個最敏感的項目,這項是由內政部統一發 03/16 21:20
ggg12345:出的,顯然快不起來的在此,而非各地戶政所.跨區調件更新應 03/16 21:25
ggg12345:是集中發號施令全部都經過中央才生效,才會造成延遲又超載 03/16 21:31
kimkao:為何我感覺g老師好像腦袋裡已經有一套完整的系統架構圖? 03/16 21:56
kimkao:可以放個concurrency view & deployment view參考嗎? 03/16 21:57
kimkao:這整個討論串整個都在瞎子摸象阿!!! 03/16 21:58
luciferii:我是覺得一般狀況外的人來猜都不會猜得這麼牛頭不對馬嘴 03/16 22:04
kimkao:這整串讓我想到大陸之前在炒他們的火車票售票系統 03/16 22:04
kimkao:也是一群人在瘋狂罵系統開發團隊然後給了一堆所謂的解法 03/16 22:06
kimkao:但實際上是根本沒人把真實設計給拋出來看拿出來想 03/16 22:06
kimkao:事實上也不可能真的拿出來,萬一被網民給解決了 03/16 22:07
kimkao:那原開發團隊也就不用玩了!!! 03/16 22:07
ggg12345:看來luciferii是知情的,這題應該來自X安,怕講清楚就不安! 03/16 22:09
ggg12345:感覺出題要求的是X安,出狀況去監控幫忙的也是X安,有解乎? 03/16 22:15
ggg12345:如果是BEA-000337,照網文找是老問題,就是db處理慢,queue 03/17 00:09
ggg12345:積長,線程長多變超載.新系統可跨區更新取件,多擠在內政部 03/17 00:18
ggg12345:網上"老瓶装新酒,一次完整的应用调优"早說出其中問題了. 03/17 00:20
Lordaeron:@freeunixer,要是有,就不會一直自說自的了. 03/17 00:24
ggg12345:當然是不知情,才要問嘛.可跨區申報更新取件是這月才公布. 03/17 00:28
ggg12345:疑問是舊系統若照新加功能的這種集中號令控管仍然會管用? 03/17 00:32
freeunixer:乾脆老師扛一箱金牌生啤到台北來,我找人來說明好了(~誤 03/17 00:36
Lordaeron:哪不如你發一篇好好的說明好了. 如何? 03/17 00:37
ggg12345:管制理念架構不好又加上爛code,小問題演成輪流錢坑,能聽? 03/17 00:43
luciferii:freeunixer好衰,誠心要解惑還被嫌不夠格XD 03/17 00:50
freeunixer:那沒我的事了,我繼續去旁邊玩沙好了 (~默 03/17 00:57
ggg12345:此串原貼是freeunixer,報導說明應觀其背景動機是lu大提醒 03/17 01:03
asdfghjklasd:阿就是人的問題不是嗎? 03/17 01:44
jk47tai:就個人聽到,版本不合,是IBM確認的(2014),然後2013年 03/17 09:36
jk47tai:就知道又這問題。 03/17 09:36