איטיות בשרת דואר

[sprinter]

שלום,

יש לי 2 שרתי Exchange 2010 שעובדים בDAG.

לאחרונה חלק מהמשתמשים חווים העלאה איטית מאוד של התיבות שלהם בארגון.

משמע התיבה עולה ולוקח לה בין 2 ל 4 דקות (פעם זה לקח כמה שניות)...

גם כשהם כבר בתוך התיבות שלהם אז מעבר לתיקיות אחרות(משותפות) גם לוקח זמן...

שאלות:

1. רציתי להבין מה קורה ברקע כשהם טוענים את ה Outlook שלהם? האם מבוצעת משיכה של כל המידע מהשרת דואר בכל פעם?

או שמבוצע סנכרון רק פעם אחת ואז כשמעלים בפעמים הבאות אז רק נוצר קשר לשרת דואר?

2. איזה כיוון לדעתכם כדי לי לבדוק?

מה שנבדק:

1. 2 שרתי הדואר עם מספיק זיכרון בדיסק הקשיח ומתפקדים בצורה טובה.

2. נבדק זיכרון RAM באחד מהשרתים יש לי רק 2 ג'יגה פנויים. האם זה מספיק?

3. חשבתי לכיוון שאולי התיבות גדולות מדי אבל יש אצלנו חלק מהמשתמשים שיש להם תיבות ענק של 30 ג' ואצלהם אין בעיה והטעינה מהירה מאוד לעומת משתמשים שיש להם תיבות של 2 ג' והם חווים איטיות אז זה לא זה...

4. בוצע ניתור ל Switch החשובים והכל תקין.

תודה

[Roger That]

1. במצב של cache exchange ב outlook נמשך מידע מהשרת אל קובץ מקומי. לא יודע אם הכל, אבל נמשך. לדעתי עדיף לעבוד עם פונקציה זו מבוטלת, כאשר מדובר ברשת מקומית.

2. את הכיוון הנ"ל + לבדוק עם יש שגיאות בלוגים של השרתים. בנוסף:

האם קיים store database אחד או יותר ?

מהוא גודלו / גודלם של ה databases? רצוי שכל אחד לא יהיה מעל 100GB על פי מיקרוסופט.

האם מתבצע כל לילה online defrag ברמת exchange ? ( ה maintenance היומי)

האם בצעת היי פעם offline defrag ברמת exchange ?

[DXM]

אתה יודע, אם יש להם תיבות בגדלים האלה, והם לא שומרים עותקים מקומיים, מאוד הגיוני שיהיה להם בעיה בלמשוך את התיבה. יש מצב שבו התיבה מושכת רק את הכותרות של המייל ולא את כל המייל עצמו ורק במידה והמשתמש רוצה לפתוח מייל אז הוא נמשך...

בכל מקרה האם השרתי EXCHANGE שלך מכילים את כל ROLE עליהם או רק ROLE אחד?

[taurus007]

1. יש ערך שאתה יכול לנטר אותו ובמידה שאכן יש עיכוב במשיכה עצמה של הCLIENT מול הEXCHANGE אז אתה תראה חריגות - לא זוכר את הערך המדוייק אבל בperfmon זה נמצא תחת msexchangeIS אחד הערכים שם - אם מישהו בפורום זוכר אז נחמד אם לא אז אבדוק לך .

והאם האאוטלוק במצב של cache mode או ללא המצב הזה ? - כי ללא המצב הזה מאוד הגיוני האיטיות כמו שאמרו קודמיי , אם המצב הזה קיים ויש וי והתקשורת תקינה - אז ניתן לסנכרן מחדש את הOST אולי יש תקלה בקובץ או לבדוק את הערכים אם הם תקינים

2. איך בדקת את הסוויץ ? תעשה העתק הדבק של קובץ גדול תראה את הקצב העברה אם הוא תקין לשני כיוונים - אם התיבות 30 ג'יגה תקינות וה2 ג'יגה לא- אז מדובר על אותו STORE או STORE אחר ? (אולי אחד פגום) או שהתקשורת בתחנות לא טובה

3. 2 ג'יגה פנויים לשרת לא מספיק בדרך כלל אין לך PAGEFILE פעיל ?

קיצר יש הרבה לבדוק עדיין - אם התיבות על אותו STORE , אולי אחד הSTORE נמצא על כונן SATA ולא SAS - שני השרתים עם אותה קונפיגרציה ?

בדקת דיסקים בשרתים ?

בעע יותר מידי לבדוק , תתחיל פה נתקדם הלאה עם התוצאות :]

[sprinter]

1. יש ערך שאתה יכול לנטר אותו ובמידה שאכן יש עיכוב במשיכה עצמה של הCLIENT מול הEXCHANGE אז אתה תראה חריגות - לא זוכר את הערך המדוייק אבל בperfmon זה נמצא תחת msexchangeIS אחד הערכים שם - אם מישהו בפורום זוכר אז נחמד אם לא אז אבדוק לך .

