最近問題處理到一個進度來回報一下 :ase

目前是傾向修改ISCSI軟體來解決會離線的問題

我抓幾段廠商回覆我的一些說明:
=================================================
總共有11個IP連到我們的Iscsi 陣列192.168.0.99:3260 PORT上。
連線iscsi Command 300~400個指令，當攝影機越多，則資料指令數就會越來越多。
不管指令數是屬於資料還是攻擊的指令，反正就是有存在.
還是建議客戶1台主機對1台iscsi陣列，最好不要超過32攝影機，因為指令數太多了。有點跨張
(因為正常跟Server對接，標準只會看到1個ip, 大約1個Iscsi指令，約6個i/o數)。
舊版的軟體，在系統碟上跑，i/o指令數會過多，會拖到系統檔掛掉。
把iscsi系統做成在記憶體上跑的唯讀架構，因為RAM的讀寫是百萬次，
新的架構可以避免指數過多，所引起的I/O瞬間掛點現像。
=================================================

看起來感覺是監控軟體架構與ISCSI軟體會有些相容性問題

一般來說攝影機影像都是集中在監控主機上再轉到ISCSI上儲存

但是該廠商的攝影機影像是不透過監控主機而是直接傳送到ISCSI儲存

這樣變成同時間這台ISCSI設備是同時被許多IP連接傳輸資料

而廠商回覆攝影機除了傳送影像資料外還有許多的不知名封包也在大量傳送

如果同時連接越多攝影機會造成同時間會有大量指令去塞爆系統造成當機

不知道我這樣的理解對不對.. :ase

一堆IPCAM同時連上一台iSCSI target寫入正好是機械式storage的罩門(i.e.保證是一大坨random seek:stupefy: ),如果iSCSI target的resource還夠的話或許可以透過queue的方式降低random seek的影響(i.e.先寫入RAM,再盡可能以sequence seek方式寫入機械式storage),但queue還是有極限的,而且也要付出可靠性的代價,目前代價最低的處理方式應該是先加RAM和換CPU(i.e. i5或i7/E3,不過考量到板子是LGA1155的,現在換CPU好像不太實際:stupefy: ),如果RAID卡夠力的話把writeback cache打開也會有所幫助,跟switch關連應該不大就是了:ase....

PS:反正年底快到了,鵝還有特休沒休完,如果有空休的話只要幫鵝出高鐵票和午餐錢鵝可以到高雄一日遊,有興趣的話再pm給鵝吧:p:p....

我們公司目前有二套db在run.....一套是oracle，另一套是mssql....
對應的ap系統，在串接撈二個db的資料時，效率真的很差....
:jolin: :jolin: :jolin:

但是又不可能打掉重練....就只能每天凌晨排程，讓db轉檔來、轉檔去的....解決這個問題。



oracle的好處...

省下來的ma費，會要你一補齊..... :laugh: :laugh: :laugh: