AIX 4.3.3 Benchmark-Einstellungen für Oracle 8.1 Siebel Server

AIX 4.3.3 Benchmark-Einstellungen für Oracle 8.1 Siebel Server

Zielgruppe: AIX-Systemadministratoren

Obwohl AIX eine relativ minimale Abstimmung erfordert, gibt es mehrere Einstellungen, die geändert werden können, um die Leistung zu verbessern. Hier ist eine Liste der AIX 4.3.3 Einstellungen, die ich für einen aktuellen "I/O-intensiven" Datenbank-Benchmark verwendet habe. Der Benchmark hat den Durchsatz und die Reaktionszeit eines Oracle 8.1(64 Bit)-Datenbankservers mit über 20.000 simulierten Siebel 6-Benutzern auf einem p680-Server  mit 24 CPUs, 64 GB Speicher, 4 Fibre Adaptern und Shark Raid 5-Festplatten gemessen.

Standard-Haftungsausschluss: Diese Einstellungen werden nur als Tuning-Richtlinie bereitgestellt. Jedes System ist anders, so dass "Ihre Tuningleistung variieren kann."

Abgesehen von Haftungsausschlüssen führten diese Einstellungen zu einer hervorragenden Benchmark-Performance. Der p680-Server lieferte den 2- bis 5-fachen Durchsatz bei weniger als der Hälfte der Antwortzeit des Top-End-Servers des Mitbewerbers mit 54 CPUs und 56 GB Arbeitsspeicher.

Benchmark Übersicht

Siebel 6 ist eine Customer Relationship Management-Anwendung. Es verwendet eine zweistufige Architektur, die "fette" PC-Clients, die die Anwendung ausführen, und einen Back-End-Datenbankserver enthält. Bei der Datenbankserver-Workload handelt es sich meist um "Leseabfragen".

Der Benchmark hat die Datenbankleistung in Bezug auf Durchsatz und Abfrageantwortzeit gemessen. Die Auslastung wurde von bis zu 800 simulierten Benutzern generiert, die Abfragen ausführen. Die Abfragen reichten von einfachen Suchanfragen bis hin zu lang andauernden Berichten, die nicht indizierte Tabellenscans und bis zu 16-Wege-Tabellenverknüpfungen erfordern.

Der Server lief AIX 4.3.3 ML7 und Oracle 8.1 (64 Bit). Die Oracle-Tabellen befanden sich auf einem JFS-Dateisystem. Die Clientverbindungen waren JDBC (Java 1.1.8). Der Server war ein p680 mit 24 CPUs, 64 GB Speicher, 100 Mbit Ethernet, 4 Fibre Adapter n. Chr. Der Shark wurde als 8 "6+P" Raid 5 LUN es mit 32 GB Cache konfiguriert.

AIX-Einstellungen

Die AIX-Optimierung für diesen Benchmark konzentrierte sich auf E/A-Einstellungen für den Zugriff auf Mehrbenutzerdatenbanken. Wir befassten uns mit zwei Arten von Datenbank-Workloads: einfache Suchabfragen und lang andauernde Berichtsabfragen.

In den folgenden Tabellen sind die im Benchmark verwendeten AIX-Einstellungen aufgeführt. Die Tabellen sind nach CPU-, Arbeitsspeicher-, E/A- und Netzwerkeinstellungen organisiert. In einigen Fällen betrifft die Einstellung zwei Kategorien (d. h. Speicher und E/A), in diesen Fällen war meine Zuordnung zu einer Kategorie willkürlich.

CPU-Einstellungen

Speichereinstellungen

Kommentar Zum Speicher

Das Benchmark-System verfügte über genügend Speicher, um Paging zu vermeiden. Wenn Paging stattgefunden hätte, hätten wir den Speicher so abgestimmt, dass permanenter Speicher (ausführbare Dateien, Dateisystemmetadaten) über ausgeponenes Arbeitsspeicher (Oracles SGA) verteilt wurde. Sehen Sie dazu den Befehl "vmtune" und die Einstellungen "minperm" und "maxperm".

I/O-Einstellungen

I/O Kommentare

