Wie schätzen Sie ein, wie viel Speicher Sie kaufen müssen?

Ich habe eine benutzerdefinierte Serveranwendung, die unter Windows 2008 R2 ausgeführt wird. Es handelt sich um einen in .Net geschriebenen Windows-Dienst, der eine Reihe von benutzerdefinierten Terminals unterstützt. Ich habe eine Testmaschine, die eine ähnliche Spezifikation wie der Live-Server hat, und ich habe eine Reihe von Client-Simulatoren, mit denen ich eine Last erzeugen kann, die eine vernünftige Annäherung an das reale System darstellt. Ich muss in der Lage sein, 12.000 davon zu unterstützen, und derzeit geht dem Server der Speicher aus (Paging geht durch das Dach).

Mein Plan war es, nur 100 der Simulatoren zu starten, die Speichernutzung zu messen, dann 100 weitere Speicher zu messen und zu wiederholen, bis das Paging beginnt (in Wirklichkeit werde ich mehr als drei Datenpunkte nehmen.) Dies sollte mir eine Zahl für geben Die Menge an zusätzlichem Speicher, die für 100 Simulatoren benötigt wird, und die es mir ermöglichen, zu projizieren, wie viel Speicher benötigt wird. Ich brauche nur eine grobe Idee von +/- 30 GB, um nicht die vollen 2 TB (im Wert von 150.000 USD) zu kaufen, die der Server benötigt. Meine Frage ist, ob dies eine vernünftige Methode ist und wenn ja, welche Leistungsindikatoren würden Sie überwachen, um die tatsächlich verwendete Speichermenge anzugeben?

Ich spreche hier speziell vom Speicher, da mich der Unterschied zwischen Working Set, Private Bytes, Committed, Shared, Virtual und allen anderen Speicherbegriffen verwirrt. Ich denke, ich kann es schaffen, CPU, E / A und Netzwerk selbst zu überwachen. Die andere Sache, die mir aufgefallen ist, ist, dass der .Net-Cache seine Speichernutzung abhängig von der Verfügbarkeit anpasst, wodurch das Erkennen eines Trends schwer zu erkennen ist.

Ehrlich? Ich nicht .
Wenn ich einen Server spezifiziere, auf dem jede Art von realer Arbeitslast auftritt, stelle ich so viel RAM ein, wie ich mir zumutbar leisten kann (Systeme werden mit größerer Wahrscheinlichkeit RAM-eingeschränkt als CPU- oder Festplattenbeschränkungen - der einzige andere garantierte Engpass ist die Vorderseite Bus).

Wenn Sie herausfinden wollen , wie viel RAM Ihre Anwendung eine Grundlast - Test verwenden können , wie Sie vorgeschlagen haben , ist ein guter Anfang, aber wenn Sie bereits haben dieses System in der Produktion (es klingt wie Sie tun) und Ihr Produktionssystem tauschen Ihre Die Aufgabe ist einfacher: Finden Sie heraus, wie viel Swap-Speicherplatz Sie verwenden -> Fügen Sie mindestens 2x so viel RAM hinzu (aufrunden, um die DIMM-Größenbeschränkungen Ihres Systems zu erfüllen).

Wenn Sie einen Belastungstest durchführen, um grobe Zahlen zu erhalten und von dort zu extrapolieren, denken Sie daran, einige Dinge zu berücksichtigen:

1. Die Speicherkurve besteht wahrscheinlich aus zwei unterschiedlichen Segmenten
   (anfänglicher starker Anstieg beim Zwischenspeichern von Frameworks / gemeinsam genutzten Bibliotheken, dann eine etwas weniger steile Kurve, wenn der nicht gemeinsam nutzbare Code jeder neuen App in den Speicher gestellt wird).

2. Sie benötigen weiterhin freien Arbeitsspeicher für das Zwischenspeichern von Festplatten und gemeinsam genutzten Bibliotheken sowie für das Betriebssystem.
   (Dies sollten mindestens ein paar Auftritte über die Anforderungen Ihrer App sein.)

