10
Store.exe sinnvolle Beschränkungen?
Hallo an alle,
daher ich mich nun durch einige Foren gelesen habe, ohne wirklich eine Antwort zu bekommen, stelle ich die Frage selbst:
store.exe zieht sich gerne allen verfügbaren Arbeitsspeicher auf dem Server, das ist mir bekannt. Ebenfalls bekannt ist mir wie ich das einschränken kann, aber:
Woher weis man wieviel Arbeitsspeicher die store.exe nun wirklich benötigt?
Wie Sinnvoll ist es, diese store.exe zu beschränken? Leider ist es bei uns so, das bei einer Nutzung von 98% des RAM's die Verwaltungskonsole sehr schwerfällig zu bedienen ist.
Natürlich gibt es genügend Beitrage auf Exchange sizing, aber diese beziehen sich doch im allgemeinen auf den kompletten Server, richtig?
Ein paar Eckdaten zum Server: etwas über 1000 User, aktuell 40 GB RAM, 6 Kerne. Exchange 2010 SP1, Windows Server 2008 R2. Genutzter Arbeitsspeicher bis zu 38 GB.
daher ich mich nun durch einige Foren gelesen habe, ohne wirklich eine Antwort zu bekommen, stelle ich die Frage selbst:
store.exe zieht sich gerne allen verfügbaren Arbeitsspeicher auf dem Server, das ist mir bekannt. Ebenfalls bekannt ist mir wie ich das einschränken kann, aber:
Woher weis man wieviel Arbeitsspeicher die store.exe nun wirklich benötigt?
Wie Sinnvoll ist es, diese store.exe zu beschränken? Leider ist es bei uns so, das bei einer Nutzung von 98% des RAM's die Verwaltungskonsole sehr schwerfällig zu bedienen ist.
Natürlich gibt es genügend Beitrage auf Exchange sizing, aber diese beziehen sich doch im allgemeinen auf den kompletten Server, richtig?
Ein paar Eckdaten zum Server: etwas über 1000 User, aktuell 40 GB RAM, 6 Kerne. Exchange 2010 SP1, Windows Server 2008 R2. Genutzter Arbeitsspeicher bis zu 38 GB.
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 282195
Url: https://administrator.de/contentid/282195
Ausgedruckt am: 25.11.2024 um 13:11 Uhr
10 Kommentare
Neuester Kommentar
Moin
Schau doch mal hir nach: MSXFAQ Exchange 2010 Sizing
Sicher, dass die RAM-Auslastung der Grund für die Schwerfälligkeit ist?
Zitat von @hossmann:
Natürlich gibt es genügend Beitrage auf Exchange sizing, aber diese beziehen sich doch im allgemeinen auf den kompletten Server, richtig?
Ja, es dreht sich bei solch einem Sizing immer um den kompletten Server.Natürlich gibt es genügend Beitrage auf Exchange sizing, aber diese beziehen sich doch im allgemeinen auf den kompletten Server, richtig?
Schau doch mal hir nach: MSXFAQ Exchange 2010 Sizing
Ein paar Eckdaten zum Server: etwas über 1000 User, aktuell 40 GB RAM, 6 Kerne. Exchange 2010 SP1, Windows Server 2008 R2. Genutzter Arbeitsspeicher bis zu 38 GB.
40 GB RAM ist nun wirklich nicht mehr viel. Warum packst du nicht was dazu?Sicher, dass die RAM-Auslastung der Grund für die Schwerfälligkeit ist?
Hey,
Danke für den Link.
Ich habe erst von 32 GB auf 40 GB erhöht und sehe aktuell keine Notwendigkeit es noch höher zu treiben, denn:
Starte ich den MicrosoftExchange-Informationsspeicher neu, funktioniert alles einwandfrei, auch zu Spitzenzeiten. nur eben nach 1-2 Tagen, wenn der Speicher sich aufgeblasen hat, merkt man wieder die Schwerfälligkeit. Also kann ich gut und gerne auf 56 GB hochrüsten, dann dauert es halt 5 Tage bis sich der Dienst alles geschnappt hat.
Deswegen die Frage ob es Erfahrungen gibt, wieviel RAM der Dienst bei gewissen größen zur Verfügung haben soll.
Danke für den Link.
Ich habe erst von 32 GB auf 40 GB erhöht und sehe aktuell keine Notwendigkeit es noch höher zu treiben, denn:
Starte ich den MicrosoftExchange-Informationsspeicher neu, funktioniert alles einwandfrei, auch zu Spitzenzeiten. nur eben nach 1-2 Tagen, wenn der Speicher sich aufgeblasen hat, merkt man wieder die Schwerfälligkeit. Also kann ich gut und gerne auf 56 GB hochrüsten, dann dauert es halt 5 Tage bis sich der Dienst alles geschnappt hat.
Deswegen die Frage ob es Erfahrungen gibt, wieviel RAM der Dienst bei gewissen größen zur Verfügung haben soll.
Hallo Hossmann,
ist eben nicht so. Denn die schwerfälligkeit kommt nicht durch den aufgeblasenen Speicher, sondern vermutlich eher durch den Rückgriff auf die Festplatte, da die essenziellen Daten nicht im RAM liegen.
Wie groß sind denn die EX DBs?
VG
ist eben nicht so. Denn die schwerfälligkeit kommt nicht durch den aufgeblasenen Speicher, sondern vermutlich eher durch den Rückgriff auf die Festplatte, da die essenziellen Daten nicht im RAM liegen.
Wie groß sind denn die EX DBs?
VG
... und was für HDD's /RAID sind darunter?
Hallo,
Wir haben mehrere Datenbanken, Standort- und Größen abhängig. Die größte misst ca. 500 GB, die kleinste 40 GB.
Wir haben mehrere Datenbanken, Standort- und Größen abhängig. Die größte misst ca. 500 GB, die kleinste 40 GB.
Ja, ok. Aber die Größe der DB's sagt in diesem Kontext eigentlich gar nichts aus.
Was den Hinweis von @certifiedit.net angeht, so sind die Festplatten darunter von Relevanz. Wieviel IOpS kommen da an und was können diese überhaupt bedienen. Falls diese überlastet sind, und davon auch die System-Platte betroffen ist, dann erklärt das die Performance-Einschränkungen bei den Verwaltungsprogrammen.
Was den Speicherverbrauch der Store.exe angeht, so kommt dieser durch den Datentransfer von und zu den DB's zustande. Das meiste ist reiner Cache und dem Speicherverbrauch der sqlservr.exe des MS SQL Servers vergleichbar. Hier kann man bedingt schlussfolgern, dass eine (oder mehrer) große Datenbank auch indirekt einen größerebn Cache-Bedarf der Store.exe erfordert, weil hier einfach mehr Aktivität zu vermuten ist. Es kann aber auch sein, dass eine (zwar) 500 GB MDB mit (aber) nur 5 Postfächern fast keinen Bedarf erzeugt.
Könnte es sein, dass der Speicherverbrauch immer während oder unmittelbar nach einer Datensicherung ansteigt?
E.
Was den Hinweis von @certifiedit.net angeht, so sind die Festplatten darunter von Relevanz. Wieviel IOpS kommen da an und was können diese überhaupt bedienen. Falls diese überlastet sind, und davon auch die System-Platte betroffen ist, dann erklärt das die Performance-Einschränkungen bei den Verwaltungsprogrammen.
Was den Speicherverbrauch der Store.exe angeht, so kommt dieser durch den Datentransfer von und zu den DB's zustande. Das meiste ist reiner Cache und dem Speicherverbrauch der sqlservr.exe des MS SQL Servers vergleichbar. Hier kann man bedingt schlussfolgern, dass eine (oder mehrer) große Datenbank auch indirekt einen größerebn Cache-Bedarf der Store.exe erfordert, weil hier einfach mehr Aktivität zu vermuten ist. Es kann aber auch sein, dass eine (zwar) 500 GB MDB mit (aber) nur 5 Postfächern fast keinen Bedarf erzeugt.
Könnte es sein, dass der Speicherverbrauch immer während oder unmittelbar nach einer Datensicherung ansteigt?
E.
Hallo,
ich schreibe mal meine Sichtweise nieder, da mein Lernprozess schon ne Weile her ist (aber so gut es geht weitergeführt wird) muss es nicht zwangsläufig richtig sein
Idealerweise passt eine Datenbank in den RAM (egal ob SQL oder Flat File), da das nur selten möglich ist nimmt sich die Datenbank , intelligent, so viel wie möglich. Den Rest müssen die Platten dann machen, deshalb sollen sie schnell sein...
Bei DB mit 500-600 GB würde ich auch einen Server mit 512 bis 768 GB Ram nehmen. Das wäre ideal...
Die Frage ist doch, müssen die Exchange DB so groß sein?! Kannst Du nicht über Beschränkungen die DB "klein" halten oder/und mit Archivierungen arbeiten? Wenn Du nicht die Grenzen setzt werden die Anwender den Server in die Knie zwingen (alternativ erschlägst Du das Problem mit Geld/ neuer Server).
Regards!
ich schreibe mal meine Sichtweise nieder, da mein Lernprozess schon ne Weile her ist (aber so gut es geht weitergeführt wird) muss es nicht zwangsläufig richtig sein
Idealerweise passt eine Datenbank in den RAM (egal ob SQL oder Flat File), da das nur selten möglich ist nimmt sich die Datenbank , intelligent, so viel wie möglich. Den Rest müssen die Platten dann machen, deshalb sollen sie schnell sein...
Bei DB mit 500-600 GB würde ich auch einen Server mit 512 bis 768 GB Ram nehmen. Das wäre ideal...
Die Frage ist doch, müssen die Exchange DB so groß sein?! Kannst Du nicht über Beschränkungen die DB "klein" halten oder/und mit Archivierungen arbeiten? Wenn Du nicht die Grenzen setzt werden die Anwender den Server in die Knie zwingen (alternativ erschlägst Du das Problem mit Geld/ neuer Server).
Regards!
Hallo smeclnt.
Wir haben ein Beschränkung, in eben dieser DB sind alle "SuperUser" mit einer maximalen Postfachgröße von 16 GB, alles darüber muss archiviert werden. Leider haben wir noch keine automatische Postfacharchivierung im Einsatz um auch diese bestmöglich zu verkleinern. Aber RAM= größter DB? Wirklich?
Wir haben ein Beschränkung, in eben dieser DB sind alle "SuperUser" mit einer maximalen Postfachgröße von 16 GB, alles darüber muss archiviert werden. Leider haben wir noch keine automatische Postfacharchivierung im Einsatz um auch diese bestmöglich zu verkleinern. Aber RAM= größter DB? Wirklich?
Aber RAM= größter DB? Wirklich?
Wenn schon, dann Summe aller DB. Aber das ist Träumerei.Relevant sind nur die bewegten Daten einer DB. Hast Du mal über meine Frage nach der Datensicherung nachgedacht?
E.
Oh Entschuldigung, komplett überlesen. Nein, während der Sicherung und danach ist kein nennenswerter unterschied zu erkennen.
