Penyesuaian performa Oracle di Solusi Bare Metal
Tujuan
Dokumen ini memberikan panduan tentang cara menangani masalah terkait performa menggunakan Oracle pada Solusi Bare Metal.
Langkah 1: Kumpulkan Data Diagnostik
Pahami masalah sedetail mungkin. Kumpulkan informasi sebanyak mungkin, termasuk hal berikut:
- Informasi lingkungan database - ID/IP mesin, lokasi pusat data, detail lingkungan Oracle, dll.
- Deskripsi masalah termasuk linimasa.
- Cakupan dampaknya - Misalnya, apakah masalah hanya memengaruhi satu sesi atau server, atau serangkaian sesi dan server terkait, atau semua pengguna database?
- Jelaskan investigasi yang telah dilakukan sejauh ini. Apakah ada solusinya?
- Apakah masalah dapat direkonstruksi sesuka hati? Jika ya, bagaimana caranya?
- Apakah ada data dasar pengukuran yang baik untuk dibandingkan?
- Apakah ada perubahan terbaru pada konfigurasi di lapisan database, host, jaringan, penyimpanan, atau aplikasi, termasuk perubahan pada beban kerja?
- Kumpulkan semua log dan rekaman aktivitas yang relevan, termasuk ASH, AWR, log pemberitahuan, file rekaman aktivitas, dan log TFA/OS watcher.
# TFA command to generate a bundled package containing files like
# the AWR report, ADDM report, ASH report, OSWatcher and ORAchk performance
# related checks.
tfactl diagcollect -srdc dbperf
Langkah 2: Menganalisis dan membuat rekomendasi
Jangan ragu untuk melewati bagian di sini berdasarkan data yang Anda kumpulkan di atas.
2.1 Kesehatan host database
Melakukan health check cepat pada host database adalah awal yang baik. Anda seharusnya
dapat menggunakan file TFA/OSWatcher untuk periode
masalah. Anda pada dasarnya mencari tanda-tanda kejenuhan, penggunaan,
dan/atau error resource di sini. Anda juga dapat menggunakan BMS Infrascope
untuk memahami lingkungan Anda di tingkat tinggi menggunakan machine-id,
lun-id, dan sebagainya.
2.2.1 Log sistem
/var/log/messagesataudmesgdapat digunakan untuk mengidentifikasi potensi masalah di lapisan penyimpanan, n/w seperti yang terlihat oleh sistem.# System messages cat /var/log/messages Or dmesg -T
CPU 2.2.2
"uptime"/"top" dapat digunakan untuk melihat rata-rata beban sistem selama 1/5/15 menit terakhir. Pertimbangkan jumlah core CPU saat melihat angka ini. Di Linux, angka ini mencakup jumlah proses di cpu/menunggu cpu serta proses dalam mode tidur yang tidak dapat diganggu(biasanya disk i/o). Berikut beberapa perintah yang berguna.
# To find load average "w" Or "uptime" Or "top" [root@svr001 ~]# uptime 21:32:09 up 12 days, 1:04, 3 users, load average: 0.31, 0.44, 0.64 # To find CPU Usage over time "sar -u 5" [root@svr001 ~]# sar -u 5 Linux 4.14.35-2025.401.4.el7uek.x86_64 (svr001) 12/16/2020 _x86_64_ (16 CPU) 09:52:20 PM CPU %user %nice %system %iowait %steal %idle 09:52:25 PM all 0.63 0.00 0.73 0.11 0.00 98.52 09:52:30 PM all 1.10 0.00 0.82 0.15 0.00 97.93 # To list the no. of processes in Runnable (R) and in Uninterruptible sleep (D) states "ps -eo s,user,cmd | grep ^[RD] | sort | uniq -c | sort -nbr | head -20"
2.2.3 Memori
Gunakan "free" untuk menemukan memori bebas "tersedia", sistem yang sehat harus memiliki ruang yang cukup.
# Find system memory usage "free -m" [root@svr001 ~]# free -m total used free shared buff/cache available Mem: 385423 16603 188217 153744 180602 211778 Swap: 16383 0 16383"vmstat" dapat digunakan untuk melihat statistik swap (si,so). Anda akan melihat nol pada sistem yang sehat. Juga menyediakan kolom menarik lainnya untuk proses/memori/cpu dll. yang juga dapat menarik, bergantung pada masalahnya.
# Virtual Mem stats 5 snapshots 5 secs apart "vmstat 5 5" [root@svr001 ~]# vmstat 5 5 procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu----- r b swpd free buff cache si so bi bo in cs us sy id wa st 1 0 0 192717472 497132 184439376 0 0 82 35 2 0 1 1 98 0 0 1 0 0 192717520 497132 184439616 0 0 3225 719 15118 29594 1 1 98 0 0Pertimbangkan untuk mengaktifkan hugepages jika belum diaktifkan, untuk memanfaatkan ukuran halaman yang lebih tinggi, penguncian sga di memori sistem.
- Konfirmasi penggunaan hugepage di bagian init.ora pada laporan awr (use_large_pages ditetapkan ke only) atau di bagian startup instance di alert.log.
- Tidak menggunakan hugepage juga dapat menyebabkan pertukaran sistem dan penggunaan memori yang lebih tinggi per koneksi ke db.
2.2.4 Penyimpanan
"iostat" dapat digunakan untuk melihat statistik perangkat blok seperti await, avgqu-sz, %util yang dapat menunjukkan kejenuhan penyimpanan, performa yang kurang baik, dll.
# IO Stats with extended per-disk statistics "iostat -x 5 5" Or "sar -dp" # For devices with 90% utilization and above "sar -dp | awk '/%util/ || ($11 > 90)'" [root@svr001 ~]# iostat -x 5 5 Linux 4.14.35-2025.401.4.el7uek.x86_64 (svr001) 12/16/2020 _x86_64_ (16 CPU) avg-cpu: %user %nice %system %iowait %steal %idle 1.05 0.01 0.77 0.09 0.00 98.08 Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util sde 0.00 0.00 0.17 0.83 7.10 20.12 54.46 0.04 41.10 18.91 45.57 1.12 0.11 sdf 0.00 0.00 0.00 0.00 0.00 0.00 43.50 0.00 1.03 1.03 0.00 0.75 0.00 sdc 0.00 0.00 0.00 0.00 0.00 0.00 40.15 0.00 0.40 0.40 0.00 0.22 0.00 sda 0.00 0.00 1.16 20.80 7.76 177.15 16.84 0.02 0.82 0.73 0.83 0.14 0.31 sdd 0.00 0.00 43.24 8.03 639.16 97.67 28.75 0.01 0.20 0.18 0.31 0.18 0.92Beberapa titik awal yang baik, jika Anda melihat saturasi dengan IO, adalah hal berikut:
- QOS untuk jumlah IOPS (blok 8K) untuk volume SSD adalah 6.000 per terabyte. Google tidak menyediakan QoS untuk HDD. Tetapkan ekspektasi yang benar menggunakan angka ini.
- Jika Anda tidak melihat QOS yang diharapkan di atas, langkah berikutnya dapat berupa memastikan Anda telah mematuhi praktik terbaik terkait konfigurasi penyimpanan.
Setiap server BMS memiliki 4 NIC, masing-masing 25 Gbps, yang diikat ke dua NIC 50 Gb menggunakan agregasi link dinamis 802.3ad (aktif-aktif).
# Interface Transfer Speed # bond0 is the primary interface in this case. [root@svr001 ~]# ethtool bond0 | grep -i speed Speed: 50000Mb/sArtinya, ( 50000 Mb/s = 6250 MB/s = 6.400.000 KB/s ) adalah titik jenuh untuk antarmuka jaringan utama.
# Interface stats "sar -n DEV | head -3 && sar -n DEV | grep bond0" [root@svr001 ~]# sar -n DEV | head -3 && sar -n DEV | grep bond0 12:00:01 AM IFACE rxpck/s txpck/s rxkB/s txkB/s rxcmp/s txcmp/s rxmcst/s 12:10:01 AM bond0.118 87.30 49.94 69.45 24.93 0.00 0.00 0.00 12:10:01 AM bond0 89.31 52.26 71.58 25.59 0.00 0.00 2.00 12:20:01 AM bond0.118 21.91 13.21 18.92 8.02 0.00 0.00 0.00 12:20:01 AM bond0 23.94 15.55 19.65 8.39 0.00 0.00 2.00
Gunakan alat umum seperti ping, traceroute, tnsping, dll. untuk mencari kemungkinan masalah jaringan seperti kehilangan paket/latensi antara mesin pengguna/aplikasi dan server db. Lihat tutorial ini untuk mengetahui info selengkapnya.
# Quick check for 9000 mtu. # If not configured correctly, we will see "Message too long" errors ping -c 5 -s 8972 -M do <IP>Melihat statistik interkoneksi dalam laporan awr dan membandingkannya dengan dasar pengukuran yang baik serta menggunakan perintah "netstat -s" (penghitung statistik IP) untuk menemukan kegagalan fragmentasi/penyetelan ulang, masalah overflow buffering, dll. dapat memberi kita petunjuk tentang kondisi jaringan pribadi.
# Interface errors: [root@svr001 ~]netstat -s | egrep "IP|Ip|ip:|TCP|Tcp|tcp:|UDP|Udp|udp:|ICMP|Icmp|icmp:|IGMP|igmp:|icmpv6:|ipv6:|drop|Drop|dropped|Dropped|error|Error|discard|Discard|timeout|Timeout|fail|Fail|Receive|receive" Ip: 168848352 total packets received 0 incoming packets discarded 701 outgoing packets dropped 3265322 fragments received ok
2.3 Kondisi database
Setelah mengetahui kondisi sistem secara keseluruhan dan membuat pengamatan yang berguna, Anda dapat melihat lebih lanjut lapisan database. Bergantung pada sifat masalah, pastikan untuk mengumpulkan semua laporan yang relevan (awr, ash, dll.) dan file log (tfa, log pemberitahuan, file trace, dll.) yang dapat membantu mendiagnosis masalah.
Beberapa area utama yang perlu dilihat dalam laporan AWR adalah:
Bagian atas laporan
- Ringkasan lingkungan memberi tahu Anda info tentang info s/w oracle, info host seperti core, memori, waktu berlalu vs waktu db, dll.
- Profil pemuatan memberi tahu kita info tentang waktu Db vs CPU DB, statistik penguraian, statistik io, dll.
- Waktu DB = CPU DB + Waktu dalam antrean + menunggu CPU (antrean operasi)
- DB CPU = Waktu yang berjalan di CPU (runqueue tidak disertakan)
- Sesi aktif rata-rata = waktu db / waktu berlalu
- db cpu per detik / (num_cpus * detik yang berlalu) memberikan info tentang saturasi CPU oleh db
Init.ora
- Cari parameter apa pun (garis bawah, terkait data guard, dll.) yang dapat menjadi pemicu di sini.
Peristiwa terjadwal latar depan teratas
- Selidiki distribusi waktu db untuk mengidentifikasi potensi terbesar untuk peningkatan.
- Cari waktu tunggu teratas yang muncul di bagian tersebut dan karakteristik performanya seperti DBTime%, class tunggu, waktu rata-rata, dll.
- Bergantung pada peristiwa yang kami temukan di bagian ini, kami dapat melihat lebih lanjut bagian lain dalam laporan awr.
Statistik model waktu
- Beberapa statistik penting yang perlu dilihat di bagian ini adalah terkait pemrosesan, waktu CPU latar belakang, waktu berlalu eksekusi sql, CPU db.
- Umumnya, waktu pemrosesan SQL yang tinggi dan waktu penguraian yang rendah adalah yang diinginkan. waktu berlalu eksekusi sql yang jauh lebih tinggi daripada cpu db dapat menunjukkan waktu tunggu io yang tinggi.
Peristiwa Tunggu Oracle Umum yang terkait dengan masalah infrastruktur
sinkronisasi file log:
- sinkronisasi file log dapat disebabkan oleh masalah infrastruktur yang mendasarinya atau
karena desain aplikasi. Berikut adalah beberapa panduan yang dapat digunakan
untuk menentukan apakah infrastruktur yang menurun berkontribusi pada peristiwa
tunggu ini.
- sinkronisasi file log dapat disebabkan oleh performa yang buruk dari penyimpanan lokal serta penyimpanan dan/atau jaringan jarak jauh jika dataguard terlibat.
- performa operasi tulis paralel file log adalah indikator yang baik bahwa latensi ada di penyimpanan lokal yang secara langsung memengaruhi performa sinkronisasi file log. Anda dapat melihat histogram peristiwa tunggu dan membandingkannya dengan dasar pengukuran yang baik untuk menemukan variasi terbaru. Operasi tulis optimal yang umum ke disk akan mendekati 10 md.
- Memiliki penyiapan dataguard Ketersediaan/Perlindungan Maksimal dapat menjadi kontributor lain di sini. Anda dapat melihat waktu tunggu terkait data guard dan histogramnya dapat membantu menunjukkan latensi jaringan dan/atau masalah IO di situs standby.
- Penyebab lainnya adalah lgwr yang sibuk karena commit yang berlebihan atau kehabisan cpu. Statistik "waktu cpu latar belakang" harus diperiksa untuk memastikan bahwa statistik tersebut bukan merupakan sebagian besar waktu db.
- sinkronisasi file log dapat disebabkan oleh masalah infrastruktur yang mendasarinya atau
karena desain aplikasi. Berikut adalah beberapa panduan yang dapat digunakan
untuk menentukan apakah infrastruktur yang menurun berkontribusi pada peristiwa
tunggu ini.
Penantian terkait Cloud Storage:
- Selain merekomendasikan penyesuaian aplikasi yang banyak melakukan percakapan atau masalah hotspot, Anda harus memeriksa dan menghilangkan kemungkinan bottleneck performa interkoneksi.
- GLOBAL CACHE BLOCKS LOST/CORRUPT harus sedekat mungkin dengan nol.
- LOST - Blokir kerugian selama transfer. Dapat menunjukkan masalah jaringan
- CORRUPT - Nilai tinggi menunjukkan masalah IPC, jaringan, atau hardware.