3. ALLE Software verliert Speicher (zumindest jede praktische Software). Achten Sie daher bei Ihren Tests darauf und stellen Sie sicher, dass Sie genügend Platz haben, um mit einem Leck umzugehen.

4. Ihre Last wird wahrscheinlich über die Lebensdauer des Servers zunehmen. Planen Sie entsprechend.
   (Wenn Sie keine guten Kapazitätsplanungszahlen haben, verdoppeln Sie die heutige Arbeitslast und planen Sie, damit umzugehen).

5. Wenn Sie heute zu viel RAM kaufen, ist dies billiger, als wenn Ihre Umgebung morgen ausfällt.

   • Erste Folgerung: Wenn Sie einen etwas größeren Server kaufen, als Sie benötigen, sind Sie der vorausschauende Administrator, der das Unternehmen am Laufen gehalten hat. Sie werden weitgehend ignoriert und nicht geschätzt.
   • Zweite Folgerung: Wenn Sie die Maschine zu klein dimensionieren und Probleme auftreten, sind Sie der inkompetente Trottel, der kein Wachstum von 500% erwarten konnte, und jeder hasst Sie.

Danke, das Update gibt zumindest allen einen Hinweis. Wenn Sie über 2 TB Speicher nachdenken, bedeutet dies, dass Sie in einem anderen Stadion als den üblichen Setups spielen. Großes System. Ich hasse es, daran zu denken, wie viel Hitze das abgeben wird.

Angesichts der Tatsache, dass es sich um einen internen Serverprozess handelt und Ihnen der Arbeitsspeicher ausgeht (Sie sagen nicht, auf welcher Ebene Sie mit dem Paging beginnen), möchte ich die Möglichkeit ausschließen, dass der Serverprozess immer mehr Speicherplatz beansprucht, bevor er ausgeführt wird des Weiteren. Wenn dies auftritt, spielt es keine Rolle, was Sie tun, das System stoppt irgendwann.

Ich kenne keine generischen Tools, mit denen Sie viel mehr als nur einen grundlegenden Überblick darüber erhalten können, was los ist ... was mit Windows geliefert wird. Der Serviceprozess selbst ist eine Black Box und Ihr Entwicklerteam muss Überwachungstools bereitstellen.

Schneller Rückblick auf die Umschlagberechnung:

2Tb of memory = 1024Gb = 1024*1024Mb = 1048576Mb
1048576Mb / 13000 connections = around 80mb per session

Dies würde nicht außerhalb des Bereichs des Arbeitssatzes eines normalen .net-Exe liegen.

Hat der Dienst mehrere Threads? Wenn sie für jede Verbindung einen Thread starten, lohnt es sich zu prüfen, wie sie dies tun. Mit ProcExp.exe von Microsoft können Sie auf einfache Weise feststellen, ob Sie mehrere Threads haben und was diese Threads verbrauchen. Es weiß nichts über .net, gibt Ihnen aber Win32-Zähler.

Können Sie angeben, wie viel Speicher und wie viele Verbindungen Sie beim Testen hatten, bevor das Paging begann?

Wie kann man also feststellen, ob der Serverprozess Probleme mit dem Speicherverlust hat? Es könnte sein, dass sich mit jeder verbundenen Sitzung mehr Speicher ansammelt, oder dass sich Speicher ansammelt und diese niemals freigibt.

Was Sie tun können, ist - wählen Sie eine Anzahl von Sitzungen aus, die kein Paging provozieren, und simulieren Sie diese Anzahl von Verbindungen. - Führen Sie die Simulation über einige Stunden aus und verwenden Sie perfmon, um die grundlegenden Speicherzähler zu überwachen. - Wiederholen Sie diese Tests mit Sitzungen, die kurz eine Verbindung herstellen und die Verbindung trennen.

Die Idee ist zu sehen, ob der Dienst mit jeder Sitzung mehr und mehr Speicher verbraucht oder ob offene Sitzungen eine ständig zunehmende Speichernutzung hervorrufen.