Exchange 2016, MAPI/HTTP und der Performance von Outlook in "Online-mode"

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Hallo Rolf!

    Bei uns sieht es mittlerweile besser aus. Wir hatten ja das Problem mit der NUMA Einstellungen an den HP Server.

    beobachte doch mal folgende Performance counters:


    .NET LocksAndThreads\Contention Rate/Sec für den MapiMailboxAppPool : soll unter 5 bleiden
    \\MSExchange MAPIHttp Emsmdb\Dispatch task active threads : bei uns lag dieser counter ständig bei 30
    \\MSExchange MAPIHttp Emsmdb\Dispatch task queue length : soll bei 0 liegen
    \\MSExchange MAPIHttp Emsmdb\Dispatch task threads : soll unter 30 liegen

    Bis CU 6 hatten wir noch das Problem das im Laufe der Zeit die CPU Last immer weiter hochgegangen ist. Erst nach einem Reboot war es wieder "normal".
    Grund war auch hier die MapiMailboxAppPool. Das Bild im Anhang zeigt das Verhalten. CU 6 haben wir mitte November installiert.

    Gruß,
    Jack
    Bilder
    • SCOM MAPIPOOL.PNG

      100 kB, 707×286, 53 mal angesehen
  • Dankeschön!

    Bei uns sieht das recht gemischt aus:

    * Contention Rate/sec liegt so um die 10 --> mehr als 5
    * Dispatch Task Active Threads bei 0.05
    * Dispatch Task Queue Length bei 0
    * Dispatch Task Threads bei 40 --> mehr als 30

    Die Frage ist, wie diese Werte zu interpretieren sind ...

    Wir betreiben die Server ebenfalls mit CU6, die "CPU-Eskapaden" hatten sie aber vorher nicht.
    Das mit dem NUMA lasse ich noch überprüfen, das könnte ein Anhaltspunkt sein.
  • Also, bei uns lagen die Counters sehr, sehr viel höher 350-680, constant 30, >900 und constant 30 resp.

    Wenn du schon einen Call bei MS geöffnet habt, dann wirst du schon auf dem F5 die Einstellungen geprüft haben.
    Am Exchange Server selbst solltest du noch die TCPKeepAlive Parameter überprüfen.

    Von MS gibt es auch das Healthchecker.ps1 Script. Wenn du das noch nicht hast laufen lassen, solltest du das auch tun.
    (github.com/dpaulson45/HealthChecker/releases)

    Habt ihr vor der Migration den Onboarding Accelator Service von Microsoft im Anspruch genommen?

    Gruß,
    Jack
  • Ja, wir haben das Sizing im Rahmen des "Onboard Accelerator Service" mitgemacht.

    Den Healthcheck habe ich mal rennen lassen, mit einige interessanten Ergebnissen:

    More than 24 logical cores detected. Please disable Hyper-Threading. For details see
    blogs.technet.com/b/exchange/a…y-how-big-is-too-big.aspx

    The TCP KeepAliveTime value is not specified in the registry. Without this value the KeepAliveTime defaults to two hours, which can cause connectivit
    y and performance issues between network devices such as firewalls and load balancers depending on their configuration. To avoid issues, add the Keep
    AliveTime REG_DWORD entry under HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters and set it to a value between 900000 and 1800000
    decimal. You want to ensure that the TCP idle timeout value gets higher as you go out from Exchange, not lower. For example if the Exchange server
    has a value of 30 minutes, the Load Balancer could have an idle timeout of 35 minutes, and the firewall could have an idle timeout of 40 minutes. Ple
    ase note that this change will require a restart of the system. Refer to the sections "CAS Configuration" and "Load Balancer Configuration" in this b
    log post for more details: blogs.technet.microsoft.com/ex…nectivity-in-exchange-201
    3-and-2016-on-premises/

    Das mit dem Hyperthreading scheint für Exchange 2013 zu gelten; sollte das auch bei 2016 eine Rolle spielen? Die Server sind ProLiant DL360p Gen8 mit 2 Prozessoren. Ich schätze daß hier das Abschalten des Hyperthreading eher kontraproduktiv wäre (lasse mich aber gerne korrigieren).

    Inwiefern beeinträchtigt TCP KeepAliveTime die Performance?

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von ElRolfo ()

  • Wir haben Phase 1 und 2 gemacht. Das war ganz gut, dafür hat MS uns beim Critsit damals den Support recht preiswert gestaltet (schlechtes Gewissen?).

    Also, bei Exchange 2016 sind nur 24 Cores supported, und Hyperthreading schon gar nicht. Zitat MS:
    Hyperthreading causes capacity planning and monitoring challenges, and as a result, the expected gain in CPU overhead is likely not justified. Hyperthreading should be disabled by default for production Exchange servers and only
    enabled if absolutely necessary as a temporary measure to increase CPU capacity until additional hardware can be obtained.
    Auf Deutsch heißt das wohl das der Performanzgewinn gering ist...


    TCPKeepalive ist wichtig weil sonnst der Exchange Server Verbindungen aufrecht erhalt die am LB schon lange abgebaut sind. Das kann zu Performanzprobleme im Netzwerkbereich leiten. Wie viele Connections habt im am F5?
  • Naja, CPU-Probleme haben wir eigentlich meiner Meinung nach nicht. Die CPU-Last liegt im Schnitt bei ca. 20%, auch wenn die Maschine "hakelt". Ich vermute daß da irgendwelche internen Locks im Weg sind, Grenzwerte bei denen sich der Server selber im Weg steht. Ich weiß nur nicht wie ich rausfinden kann welche.

    Unsere F5 stemmt zur Zeit ca. 45.000 Connections zu den Exchange-Servern.

    "netstat -es" bringt allerdings etwas bemerkenswertes zu Tage: manche Server haben über 50.000 Connections offen. Das könnte auf ein Problem mit dem TCP Keep Alive hindeuten.
  • Ich habe 17.500 User und rund 10.000 Smartphones etc. auf der Farm. Da hat die F5 schon einiges zu kauen, aber sie macht das ganz locker.
    Im kommenden Jahr sollen noch mal ca. 2000 User drauf kommen, daher mache ich mir jetzt schon Gedanken wie ich die langsam aufkommenden
    Probleme mit der Performance evtl. ohne neue Maschinen gebacken kriege. CPU und Storage sind ja noch lange nicht am Anschlag, Netzwerk auch nicht.

    Wir kommen nur (glaube ich) auslegungsbedingt in den Bereich wo man an den Servern ein wenig schrauben muß damit es weitergeht.

    Die RegKeys ändere ich erst am Wochenende und nach Rücksprache mit Microsoft. Wir haben auf dem Ding auch ca. 3500 "linked" Mailboxen und die machen gerne mal Ärger wenn man den Server durchstartet, auch nachdem man die aktiven Kopien umgeschaltet und den Server in den Wartungsmodus versetzt hat. Das ist aber nur ein temporäres Problem, in einem halben Jahr kann ich solche Sachen wieder während der Arbeitszeit erledigen.
  • Jack, hast du eigentlich noch die vielen "Pseudo-CAS" in Nutzung, oder läuft bei Dir nun alles mit den 8 Servern zufriedenstellend?

    Edit: neue Eskalationsstufe: Heute aus heiterem Himmel auf einmal ganz viele User mit Outlook ohne Cache die massive Probleme haben. Nicht das übliche "ruckelig und langsam", sondern richtig böse.

    Ein Grund dafür ist nicht erkennbar: am System wurde nichts verändert und auch keine neuen Benutzer auf das System genommen. Ich denke ich werde den MS-Support-Call mal eskalieren.

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von ElRolfo ()

  • Microsoft bemängelt zunächst zwei Punkte:

    * Hyperthreading muss abgeschaltet werden
    * Swapfile ist anzupassen; das steht aktuell auf "Default" und soll nun auf 32GB + 10MB gesetzt werden (obwohl die Maschine 96GB RAM hat).

    Ich glaube zwar nicht daß das die Ursache sein soll, aber wenn es M$ verlangt, dann muss man das sicher tun.