推 ggg12345:這應該是官老爺跟記者們用錢可以買通擊穿任何護身的思惟. 03/22 08:21
→ ggg12345:也就是有錢能使鬼推磨,用錢(資本)就能買動技術人員的思惟 03/22 08:24
推 liunate:看不懂樓上在推什麼 03/22 18:00
推 atpx:樓上的意思是, 大家都以為隨便亂搞沒差, 反正最後花錢請IBM 03/23 16:09
→ atpx: 1F 03/23 16:10
→ atpx:出來收爛攤就沒事的思維 03/23 16:10
※ 引述《mephiliu (Mephi)》之銘言：
: ※ 引述《ggg12345 (ggg)》之銘言：
: : ========
: : 超過 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專業.
報給您知
IBM SUPPORT TEAM在這個新聞的時間點裡是沒有進去的
所以不知道您 "IBM support team 不如 Oracle suppor team專業"的結論是從何而來
這個案子裡 該向IBM買的SUPPORT SERVICE沒有完成前
IBM自然也不會進場處理經銷商或SI自己硬幹搞出的TROUBLE
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 220.139.147.210