והאם האאוטלוק במצב של cache mode או ללא המצב הזה ? - כי ללא המצב הזה מאוד הגיוני האיטיות כמו שאמרו קודמיי , אם המצב הזה קיים ויש וי והתקשורת תקינה - אז ניתן לסנכרן מחדש את הOST אולי יש תקלה בקובץ או לבדוק את הערכים אם הם תקינים

2. איך בדקת את הסוויץ ? תעשה העתק הדבק של קובץ גדול תראה את הקצב העברה אם הוא תקין לשני כיוונים - אם התיבות 30 ג'יגה תקינות וה2 ג'יגה לא- אז מדובר על אותו STORE או STORE אחר ? (אולי אחד פגום) או שהתקשורת בתחנות לא טובה

3. 2 ג'יגה פנויים לשרת לא מספיק בדרך כלל אין לך PAGEFILE פעיל ?

קיצר יש הרבה לבדוק עדיין - אם התיבות על אותו STORE , אולי אחד הSTORE נמצא על כונן SATA ולא SAS - שני השרתים עם אותה קונפיגרציה ?

בדקת דיסקים בשרתים ?

בעע יותר מידי לבדוק , תתחיל פה נתקדם הלאה עם התוצאות :]

תודה רבה על התשובה אך כמה שאלות...

1. האם מומלץ לעבוד עם

cache mode בארגון או לא? אנחנו עובדים בלי מצב cache mode מה שאומר שכל פעם שמשתמש טוען תיבה אז כל המידע יורד מהשרת דואר במלואו מכיוון שאין OST, נכון ?

2. מה הם פעולות התחזוקה המומלצות לשרת דואר ארגוני? ( 250 תיבות)

תודה

[taurus007]

תודה רבה על התשובה אך כמה שאלות...

1. האם מומלץ לעבוד עם

cache mode בארגון או לא? אנחנו עובדים בלי מצב cache mode מה שאומר שכל פעם שמשתמש טוען תיבה אז כל המידע יורד מהשרת דואר במלואו מכיוון שאין OST, נכון ?

2. מה הם פעולות התחזוקה המומלצות לשרת דואר ארגוני? ( 250 תיבות)

תודה

1. כן מומלץ לעבוד עם CACHED MODE , וכן הדואר יורד מחדש להלן לינק שמצאתי שמאוד מוצלח בנושא http://technet.microsoft.com/en-us/library/jj683103.aspx

2. איזה שרת EXCHANGE יש לך ENT או STD ?- בכל מקרה בשניהם עדיף לחלק את התיבות לכמה STORE שלא הכל ישב בSTORE אחד , אפשר לחלק את זה לפי מחלקות/שמות/סטטוסים(אנשי VIP וכדומה) ובכך אתה יוצר לעצמך שני מצבים , אם STORE אחד נופל אז זה לא מפיל את כולם אלא חלק , ושחזור מגיבוי יהיה הרבה יותר מהיר כי אתה משחזר מSTORE שהוא יותר קטן

ההבדל שרלוונטי לנו בין STD לENT וזה למה שאלתי כי בגרסת ENT(ENTERPRISE) אפשר להשתמש בבלי סוף DB (אם אני זוכר נכון) ובSTD(STANDARD) אפשר להשתמש עד 5 אז זה משנה את הצורה שמסתכלים ומתכננים את זה

[dady]

1. כן מומלץ לעבוד עם CACHED MODE , וכן הדואר יורד מחדש להלן לינק שמצאתי שמאוד מוצלח בנושא http://technet.microsoft.com/en-us/library/jj683103.aspx

2. איזה שרת EXCHANGE יש לך ENT או STD ?- בכל מקרה בשניהם עדיף לחלק את התיבות לכמה STORE שלא הכל ישב בSTORE אחד , אפשר לחלק את זה לפי מחלקות/שמות/סטטוסים(אנשי VIP וכדומה) ובכך אתה יוצר לעצמך שני מצבים , אם STORE אחד נופל אז זה לא מפיל את כולם אלא חלק , ושחזור מגיבוי יהיה הרבה יותר מהיר כי אתה משחזר מSTORE שהוא יותר קטן

ההבדל שרלוונטי לנו בין STD לENT וזה למה שאלתי כי בגרסת ENT(ENTERPRISE) אפשר להשתמש בבלי סוף DB (אם אני זוכר נכון) ובSTD(STANDARD) אפשר להשתמש עד 5 אז זה משנה את הצורה שמסתכלים ומתכננים את זה