Randomize-Datenlayout: Reduzieren Sie mögliche E/A-Konflikte, indem Sie die Datenverteilung auf Festplatten maximieren (mklv -e x). Darüber hinaus sollte jedes LV in einer eindeutigen Reihenfolge über die Festplatten verteilt werden. Dadurch werden E/A-Engpässe minimiert, die auftreten können, wenn sich mehrere serielle Lesevorgänge (Tabellenscans, Datenladungen) gegenseitig "tailgate" "tailgate" durchführen.

Um eine Layoutsequenz anzugeben, erstellen Sie zuerst die LV, die die Layoutsequenz angibt. Erstellen Sie als Zweiter ein Dateisystem auf dem "zuvor definierten" LV. Hier ist ein Beispiel für das Erstellen von 2 LV es auf denselben Datenträgern, jedoch mit unterschiedlicher Sequenzierung.

mkly -y lv01 -e x datavg hdisk1 hdisk2 hdisk3

mklv -y lv02 -e x datavg hdisk3 hdisk2 hdisk1

Verbessern Sie die sequenzielle Read, indem Sie "read ahead" erhöhen: Wenn AIX eine sequenzielle Read wahrnimmt, versucht es, die E/A-Leistung zu verbessern, indem die Anzahl der Blöcke erhöht wird, die es auf der nächsten E/A liest. Das vmtune -Flag "maxpgahead" bestimmt die Anzahl der Blöcke, die AIX vorher lesen kann. Der parameter maxpgahead muss eine Leistung von 2 (2, 4, 8, 16, …) haben.

In unserem Benchmark haben wir "maxpgahead" so dimensioniert, dass die maximale Lesegeschwindigkeit in etwa der Größe des RAID 5-Streifens über die Festplatten (6+P) entspricht. Wir haben die folgende Formel verwendet, um "maxpgahead" zu berechnen, dann auf das nächste Vielfache von 2 aufgerundet:

