Beiträge von ElRolfo

Ich habe noch was Interessantes gefunden:

Die Maschinen produzieren (wenn richtig viel los ist) massenhaft EInträge im System Event Log "16949" / "16950" (MsLbfoSysEvtProvider).
(also Member Nic {pieeep} Disconnected. und Connected.)

Anscheinend kommen die beim Teaming/LACP durcheinander wenn viel Client Access reinkommt. Schaltet man Teaming ab, hört der Spuk sofort auf.
Wenn der Verkehr nachläßt (Mo-Do nach 16.00) hören auch diese Fehlermeldungen auch auf um pünktlich früh gegen 07.00 Uhr wenn wieder richtig Last auf die Farm kommt zu beginnen.

Ciscoseitig hinterlassen diese Aktionen auch deutliche Spuren:

2017 Dec 13 15:21:44 pieeep %LACP-FEX132-5-LACP_SUSPEND_INDIVIDUAL: LACP port Ethernet132/1/29(0x1f830700) of port-channel port-channel1153(0x16000480) not receiving any LACP BPDUs suspending (individual) port

Also, spontan wegbrechenden Netzwerkverbindungen halte ich schon für einen recht relevanten Störfaktor. Allerdings kann ich zu obigen Event ID nichts sinnvolles finden. Ist das euch schon mal untergekommen?

Hm,

das Problem haben wir aber erst nachdem die Benutzeranzahl eine bestimmte Menge überschritten hat, und wir haben es ausschließlich mit Usern die Outlook ohne Cache nutzen. Alle anderen User können zufriedenstellend arbeiten.

Ich lasse das aber mal an der F5 prüfen.

Das GC-Problem kann ich mal angehen wenn wieder richtig Dampf auf der Farm ist. Jetzt (Freitag Nachmittag) ist alles problemlos, da sich die Useranzahl fast halbierte. Vermutlich gilt das Motto "Freitag nach eins / tut jeder seins"

Mir fehlt auch die Zeit, aber ich kann sehen daß auch andere Exchange-Admins am selben Problem hängengeblieben sind und keine Zeit haben

Das mit der Authentifizierung ist auch ein ungelöstes Problem. Wenn ein sendendes System Mails mit Anmeldung versendet dann geht das nur wenn es als Absendeadresse die der Anmeldung (oder freigegebener Postfächer für diese Anmeldung) verwendet.

Ich würde das gerne so machen daß sich das sendende System zwar anmelden muß, dann aber beliebige Absendeadressen verwenden kann. Ist mir bisher nicht gelungen. Klar, SAP machen wir auch ohne Anmeldung ... aber allein aus Überlegungen zur Sicherheit wäre es auch gut wenn sogar SAP angemeldet senden könnte.

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.

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.

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.

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.

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
http://blogs.technet.com/b/exc…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: https://blogs.technet.microsof…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?

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.