1) עד כמה שידוע לי, לאו דווקא מומלץ לעבוד עם CACHED MODE. זה גורם להרבה בעיות סנכרון (יומנים וכו'). אין שום סיבה לעבוד בצורה זו אלא אם מדובר בניידים אשר אנשים רוצים לקרוא מיילים במצב OFFLINE מה שהיה נכון לגבי העבר שלא הייתה ממש גישה לאינטרנט מכל מקום. היום יש גישה לאינטרנט מכל חור ואפשר גם דרך טלפון נייד ודונגלים למיניהם. המקום היחיד שאני יכול לחשוב עליו שאסור לגלוש בו זה בטיסות וגם זה נדמה לי רק בהמראה ונחיתה.

בנוסף, לא זכור לי שכאשר עובדים עובדים במצב ONLINE טהור (דהיינו ללא CACHED MODE) יורד משהו למחשב עליו מותקן האוטלוק. האוטלוק הוא יותר תוכנה בסגנון VIEWER כדי לעבוד על התיבה שנמצאת בשרת הדואר.

- - - תגובה אוחדה: - - -

שלום,

יש לי 2 שרתי Exchange 2010 שעובדים בDAG.

לאחרונה חלק מהמשתמשים חווים העלאה איטית מאוד של התיבות שלהם בארגון.

משמע התיבה עולה ולוקח לה בין 2 ל 4 דקות (פעם זה לקח כמה שניות)...

גם כשהם כבר בתוך התיבות שלהם אז מעבר לתיקיות אחרות(משותפות) גם לוקח זמן...

שאלות:

1. רציתי להבין מה קורה ברקע כשהם טוענים את ה Outlook שלהם? האם מבוצעת משיכה של כל המידע מהשרת דואר בכל פעם?

או שמבוצע סנכרון רק פעם אחת ואז כשמעלים בפעמים הבאות אז רק נוצר קשר לשרת דואר?

2. איזה כיוון לדעתכם כדי לי לבדוק?

מה שנבדק:

1. 2 שרתי הדואר עם מספיק זיכרון בדיסק הקשיח ומתפקדים בצורה טובה.

2. נבדק זיכרון RAM באחד מהשרתים יש לי רק 2 ג'יגה פנויים. האם זה מספיק?

3. חשבתי לכיוון שאולי התיבות גדולות מדי אבל יש אצלנו חלק מהמשתמשים שיש להם תיבות ענק של 30 ג' ואצלהם אין בעיה והטעינה מהירה מאוד לעומת משתמשים שיש להם תיבות של 2 ג' והם חווים איטיות אז זה לא זה...

4. בוצע ניתור ל Switch החשובים והכל תקין.

תודה

2. לא כתבת כמה זיכרון יש לכל שרת בכללי. אם באחד מהם יש 2 GB פנויים, זה מתוך כמה?

3. נתחיל עם זה שתיבות בגודל של 30GB זה מעל ומעבר ואף מוגזם. כמו שרשמו כאן לפני, האם כל 250 התיבות יושבות על DATA STORE אחד או שיש כמה?

לא הגיוני בעליל שהאוטלוק עם תיבות דואר של 30GB יעלה מהר יותר מאלו של 2GB.

האם זה קורה במשך כל היום או בשעות מסוימות? האם רצה על שרתי הדואר תוכנת אנטי וירוס מותאמת לשרתי דואר?

האם בדקת ב TASK MANAGER אם יש משהו מעיק על המערכת?

[Support]

מניסיון בעבודה של למעלה מ-20 ארגונים, שחלקם מוגדרים ENTERPRICE (מעל ל-5,000 עובדים) רובם עובדים בצורה הבאה:

עבודה רק של CACHED EXCHANGE. הדבר מאפשר עבודה הרבה יותר מהירה, הורדת לחץ מהשרת, ויצירת מצב שבו המיילים הולכים לכל מקום ובמידה ויש תקלות רשת - המיילים עדיין קיימים וניתן לעבוד עליהם (וגם בתוך הארגון במידה ויש סוויץ' תקול או נקודת רשת שלא עובדת).

לאחר מכן, הרבה מהארגונים יוצרים חוקים שלא מאפשרים תיבה מעל 15GB או 25GB (יוצאי דופן הם בדר"כ בעלי הדרג הגבוה - סמנכ"ל ומנכ"ל).

הדבר הנ"ל מחייב אנשים ליצור ארכיונים פרטיים או למחוק מיילים שהם לא זקוקים.

במידה ואדם ספציפי בחברה זקוק לנפח גדול יותר - ניתן להגדיל לו את הנפח או ליצור ארכיון בכונן חיצוני.

הרעיון המרכזי מבחינת החברות - להוריד לחץ מהשרת וליצור מצב שאם יש תקלות - זה ברמת התחנות ולא ברמת השרת, דבר שגורר השבתה כללית של החברה.

זה לא מבטיח שלא יהיו תקלות - אבל זה מוריד את האפשרות שזה יקרה.

ועצה אחרונה - השרת עצמו. במידה והאיטיות נובעת מחומרה - לבדוק האם יש כונני SAS, האם יש RAID (ובמידה וכן, איזה? MIRROR? עבודה כפולה = איטיות).

לבדוק האם השרת עמוס מקבצים אחרים או שירותים אחרים שפועלים עליו. לבדוק ב-TASK MANAGER האם ה-CPU או הזכרונות כמעט מלאים.

אני מניח שהשרת דואר מתפקד גם כעוד שרת - איזה שרת?

בהצלחה בביצוע מה שתחבר לעשות, ותעדכן אותנו מה התוצאות.