maxpgahead (Raid  5 Streifengröße)* (#Raid-5 Anzahl der Festplatten) / (4k/Blöcke )

128k ( * 6 Scheiben / (4k) = 192 Blöcke =  256  (Aufrundung auf die nächste Leistung von 2)

JFSLOG ist ein logisches Volume, das von AIX verwendet wird, um Dateiänderungen zu erfliegt. In jeder Volume-Gruppe gibt es mindestens ein JFSLOG, das ein Dateisystem enthält. Das JFSLOG trägt zur Aufrechterhaltung der Datenintegrität bei, kann aber bei starkem Schreibverkehr zu einem Engpass werden.

Das JFSLOG sollte auf Dateisystemgröße und E/A-Rate abgestimmt werden. Der Standard-JFSLOG ist für große Dateisysteme unterdimensioniert. Die Größenregel des Daumens  ist 2 MB JFSLOG pro GB Dateisystem. Um 150 GB Dateisysteme zu unterstützen, benötigten wir ein 300 MB JFSLOG. Um zu verhindern, dass das JFSLOG zu einem E/A-Engpass wird, haben wir es "Raid 0" auf mehrere Festplatten gestreift.

Das Verfahren zum Nachbilden eines gestreiften JFSLOG ist unten aufgeführt. In diesem Beispiel ist der Volume-Gruppenname "datavg", das JFSLOG heißt jfslog00, und wir möchten es mit 128k-Blöcken über den hdisks 6, 7, 8 und 9 stripen.

1. 1. Aufheben der Bereitstellung aller Dateisysteme in datavg
   2. Entfernen Sie jfSLOG: rmlv jfslog00
   3. JFSLOG neu erstellen: mklv -y jfslog00 datavg -S128k hdisk6 hdisk7 hdisk8 hdisk9
   4. Formatieren sie JFSLOG: logform /dev/jfslog00
   5. Remount-Dateisysteme in datavg

Asynchrone E/A-Informationen verbessern die Schreibleistung, indem Bestätigungen gruppiert werden. Anwendungen müssen geschrieben werden, um aIO nutzen zu können, wie dies bei Oracle der Fall ist. Die AIO-Optimierung umfasst die Angabe der Anzahl der AIO-Server und deren Aktivierung (smit aio). Wir legen den AIX-Mindestbetrag auf 150 fest, basierend auf der Empfehlung einer SupportLine. Die maximale Einstellung von 300 ist doppelt so hoch wie die Mindesteinstellung.

Während des Benchmarks stellten wir fest, dass die Mindesteinstellung von 150 wahrscheinlich zu hoch war. Die Anzahl der aktiven AIO-Server sollte zwischen der min/max-Einstellung liegen (pstat -a | grep -c aios). Überkonfiguriert zu sein, schadet nicht, daher haben wir die Einstellung nicht geändert.

Netzwerk

Alle Netzwerkeinstellungen wurden vor Beginn des Benchmarks geändert. Die Änderungen basierten auf früheren Erfahrungen und nicht auf Engpässen.

Kommentare/Beobachtungen

Systemleistung: Die CPU lag im Durchschnitt unter 30 % Auslastung. Warte-E/A lag im Durchschnitt unter 15 %. Die Datenträgeraktivität wurde gleichmäßig auf alle Datenträger verteilt. Während der Benchmark wurden keine Systemengpässe festgestellt.

Schreibgeschützte Datenbanken können über erheblichen Schreibinhalt verfügen.  Dieser Benchmark zeigte Perioden hoher Schreibaktivität, obwohl die Abfragen schreibgeschützt waren. In der Reihenfolge der Tätigkeit, die Quellen der Schreib-E/A enthalten:

1. 1. Das JFSLOG hatte die höchste Schreibaktivität. Das JFSLOG wurde am Ende des Benchmarks zu 100 % genutzt, als Oracle inaktive Verbindungen schloss. (Wir vermuten, dass es sich um einen "bekannten" Oracle-Fehler handelt, der mit übermäßigen fsync()-Aufrufen verbunden ist. Ich verstehe, dass ein Patch verfügbar ist.) Da es nach dem Benchmark aufgetreten ist, hat es die Ergebnisse nicht beeinflusst.
   2. Tabellenverknüpfungen waren die zweithöchste Quelle für Schreibaktivität. Schreib-E/A auf Oracles temporäre Festplatte erreichte einen Spitzenwert von über 40 MB/sek. Diese I/O es neigten jedoch zu kurzen Bursts, die 10-20 Sekunden dauerten.
   3. Oracle-Protokolldateien machten bis zu 5 % der Warte-E/A aus. Diese Aktivitätsstufe würde nicht als Systemengpass betrachtet, könnte sich jedoch auf die Oracle-Leistung auswirken.

Speicheranforderungen: Die hauptbenutzer des Speichers waren Oracles SGA- und JDBC-Verbindungen. Die Oracle SGA verwendete 4-5 GB. (Es hätte größer sein können, war aber darauf beschränkt, der Größe des Wettbewerbsservers zu entsprechen.) Jede JDBC-Verbindung zwischen dem Client und der Datenbank benötigte etwa 3 MB Arbeitsspeicher auf dem p680. Der p680 war bei etwa 20.000 Verbindungen nicht mehr genügend Arbeitsspeicher, wobei die überschüssigen Verbindungen auf den Datenträger ausgelagert wurden. Die große Anzahl von Verbindungen hat die Datenbankleistung nicht wesentlich beeinträchtigt (nachdem die überschüssigen Verbindungen auf den Datenträger ausgelagert wurden).

Datenzwischenspeicherung: AIX und Oracle haben gute Arbeit beim Zwischenspeichern von Daten im Speicher geleistet. Es gab fast keine Datenträger-E/A mit 400 aktiven Benutzern, die einfache Abfragen ausführen. Die meisten E/A-Dateien waren hauptsächlich mit dem Schreiben von temporären Dateien verbunden.

Aufgrund der Low-Disk-Aktivität würde ich den standardmäßigen 8-GB-Shark-Cache über den im Benchmark verwendeten 32-GB-Cache empfehlen.

Das Mischen einfacher und komplexer Abfragen erforderte mehr Ressourcen als wenn sie separat ausgeführt wurden. Es schien eine Interaktion zwischen einfacher Suche und lang andauernden Abfragen zu geben, die den Durchsatz reduzierten. Der Effekt ist schwer zu quantifizieren, aber ich würde es auf die Größenordnung von 10-15% zusätzlichen Overhead schätzen.