Liebe Kollegen,
ich versuche unsere produktive oracle-db (10g, linux) auf einer VM unter ESX 3.5 zu betreiben. Die Datenbank hat nun doch einige Performanceprobleme. Die VM ist mit zwei CPUs und 4GB Ram versehen und via "shares" entsprechend privilegiert. Der Speicherbereich (Daten und vmdk)befindet sich an einer HP EVA und ist/sind als raw-device ausgelegt (vRaid1) Die ESX-Pfade zu den Luns für tablestore und logs sind getrennt und laufen über verschiedene ESX-HBAs.....(4GBit san)
Wie auch immer, das Teil ist langsam.
Sobald der User ernsthaft mit der Applikation arbeitet sind auf der VM "iowaits" auszumachen. Auch die Oracle-DB meint, das ihr Problem "user-IO" ist.
Zum Test habe ich die DB auf 64 Bit migriert (BS und Datenbank) und den Speicherbereich der SGA auf 8GB gesetzt. Das bring zwar etwas, der große Wurf ist es nicht. Die ESX-Hosts sind mit AMD Dualcore-CPU ausgestattet, je Server 2 CPUs mit 2Kernen und 32GB Ram.
Weder ESX-Server noch CPU der VM sind ausgelastet. Trotzdem ist das IO-Verhalten offenbar schlecht. Hatte jemand ähnliche Nöte und wie kann man da vorgehen (außer die Datenbank auf echter Hardware...)
Danke
Die Foren-SW läuft ohne erkennbare Probleme. Sollte doch etwas nicht funktionieren, bitte gerne hier jederzeit melden und wir kümmern uns zeitnah darum. Danke!
oracle db auf esx 3.5
-
daniel1010
- Member
- Beiträge: 10
- Registriert: 07.09.2008, 20:23
Moin,
so schauts aus
auf dem tablespace-volume:
Timing cached reads: 4516 MB in 2.00 seconds = 2261.32 MB/sec
Timing buffered disk reads: 560 MB in 3.00 seconds = 186.41 MB/sec
log-volume:
Timing cached reads: 3808 MB in 2.00 seconds = 1907.61 MB/sec
Timing buffered disk reads: 498 MB in 3.01 seconds = 165.49 MB/sec
Die Werte brechen auch mal ein auf:
Timing buffered disk reads: 116 MB in 3.02 seconds = 38.46 MB/sec.
2.6.18-53.1.13.el5 #1 SMP Mon Feb 11 13:27:52 EST 2008 i686 athlon i386 GNU/Linux
Gruß
so schauts aus
auf dem tablespace-volume:
Timing cached reads: 4516 MB in 2.00 seconds = 2261.32 MB/sec
Timing buffered disk reads: 560 MB in 3.00 seconds = 186.41 MB/sec
log-volume:
Timing cached reads: 3808 MB in 2.00 seconds = 1907.61 MB/sec
Timing buffered disk reads: 498 MB in 3.01 seconds = 165.49 MB/sec
Die Werte brechen auch mal ein auf:
Timing buffered disk reads: 116 MB in 3.02 seconds = 38.46 MB/sec.
2.6.18-53.1.13.el5 #1 SMP Mon Feb 11 13:27:52 EST 2008 i686 athlon i386 GNU/Linux
Gruß
Die Werte von esxtop fand ich jetzt nicht aufregend, im Vergleich zu anderen VMs
LOAD CMDS/s READS/s WRITES/s MBREAD/s MBWRTN/s
0.00 774.15 761.51 12.64 16.07 0.12
Die Werte verteilen sich dann noch auf die hba's
Da zeigen Windows-Fileserver gelegentlich deutlich höhere Werte wenn auch nur für kurze Zeit, die Last der oracle-vm ist da eher Konstant.
Bei den "Scsi Queue Tiefen" muss ich passen, die HP EVA ist für ESX-Server konfiguriert(also die hosts). In das SAN-Tuning bin nicht wirklich eingestiegen. Will sagen, da wird wohl weiter nichts abgestimmt sein.
esxtop zeigt bei Aqlen 4096 ;
Der Blick auf die einzelnen LUNs:
Manchmal taucht bei "ACTV" eine "1" auf, sonst ist dort eher Ruhe.
vmhba0:0:60 - 4 5 2 32 0 0 0 0 0.00 0.95 0.16 0.79 0.00 0.00
vmhba0:0:61 - 4 5 2 32 0 0 0 0 0.00 280.22 279.27 0.95 2.57 0.01
vmhba0:0:62 - 4 5 2 32 0 0 0 0 0.00 0.64 0.00 0.64 0.00 0.01
vmhba0:0:63 - 4 5 2 32 0 0 0 0 0.00 0.00 0.00 0.00 0.00 0.00
Dann sind da noch diese Latenzzeiten z.B. GAVG/cmd, aber auch hier Werte zwischen 1 - 15 ms bei Nutzeraktivität, sieht auch nicht bedrohlich aus.
Gruß
LOAD CMDS/s READS/s WRITES/s MBREAD/s MBWRTN/s
0.00 774.15 761.51 12.64 16.07 0.12
Die Werte verteilen sich dann noch auf die hba's
Da zeigen Windows-Fileserver gelegentlich deutlich höhere Werte wenn auch nur für kurze Zeit, die Last der oracle-vm ist da eher Konstant.
Bei den "Scsi Queue Tiefen" muss ich passen, die HP EVA ist für ESX-Server konfiguriert(also die hosts). In das SAN-Tuning bin nicht wirklich eingestiegen. Will sagen, da wird wohl weiter nichts abgestimmt sein.
esxtop zeigt bei Aqlen 4096 ;
Der Blick auf die einzelnen LUNs:
Manchmal taucht bei "ACTV" eine "1" auf, sonst ist dort eher Ruhe.
vmhba0:0:60 - 4 5 2 32 0 0 0 0 0.00 0.95 0.16 0.79 0.00 0.00
vmhba0:0:61 - 4 5 2 32 0 0 0 0 0.00 280.22 279.27 0.95 2.57 0.01
vmhba0:0:62 - 4 5 2 32 0 0 0 0 0.00 0.64 0.00 0.64 0.00 0.01
vmhba0:0:63 - 4 5 2 32 0 0 0 0 0.00 0.00 0.00 0.00 0.00 0.00
Dann sind da noch diese Latenzzeiten z.B. GAVG/cmd, aber auch hier Werte zwischen 1 - 15 ms bei Nutzeraktivität, sieht auch nicht bedrohlich aus.
Gruß
-
kastlr
- Profi
- Beiträge: 993
- Registriert: 31.03.2008, 17:26
- Wohnort: Einzugsbereich des FC Schalke 04
- Kontaktdaten:
Hallo,
es gibt eine Präsentation von der VMWorld Europe 2008, da solltest du eigentlich ne Menge nützlicher Infos finden.
http://www.vmworld.com/docs/DOC-2474
Leider ist der Zugriff (noch) ausschließlich für Teilnehmer freigeschaltet, aber vielleicht hast du ja diesen Zugriff.
Zum Thema FC LUN queue depth: http://kb.vmware.com/kb/1267
Sorry, das ist inzwischen in die folgende Doku gewandert http://www.vmware.com/pdf/vi3_esx_san_cfg.pdf
Zum Thema outstanding disk requests http://kb.vmware.com/kb/1268
Und dann noch ein paar generelle Tuning Recommendations zu Oracle.
Gruß
Ralf
es gibt eine Präsentation von der VMWorld Europe 2008, da solltest du eigentlich ne Menge nützlicher Infos finden.
http://www.vmworld.com/docs/DOC-2474
Leider ist der Zugriff (noch) ausschließlich für Teilnehmer freigeschaltet, aber vielleicht hast du ja diesen Zugriff.
Zum Thema FC LUN queue depth: http://kb.vmware.com/kb/1267
Sorry, das ist inzwischen in die folgende Doku gewandert http://www.vmware.com/pdf/vi3_esx_san_cfg.pdf
Zum Thema outstanding disk requests http://kb.vmware.com/kb/1268
Und dann noch ein paar generelle Tuning Recommendations zu Oracle.
- use 64-bit DB
add enough memory to cache DB, reduce I/O
use Direct-IO high performance uncached pass-trough
use Asynchronous I/O to reduce system calls
use large MMU pages
optimize storage layout, amount of disk spindles
Gruß
Ralf
Hallo ,
vielen Dank.
die 64 Bit -Variante habe ich schon getestet, das hilft wirklich etwas, aber natürlich hauptsächlich wegen der Möglichkeit einer großen SGA.
Ich habe derzeit die vRaid1 Luns via LVM eingebunden (jede Lun eine eigene PVG/LVG)
Angeblich ist die Performace ja vergleichbar mit ASM von oracle. Und CPU-Probleme habe ich eigentlich nicht.
Dagegen sprechen diese Empfehlung bzw, ich wüsste nicht, wie ich mit LVM so etwas realisieren könnte wie "direct-io"
Ist LVM doch vielleicht das Problem, speziell in Verbindung mit ESX-Server?
Gruß
vielen Dank.
die 64 Bit -Variante habe ich schon getestet, das hilft wirklich etwas, aber natürlich hauptsächlich wegen der Möglichkeit einer großen SGA.
Ich habe derzeit die vRaid1 Luns via LVM eingebunden (jede Lun eine eigene PVG/LVG)
Angeblich ist die Performace ja vergleichbar mit ASM von oracle. Und CPU-Probleme habe ich eigentlich nicht.
Dagegen sprechen diese Empfehlung bzw, ich wüsste nicht, wie ich mit LVM so etwas realisieren könnte wie "direct-io"
Ist LVM doch vielleicht das Problem, speziell in Verbindung mit ESX-Server?
Gruß
-
kastlr
- Profi
- Beiträge: 993
- Registriert: 31.03.2008, 17:26
- Wohnort: Einzugsbereich des FC Schalke 04
- Kontaktdaten:
Hallo,
leider bin ich kein Linux Spezialist und kann dir daher die Frage bezüglich LVM nicht beantworten.
Wieviele physikalische Disks nutzt du denn auf der EVA?
Denn je nach I/O Profil ist das Problem eventuell auf der Storageseite zu suchen.
Als Richtwert kannst du folgende Werte annehmen.
Ralf
leider bin ich kein Linux Spezialist und kann dir daher die Frage bezüglich LVM nicht beantworten.
Wieviele physikalische Disks nutzt du denn auf der EVA?
Denn je nach I/O Profil ist das Problem eventuell auf der Storageseite zu suchen.
Als Richtwert kannst du folgende Werte annehmen.
- 10k RPM Disk, 150 IO/sec max, ~80 IO/sec average
15k RPM Disk, 280 IO/sec max, ~120 IO/sec average
- Data, Transaction Log und TempDB auf separaten Disks
RAID 10 oder RAID5 für Data
RAID1 für logs
multiple Pfade zu den LUN's
Allignment der Partition gemäß Vorgaben Storage Vendor
Ralf
Vermutlich werde ich die Datenbank komplett vom ESX Server-Umfeld und der EVA wegnehmen. Das kommt billiger als das ganze ESX-Umfeld (versuchsweise) aufzurüsten und der EVA datenbankoptimiertes separates Plattenumfeld zu spendieren. Glücklich bin ich damit nicht, aber wir brauchen Ergebnisse....
Gruß + Dank
Gruß + Dank
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 4 Gäste