請教各位大大
以下這樣的人數與規格 在使用系統上會有延遲情況
該如何解決
據廠商告知 是記憶體太少 . 但初步觀察 4G記憶體僅消耗1.5G
而cpu 更是沒啥跳動.
查網路想請問各位大大 此種規格是否會影響系統運作速度
又 sql2000 可否支援超過2G記憶體. 網路說法不一
聽起來好像是多年前我遇到某個鼎X的問題.
我的處理方法如下.(其它的erp也可以這樣處理)
1 windows 2003 server 每週維護一次.
2 sql 2000 server 最好每週維護db一次(含壓縮及備份.)
3 erp中只有單一台主機處理.db+report+派班(或是其它)
如是請問這台主機會不會沒有更新過.2-3年主機最好升級一次.(主機升級)
4 了解整個網路的流量和使用情況.會不會是其它的網路問題引起的LAG.
5 除了看cpu使用量及記憶體使用量,erp的主機網路卡的使用量也需要了解及規劃.
5 db中的資料如果按年份分有2-3年以上.
可以把db切開按年份來進erp.
附上.SQL Server 2000 Standard Edition 僅支援到2GB 的記憶體
如要使用超過2GB 以上請參考microsoft 文件設定.
gavinnokia提到:
中只有單一台主機處理.db+rep
謝謝您回答
這台主機是全新的 今年八月買
更新也是已經到最新的.
是否可以說明一下主機規格.erp軟體名稱.db是否有設定過.
及db是否為SQL Server 2000 Standard Edition.謝謝.
回應
是將舊系統DB搬到新購主機嗎,資料庫與交易紀錄檔有沒有太大(超過10G以上)?另外有將SQL Server記憶體參數做調整嗎?
還有慢是連打單時候慢(寫入),還是只有在跑報表時慢(查詢)。
因為使用者跑報表下錯範圍加上資料庫大,光是磁碟I/O就可以拖慢整個系統。
是舊資料庫轉入. 資料庫大小約800m
記憶體參數是沒有調整. 很怕調整後會出問題.
慢的時候是 讀取慢 ,也可說查詢慢沒錯.
磁碟io 該如何測試 ?
db 是 Microsoft SQL Enterprise Manager
erp 系統 是 eep.net 設計的
不知 allen1975 可否按 各位大大的方法.
先提供資訊給大家,了解您的case是卡在那一個地方.
才好幫忙提供解決的方法.
eep.net 訊光出的產品.
如 raytracy 大大 提的.CPU,RAM,HDD. 有監測數值出來, 才能討論問題是塞在哪裡?(還有net也要哦)
等你的數據中,加油吧.
http://www.infolight.com/discuss/index_view.asp?status=open&no=232101&I1401=28
可能訊光EEP .NET程式問題寫法比較大吧。
建議你還是上訊光的討論區去問吧...
http://www.infolight.com.tw/discuss/index.asp?status=open&I1401=16
gavinnokia提到:
eep.net 訊光出的產品.
若是用 EEP 的話, 請順便也考慮一下 EEP 工具的可靠度....
我去年受邀幫國內某家臍帶血中心, 檢測 SQL 效能慢的問題時, 就發現問題都不是出在我們上面所猜的幾個項目, 而是 EEP 工具在傳輸過程中, 自己會掉資料(透過 Sniffer 抓兩端的網路封包出來比對後發現的), 掉資料後 EPP 會重新發動傳送流程, 所以中間做了很多白工, 才導致反應變慢. 而這個問題跟 SQL 或硬體都無關, 是 EEP 工具本身的問題.
但因我不是程式專家, 無法對此問題提出改善建議, 只能建議他們直接找訊光解決. 後來聽說當時接下這個軟體開發案的廠商, 好像因為此問題一直無法驗收結案....因事隔一年了, 我也不知他們最後是如何解決的...
這台主機是全新的 今年八月買
更新也是已經到最新的.sql2000==> EOL and EOSL now !
不知道是否為樓上朋友分享的鼎X系統。
如果是... 在資料多的狀態下,有人下錯條件or條件較大整個系統就像死掉一樣...
這問題,我自己以為架構不改是沒解的。
自己走過的路跟您分享,但這些都不是問題解決的方案,最後還是進行DB分割。
‧SQL由Std. 換成Ent. 版:有快一點,但死掉的狀態依舊。
‧HDD升級為 15k:有快一點但還是會死。
‧系統、DB、暫存分不同的實體HDD,還是會死。
‧換更快的機器,還是會死...
最後還是將資料分為: 即時(所有),備份(今天以前)..
==>如果不需要跑到當天資料的報表,通通改為抓前一天資料的DB。
--//因為下方有人翻出古董文章,所以我也來更新一下@2022/11/17。
DB:改用 全SSD的,速度提升有感。為了安全,同外接儲存多HDD一套RAID。外部NAS RAID6放多台+冷儲存。
AP:跟DB一起用ESXi虛擬化很多年,但儲存依據需求有的在SSD,有的在HDD。
我這樣說不知是否有幫助,就是:依據用途有不同的AP、DB,資料要切割!
CPU 不忙, RAM 不塞, 那就剩下 HDD 最可疑了:
「恭喜」!又有一個相同的案例了...
我們公司因為要升級ERP的DB SERVER,在之前換了一台全新的IBM 3650 M2,沒錯,就是跟大大同一款的,結果,跑起來的狀況與大大描述的一模一樣,有找IBM更新了軔體,結果還是一樣,最後找了ERP的廠商問了一下,問了才知道,他們的客戶有相同情況的還真不少,基本上應該是那款SERVER的硬體有些問題,就連原廠的維修工程師也這樣說...
最後,我們只好再換一台SERVER,HP的,那一台只能束之高閣,頂多跑跑一些不重要的服務
請問大大貴公司用哪款 可否推薦下
Very curious about the IBM x3650 M2 has the performance issue (Intel Nehalem), Wondering the old and out of date ERP "system software" (OS + DB engine )is the culprit to cause the performance issue. Recently, the new data center deployed 46x 42U racks with IBM x3650 M3 (Westmere) around 800 units (1xsocket, 12GB), Windows 2008 R2 Enterprise + SQL Server 2008+FCoE CNA HBA +SAN storage, the overall performance are excellent.
allen1975提到:
請問大大貴公司用哪款
後來,我們很快就換了等級類似的HP DL380G6,目前一切都還OK,僅供參考囉
Based on SAP SD ECC 2-tiers result as below:
The x3650 M2 achieved 5,100 SAP SD Benchmark users with 1.98 seconds average dialog response time,
25,530 SAPS, measured throughput of 1,532,000 dialog steps per hour (or 510,670 fully processed line
items per hour), and an average CPU utilization of 99 percent for the central server.
The x3650 M2’s 2-processor result of 5,100 SAP SD Benchmark users beats the score of 4,995 SAP SD
Benchmark users achieved by the HP ProLiant DL380 G6 using the same processors and the same amount
and type of memory.
雖然我個人也不喜歡用 IBM 的 Server, 但是光憑以上的理由, 就要把機器換掉? 若我是主管, 肯定簽不下去...
學理工的人應該要講求證據與事實, 就算機器慢, 有問題, 也應該有個原因, 不能把答案推給一個未知的黑洞, 用這樣的態度走下去, 公司的管理遲早會出問題.
我去年有個客戶, 同樣用 x3650 M2 (3GB RAM), 同樣有反應速度慢的問題, 原本廠商也是歸罪於機器, 要求客戶換型號, 但經我監測所有數據, 根據數據結果來調整軟硬體架構之後, 已經不再出現反映慢的問題, 原機一直沿用至今, 都不再被員工嫌慢. (該客戶基本資料庫大約 80GB, 每天異動資料有 11GB, 每次跑一個 Report 大約要 Qeury 22 萬筆 record).
請問大大 系統架構是如何. 也是跑 SQL 還是其他種類資料庫
使用人數約多少呢.
allen1975提到:
請問大大 系統架構是如何. 也是跑 SQL 還是其他種類資料庫
MS-SQL 2000, 約 60 人使用, 該機也跑 AP, 另有一台專跑 Report, 但會來該機 SQL 拉資料.
問題是卡在原有 HDD 的 IOPS 太低 (監測到的 IOPS 需求約是 1,7xx, 但硬體只能提供 140, 相差 10 幾倍), 後來是用 iSCSI 把儲存拉出來到 IP-SAN 設備, 用了 15 顆 15K 的 SAS 硬碟, 加上 1GB 的 Disk Cache, 把 IOPS 提升到 3,450 就解決了.
很多人會誤以為 HDD 的 Throughput (傳輸效率) 就是效能指標, 拼命去追求 xxx MB/sec 的讀寫速度; 卻不知道: SQL Transaction 對於 Throughput 的敏感度不見得很高, 但若 IOPS 不夠卻很容易卡住, 積了一大堆 I/O Command queue 消化不掉.
以上例來說, AP 實際用到的 Throughput 只需要 90MB/sec 左右, 而該機可以提供的 Throughput 高達 150MB/sec 以上, 所以當我判定為 HDD 效能不夠時, MIS 沒有一個人相信我說的 (他們想: 150MB/s 怎麼可能不夠 90MB/s 的 AP 用? 邏輯不通吧?...). 但是我從監測中看到的, 卻是 HDD 來不及處理 IOPS, 且效能不足達 10 倍以上 (奇怪的是, MIS 都沒人知道要去看 IOPS...).
換了架構了, Throughput 並沒有提升多少 (反正 AP 只需要 90MB/sec, 再往上提升也是白費), 但是 IOPS 提升的程度, 大幅改善了 SQL 的反應速度.
raytracy提到:
MIS 都沒人知道要去看 IOPS...
這種事情常發生,RAY大您別介意...
其實這樣的說法,真的有點牽強,我有User目前資料庫使用SQL2000 單一資料庫約50G,每日異動約2G多同步查詢約90-100U,規劃的機器為ASUS入門型SERVER * 2一台作為AP另外一台作為DB,一樣順順順...
同樣的硬體.同樣的軟體.有可能有的人用出來的環境就很順.也有的人用出來就會卡卡的.
重點是用心.及抓問題的方法.祝 allen1975 早日找到處理問題的點.
May try this way ?! If can get the other LSI Raid card from your vendor.
OS : 2xinternal disks, raid1 ( uses integrataed raid port)==> C: drive
Data : 4x internal disk, IBM-LSI raid card, Raid5 ==> D: drive, ERP data only and workflow+DB Engines
請問 seiko133 大大 你這系統 . 規格如何
系統是跑 standrad or enterprise
ram ?
hdd 架構 ?