ExchangeIS Fehler und Serverlast während Exchange Konsistenzprüfung
Guten Tag allerseits,
Ich habe folgendes Phänomen auf einem SBS 2011 zu verzeichnen. Immer wenn ich mittels Windows Backup oder BackupAssist (basiert auf Windows Backup Engine) ein Backup erstelle wird der Server sehr träge. Verbinden via RDP ist dann quasi nicht möglich. Ebenfalls wird mir folgender Fehler pro Backup meistens einmal geloggt:
Protokollname: Application
Quelle: MSExchangeIS
Datum: 17.08.2015 23:54:22
Ereignis-ID: 10026
Aufgabenkategorie:Allgemein
Ebene: Fehler
Schlüsselwörter:Klassisch
Benutzer: Nicht zutreffend
Computer: FSTOPLINE.toplineag.local
Beschreibung:
Es gibt 10 RPC-Anforderungen für die Datenbank 'DATENBANK: /o=First Organization/ou=Exchange Administrative Group (XXXXXXXX)/cn=Configuration/cn=Servers/cn=SERVER/cn=Microsoft Private MDB', deren Ausführung ungewöhnlich lange gedauert hat. Dies kann ein Hinweis auf Leistungsprobleme Ihres Servers sein.
Theoretisch würde ich darauf tippen, dass mein SATA Raid 1 an die Grenze kommt und deshalb alles so träge wird. Was ich aber nicht nachvollziehen kann: Dies passiert nur während der Konsistenzprüfung. Während der täglichen Arbeit sowie dem effektiven Backup etc. läuft alles tadellos. Auch die Dauer der Prüfung (ca. 20 Minuten) ist meines erachtens im normalen Rahmen.
Der Server ist logsicherweise als DC konfiguriert. Es wird nur der Exchange aktiv eingesetzt. Daten etc. sind auf einem NAS abgelegt.
Ich weiss: SAS wäre sicher optimaler gerade in solchen Fällen. Wird auch bei Gelegenheit geprüft.
Ist dies ein Bug, dass die Prüfung soviel Daten schaufelt? Kann ich das ignorieren wenn es nur während diesem Ereignis passiert? Kann man diese Prüfung evtl. etwas "begrenzen"?
Ich habe auch andere SBS Maschinen mit SATA und Exchange im Einsatz und konnte dieses Phänomen so noch nie beobachten.
Eingebaut ist ein SAS 6/IR Controller. Hauptspeicher 32 GB.
Gruss und danke schonmal,
Christof
Ich habe folgendes Phänomen auf einem SBS 2011 zu verzeichnen. Immer wenn ich mittels Windows Backup oder BackupAssist (basiert auf Windows Backup Engine) ein Backup erstelle wird der Server sehr träge. Verbinden via RDP ist dann quasi nicht möglich. Ebenfalls wird mir folgender Fehler pro Backup meistens einmal geloggt:
Protokollname: Application
Quelle: MSExchangeIS
Datum: 17.08.2015 23:54:22
Ereignis-ID: 10026
Aufgabenkategorie:Allgemein
Ebene: Fehler
Schlüsselwörter:Klassisch
Benutzer: Nicht zutreffend
Computer: FSTOPLINE.toplineag.local
Beschreibung:
Es gibt 10 RPC-Anforderungen für die Datenbank 'DATENBANK: /o=First Organization/ou=Exchange Administrative Group (XXXXXXXX)/cn=Configuration/cn=Servers/cn=SERVER/cn=Microsoft Private MDB', deren Ausführung ungewöhnlich lange gedauert hat. Dies kann ein Hinweis auf Leistungsprobleme Ihres Servers sein.
Theoretisch würde ich darauf tippen, dass mein SATA Raid 1 an die Grenze kommt und deshalb alles so träge wird. Was ich aber nicht nachvollziehen kann: Dies passiert nur während der Konsistenzprüfung. Während der täglichen Arbeit sowie dem effektiven Backup etc. läuft alles tadellos. Auch die Dauer der Prüfung (ca. 20 Minuten) ist meines erachtens im normalen Rahmen.
Der Server ist logsicherweise als DC konfiguriert. Es wird nur der Exchange aktiv eingesetzt. Daten etc. sind auf einem NAS abgelegt.
Ich weiss: SAS wäre sicher optimaler gerade in solchen Fällen. Wird auch bei Gelegenheit geprüft.
Ist dies ein Bug, dass die Prüfung soviel Daten schaufelt? Kann ich das ignorieren wenn es nur während diesem Ereignis passiert? Kann man diese Prüfung evtl. etwas "begrenzen"?
Ich habe auch andere SBS Maschinen mit SATA und Exchange im Einsatz und konnte dieses Phänomen so noch nie beobachten.
Eingebaut ist ein SAS 6/IR Controller. Hauptspeicher 32 GB.
Gruss und danke schonmal,
Christof
Please also mark the comments that contributed to the solution of the article
Content-ID: 280512
Url: https://administrator.de/forum/exchangeis-fehler-und-serverlast-waehrend-exchange-konsistenzpruefung-280512.html
Printed on: May 13, 2025 at 11:05 o'clock
18 Comments
Latest comment
Hallo,
Wie hoch laut Resourcenmonitor die Plattenauslastung lesen/schreiben? (generell und bei Konsistenzprüfung)
Esid wann ist diese Problem vorhanden?
Wie ist der Datendurchsatz des RAID?
SMART-Werte der Platten einsehbar?
Wie voll sind die Platten, ist die Datenbank?
SATA reicht auch, muss rein SAS sein, kommt drauf an wie der RAID an sich ausgelegt ist, wenn es ein RAID1 mit nur 2 Platten ist, braucht man sich nicht wundern.
Gruß
Chonta
Theoretisch würde ich darauf tippen, dass mein SATA Raid 1 an die Grenze kommt und deshalb alles so träge wird.
Wieviele Platten sind den im RAID-Verbund von deinem RAID1?Wie hoch laut Resourcenmonitor die Plattenauslastung lesen/schreiben? (generell und bei Konsistenzprüfung)
Esid wann ist diese Problem vorhanden?
Wie ist der Datendurchsatz des RAID?
SMART-Werte der Platten einsehbar?
Wie voll sind die Platten, ist die Datenbank?
SATA reicht auch, muss rein SAS sein, kommt drauf an wie der RAID an sich ausgelegt ist, wenn es ein RAID1 mit nur 2 Platten ist, braucht man sich nicht wundern.
Gruß
Chonta
Hallo,
das bedeutet egal ob Du SAS oder SATA verwendest wer einen Exchangeserver auf einer einzelnen HDD betreibt, braucht sich über Peerformanceprobleme nicht zu wundern.
Auch wenn ihr den Exchange nur mit 15 Benutzern fütter ist das ein System das darauf ausgelegt ist das 10 fache und mehr abzukönnen.
Ein Exchange ist schon immer IO Lastig gewesen bei einigen Prozessen. Ich vermute mal das der Lerlauf deiner Platten zu dem Zeitpunkt gegen 0 geht bis der Check zu ende ist.
Wohin wird denn das Backup geschrieben, evtl ist das auch ausgelastet und es kommt zum Rückstau beim SBS.
Gruß
Chonta
"SATA reicht auch, muss rein SAS sein, kommt drauf an wie der RAID an sich ausgelegt ist, wenn es ein RAID1 mit nur 2 Platten ist, braucht man sich nicht wundern."
Den Satz verstehe ich leider nicht?
Den Satz verstehe ich leider nicht?
das bedeutet egal ob Du SAS oder SATA verwendest wer einen Exchangeserver auf einer einzelnen HDD betreibt, braucht sich über Peerformanceprobleme nicht zu wundern.
Auch wenn ihr den Exchange nur mit 15 Benutzern fütter ist das ein System das darauf ausgelegt ist das 10 fache und mehr abzukönnen.
Ein Exchange ist schon immer IO Lastig gewesen bei einigen Prozessen. Ich vermute mal das der Lerlauf deiner Platten zu dem Zeitpunkt gegen 0 geht bis der Check zu ende ist.
Den Rest muss ich vor Ort anschauen da ich ja via RDP kaum was prüfen kann während der Konsistenzprüfung.
Muni z.B. oder halt ein Performanemonitoring generell.Wohin wird denn das Backup geschrieben, evtl ist das auch ausgelastet und es kommt zum Rückstau beim SBS.
Gruß
Chonta
Versuch die Jobs so zu legen, das die nicht mit der Automatischen Wartung kolledieren oder anderen Events.
Wenn Du die Meldung immer hättest auch im Normalbetrieb dann wärs problematischer.
Ich empfehle Dir aber mal dein backup in einer VM wiederherzustellen um zu sehen ob es auch alles drin hat keine nullnummer ist
Gruß
Chonta
Wenn Du die Meldung immer hättest auch im Normalbetrieb dann wärs problematischer.
Ich empfehle Dir aber mal dein backup in einer VM wiederherzustellen um zu sehen ob es auch alles drin hat keine nullnummer ist
Gruß
Chonta
Hallo,
in den Anwendungsprotokollen kannst Du normalerweise sehen wann der Exchange seine Wartungsintervalle macht. Unser alter SBS 2003 hatte z.B. von 0 Uhr bis 5 Uhr gerödelt. Und in dem Zeitfenster ein Backup zu machen war keine gute Idee.
Da ihr nicht 24/7 arbeiten werdet mach das Backup zum start des Feierabend bis fertig
Gruß
Chonta
in den Anwendungsprotokollen kannst Du normalerweise sehen wann der Exchange seine Wartungsintervalle macht. Unser alter SBS 2003 hatte z.B. von 0 Uhr bis 5 Uhr gerödelt. Und in dem Zeitfenster ein Backup zu machen war keine gute Idee.
Da ihr nicht 24/7 arbeiten werdet mach das Backup zum start des Feierabend bis fertig
Gruß
Chonta
Moin,
Wieviel RAM hat die Kiste denn überhaupt, wieviel user? Ansonsten auch mal hier gucken ... aber CAVE!, da kann man auch schnell mal eine Musikbox aus so einem lieblos behandelten SBS zaubern ...
LG, Thomas
Es gibt 10 RPC-Anforderungen für die Datenbank
Dies kann ein Hinweis auf Leistungsprobleme Ihres Servers sein.
was willst Du denn noch wissen? Im Übrigen hat der Bill doch auch einen Ressourcenmonitor in den SBS stricken lassen?Dies kann ein Hinweis auf Leistungsprobleme Ihres Servers sein.
Wieviel RAM hat die Kiste denn überhaupt, wieviel user? Ansonsten auch mal hier gucken ... aber CAVE!, da kann man auch schnell mal eine Musikbox aus so einem lieblos behandelten SBS zaubern ...
LG, Thomas
Moin nochmal,
Ich kenne solche Probleme seit MX 2010 eigentlich nicht mehr ... andere events hat es da nicht?
Aber check mal mit dem Ressourcenmanager, dann kann man weiter sehen - eventuell hat ja doch eine Platte einen Schmarrn, ich kenn nur die DELL-Controller nicht bezüglich ihrer diagnostischen Möglichkeiten.
Auf einem normal konfiguriertem SBS2011 Standard sollte so ein Verhalten nicht auftreten, es sein denn, Du hast da 5,4k-Platten drin. Beim 2003/2008 war das schon noch anders, da ist vom MX recht viel auf den Platten rumgekratzt wurden.
LG, Thomas
32 GB RAM (steht oben)
SRY - hatte ich überlesen. Was hast Du für eine CPU in der Kiste?Ich kenne solche Probleme seit MX 2010 eigentlich nicht mehr ... andere events hat es da nicht?
Aber check mal mit dem Ressourcenmanager, dann kann man weiter sehen - eventuell hat ja doch eine Platte einen Schmarrn, ich kenn nur die DELL-Controller nicht bezüglich ihrer diagnostischen Möglichkeiten.
Auf einem normal konfiguriertem SBS2011 Standard sollte so ein Verhalten nicht auftreten, es sein denn, Du hast da 5,4k-Platten drin. Beim 2003/2008 war das schon noch anders, da ist vom MX recht viel auf den Platten rumgekratzt wurden.
LG, Thomas
Moin nochmal miteinander,
! Jetzt sind zugegebener Massen die Opterons nicht gar so gewaltig, ich habe aber in meiner Büchse auch nur einen E5-2620 drin. Und meinen SBS2008 hatte ich mit 7,2K-SATA an einem HP-fake-controller mit 8GB RAM am Laufen - selbst der hat sich nicht so zickig gehabt.
Virtualisiert ist die Kiste nicht zufällig??
LG, Thomas
Der RAM mit 32GB ist schön, aber die einzelne Platte ist der Flaschenhals.
glaube ich auch nicht wirklich dran ... ich habe an meinem SBS 4 RAID 1 an einem Controller, auf einem array liegt das System. auf einem anderen die MX-DB. Läuft mit 10k-SAS extrem fluffig ... da stimmt watt nit Virtualisiert ist die Kiste nicht zufällig??
LG, Thomas