請問旗下有 Exchange 2003 的 IT 同仁們

achen

這兩天我們公司的一台 Exchange 2003 Server 開始出現很嚴重的效能問題, 基本上所有收發與 public store 功能都沒問題, 但是所有的用戶 Outlook 都會不時出現類似 "Outlook 正在與 Exchange Sever 洽詢資料..." 的訊息, 等mail 清單出現有時要等個一兩分鐘.

我目前還抓不到問題根源, 但是比較懷疑的是 private store 的總容量過大, 在這台 server 上已經達到 72 GB, 因為我們有很多台 Exchange 分散在不同的 VPN LAN 下, 所以並沒有購買價錢貴四倍的 Enterprise 版本,  因此上面的 size 是單一個 Storage Group (edb= 50 GB, stm=22 GB).

請問這樣的 size 是否有可能造成 performance 問題? 我今晚把它下線作 offline defrag, 但是過了四個小時, 只完成  8% 左右, 看來明早還沒做完還是得把它取消掉把 IS 弄上線, 然後整天再準備接幾百通詢問的電話  (煩啊..)

[ 本文最後由 achen 於 2008-6-13 06:21 編輯 ]

achen

原文由 筠心 於 2008-6-13 07:10 發表
問兩個問題:
1.有做備份嗎? 指的是使用OS內建(或第三方公司出的)備份軟體做備份
2.網路設備的MTU值是否調太小?

第一個是因為,Exchange2003做備份時, 會把多餘的交易檔清掉(也就是會縮小目錄容量),而且User在連接時也不用做多餘的查詢動作

第二個是,Exchange的封包比一般的大,如果MTU值調太低,會造成一直重Resquest的問題

1. 當然有,  但是就算沒有, 那些 log files 的存在並不影響資料庫的大小, 他們只是在 Exchange 當掉的時候可以用來搭配最後一個成功的備份, 進行修復的動作.

我不認為User在連接時會去查詢這些 log 檔案, 因為 Information Store service 本身都不會管這些檔了 (你可以隨時刪除或搬移), user 連接時為何要去查詢?  (<- 個人觀點, 歡迎指證)

2. 老實說對這個問題, 我不知道封包的大小是設多少, 但是網路內部其他所有服務都沒有問題, 包括其他的 Exchange Server. 所以我想這是在單一 server 自己的問題.

achen

原文由 cch1970 於 2008-6-13 06:24 發表

這樣做是假定寫回去的位置已經是連續的了,而沒有fragment的狀況?

這個假定在現實上很難成立

因為 Exchange 的 offline defrag 是先建立兩個臨時檔案
等到完成後, 用這兩個檔去取代原本的 .edb 和 .stm

如果硬碟已經沒有連續空間, 那這兩個檔本身也會很散.
如果 temp folder 是指定不同的硬碟, 那就算他們做好後是連續的, 寫回 Exchange 那顆 drive 也會變分散.

我自己的不負責想法啦,  Exchange 的資料庫, 也許檔案的 fragmentation 不是太大的問題. 因為只要 Exchange server 在跑, 不斷在收發 email, 檔案內容每秒鐘都在變更, 你如何期望它可以不 fragmented ???

筠心

問兩個問題:
1.有做備份嗎? 指的是使用OS內建(或第三方公司出的)備份軟體做備份
2.網路設備的MTU值是否調太小?

第一個是因為,Exchange2003做備份時, 會把多餘的交易檔清掉(也就是會縮小目錄容量),而且User在連接時也不用做多餘的查詢動作

第二個是,Exchange的封包比一般的大,如果MTU值調太低,會造成一直重Resquest的問題

希望對你有幫助

cch1970

原文由 gcvincent 於 2008-6-13 15:49 發表
我不懂exchange,

如果下線，備份72GB資料後，清除硬碟資料，再將72GB復原蓋回去。
是不是跟defrag差不多，但是快很多？

這樣做是假定寫回去的位置已經是連續的了,而沒有fragment的狀況?

achen

原文由 gcvincent 於 2008-6-12 23:49 發表
我不懂exchange,

如果下線，備份72GB資料後，清除硬碟資料，再將72GB復原蓋回去。
是不是跟defrag差不多，但是快很多？

Exchange 的 defrag 和硬碟的 defrag 是有不同效果的
雖然名稱是 defrag, 不如說是 compact 比較洽當, 因為它有縮小檔案 size 的功能 (假設你有備份的前提下)

當然你說的 hard disk fragmentation 也有可能造成效能問題, 但是一般情況下 Exchange 遇到問題, 都是從 Exchange 本身先下手去除錯
先把 Exchange 最佳化之後, 再去作 disk I/O 最佳化.

很慶幸昨晚的 offline defrag 在凌晨六點完成了, private store 縮減為 60GB (edb= 43 GB, stm=17 GB).  IS 上線後看起來蠻正常的. 等到八點更多人開  Outlook 後就知道有沒有效了.

小酒蟲

我管的 Exchange v5.5 之中，private store 大約是 50GB；目前每三個月會利用週末 offline 讓 PerfectDisk 去做一次 defrag，每次大約一個晚上搞定。

至於備份 72GB 再覆寫...你絕對不會想在 Enterprise servers 上做這種傻事。

gcvincent

我不懂exchange,

如果下線，備份72GB資料後，清除硬碟資料，再將72GB復原蓋回去。
是不是跟defrag差不多，但是快很多？