... hatte gehofft, ich könnte ... eine grobe Schätzung dessen bekommen, was wir laufen sollten.
Ohne weitere Informationen zu Ihren Abfragen und Datengrößen ist es wirklich schwierig, Ihnen eine Schätzung zu geben, geschweige denn eine genaue Schätzung.
Datenbank: SQL Server 2008 R2 Unternehmensdatenbank
Windows: Windows 2008 r2 Enterprise 64-Bit, ziemlich sicher unter VMware.
Prozessor: Intel (R) Xeon (R) CPU E7-4860 bei 2,27 GHz 2,26 GHz (2 Prozessoren)
Installierter Speicher: 4 GB
Zwei Prozessoren (ich gehe davon aus, dass dies in der VM als 2 Kerne verfügbar ist) sind möglicherweise nicht ausreichend bereitgestellt. Die einer VM zugewiesenen Kerne sind nicht unbedingt direkt physischen Kernen zugeordnet (oder dürfen bei Bedarf sogar 100% eines einzelnen Kerns verwenden!). Daher ist dies möglicherweise eine flexiblere Ressource als Speicher. Ohne weitere Informationen zu Ihrer Workload oder Hardware- / Virtualisierungskonfiguration würde ich sagen, dass es schön wäre, diese auf 4 zu erhöhen.
Speicherzuweisung. Oh Junge. Dies ist grob für die Arbeitsbelastung unter bereitgestellt. Windows selbst benötigt mindestens 2-3 GB, um zufrieden zu sein, und jeder der beiden Benutzer, die BIDS auf der Box ausführen, benötigt jeweils mindestens 500 MB. Damit ist die Box bereits voll und ich habe noch nicht einmal herausgefunden, wie viel die Datenbank benötigen wird.
Die Mehrheit der Benutzer interagiert mit der Datenbank über die asp.net-Website und die Berichtsserver-Website.
Sie haben es nicht gesagt, aber wenn diese auf derselben Box ausgeführt werden, müssen auch die Speicheranforderungen für sie berücksichtigt werden.
Schließlich haben wir einen ziemlich komplizierten Data Warehousing-Vorgang, der wahrscheinlich 3 Millionen Datensätze pro Tag über SSIS-Pakete einbringt, die auch auf dem Server ausgeführt werden.
Angenommen, dies wird nachts ausgeführt, wenn sich keine Live-Benutzer auf dem System befinden, sehe ich dies nicht als Problem an, es sei denn, die Ausführung dauert zu lange. Dieser Teil der Dinge ist die geringste Ihrer Sorgen; Live-Benutzer sind wichtiger.
Unsere früheren Anforderungen an zusätzlichen Speicher wurden mit der allgemeinen Antwort abgelehnt, dass wir mehr Abfrageoptimierungen durchführen müssen.
Wie ich oben gezeigt habe, ist die derzeit bereitgestellte Speichermenge völlig unzureichend. Gleichzeitig ist es jedoch äußerst unwahrscheinlich, dass Sie am anderen Ende des Spektrums genügend Speicher bereitstellen können, um den Speicher zu behalten gesamte Datenbank auf einmal im Speicher .
Auch wenn Sie eine pauschale Antwort wie diese erhalten haben (was übrigens wahrscheinlich mehr damit zu tun hat, wie überzeugend Ihre Rechtfertigung für zusätzliche Ressourcen war, und nicht mit der tatsächlichen Ressourcennutzung selbst), ist es sehr wahrscheinlich, dass die Effizienz der Datenbank sein könnte verbessert. Es gibt jedoch keine Optimierung allein, mit der die Probleme behoben werden können, die derzeit auftreten. Der Vorschlag dafür ist für mich ein völliger Nichtstarter.
Ich würde den Gesamtansatz verfolgen, dass die derzeit bereitgestellte Speichermenge unter dem erforderlichen Mindestwert liegt (der so schnell wie möglich korrigiert werden sollte), und dass möglicherweise zusätzliche Ressourcen erforderlich sind, um die Benutzererfahrung auf ein nutzbares Niveau zu verbessern, während Verbesserungen vorgenommen werden, um die Effizienz von zu steigern die Systeme.
Hier sind einige Gedanken (in der Reihenfolge des Angriffs):
Sie werden gewinnen, wenn Sie nachweisen können, wie viel Leistung sich jedes Mal verbessert, wenn Sie mehr Ressourcen bereitstellen. Verfolgen Sie die Leistungsmetriken mithilfe der Protokollierung des Leistungsmonitors (Hinweis: Der Protokollierungsteil ist sehr wichtig), einschließlich der Antwortzeiten der Website, wenn Sie können. Beginnen Sie jetzt damit , bevor Sie etwas anderes tun. Wenn Sie endlich die minimale Speichermenge erreicht haben (Sie werden nicht sofort 32 GB erhalten), haben Sie plötzlich Beweise dafür, dass der hinzugefügte Speicher die Dinge verbessert hat ... was bedeutet, dass das Hinzufügen von noch mehr wahrscheinlich auch helfen würde! Wenn Sie keine Basislinie für die aktuelle Konfiguration erfassen, werden Sie das Boot verpassen, wenn die Dinge auf das empfohlene Mindestniveau gebracht werden.
Analysieren Sie Ihre Server - Warte Statistiken . Hier erfahren Sie, was der größte Engpass im System ist. Sie haben wahrscheinlich PAGEIOLATCH_XXdie häufigste / höchste Wartezeit, was darauf hinweist, dass zu viel E / A ausgeführt wird, um Seiten von der Festplatte abzurufen. Dies kann durch Hinzufügen von Speicher verringert werden, sodass die physischen E / A weniger häufig werden, da sich die benötigten Daten bereits im Speicher befinden. Während diese Analyse so ziemlich eine Selbstverständlichkeit ist, gibt Ihnen die Tatsache, dass Sie diese Statistiken überhaupt gesammelt haben, mehr Munition, wenn Sie den Bedarf an Ressourcen rechtfertigen.
Wie oben erwähnt, wird die Mindestanforderung an den Speicher nicht erfüllt. Sammeln Sie die empfohlenen Hardwareanforderungen für die gesamte Software, die Sie ausführen, und erstellen Sie möglicherweise auch Screenshots des Task-Managers. Dies allein sollte ausreichen, um vor Ort mindestens 4-8 GB mehr zu rechtfertigen. Wenn sie sich immer noch weigern, versuchen Sie, sie davon zu überzeugen, dass Sie es eine Woche lang ausprobieren können, und geben Sie es danach zurück (Sie sammeln Leistungsstatistiken, sodass Sie es nicht zurückgeben müssen, weil Sie es Mitte der Woche sind. ' Ich werde beweisen können, um wie viel sich die Situation verbessert hat. Wenn sie sich immer noch weigern, werden Sie zum Scheitern verurteilt. URLT .
Wenn Sie einen Teil der Arbeitslast auslagern können (insbesondere ein Remoting nach Möglichkeit vermeiden), erhöht dies den für die Datenbank verfügbaren Speicher, was kritischer ist.
Sie können nicht die gesamte Datenbank auf einmal in den Speicher einpassen. Dies bedeutet, dass Sie die maximale Speichereinstellung von SQL Server sehr sorgfältig festlegen müssen, um ein Überschreiben des Speichers zu vermeiden , wodurch die Leistung wie nichts anderes beeinträchtigt wird . Over-Commit ist sogar noch schlimmer, als einfach nicht alle Daten im Speicher unterzubringen. Es ist sehr wahrscheinlich, dass Sie sich gerade in diesem Szenario befinden, nur weil überhaupt kein Speicher verfügbar ist und es wahrscheinlich ist, dass die maximale Speichereinstellung auf den Standardwert (unbegrenzt) eingestellt ist.
Da Sie SQL Server Enterprise Edition ausführen und der Arbeitsspeicher knapp ist, würde ich die Implementierung der Datenkomprimierung dringend in Betracht ziehen . Dies führt zu einer Erhöhung der CPU-Auslastung, um Speicherplatz zu sparen (und damit die Festplattenzugriffe zu verringern, die vergleichsweise sehr langsam sind).
Optimieren Sie die Datenbank. Es ist wahrscheinlich, dass die Strukturen und Abfragen Verbesserungen in Bezug auf Indizierungs- und Zugriffsmuster gebrauchen könnten. Wenn viele Daten häufig gescannt und aggregiert werden, kann das Erstellen indizierter Ansichten, Übersichtstabellen oder vorberechneter Berichte sehr hilfreich sein.
Dies kann ein Longshot sein, da es wahrscheinlich mehr Hardware-Bereitstellung bedeutet, aber eine Caching-Lösung implementiert. Die schnellste Abfrage ist die, die Sie nie stellen .
Das sind nur ein paar Ideen. Das Fazit ist, dass das Tuning allein weder die Probleme hier noch die Hardware allein lösen wird, obwohl letztere wahrscheinlich die Mehrheit der unmittelbaren Probleme lindern wird. So geht das wirklich: Werfen Sie kurzfristig Hardware auf das Problem, um das Feuer zu löschen, und werfen Sie langfristig eine Optimierung auf das Problem, um die Grundursache so gut wie möglich zu beheben.