Performance overview

Performence merupakan cara sebuah sistem komputer berjalan dalam merespon

fakta-fakta pada beban kerja. Performence diukur dalam hubungan dari system
respone time, throughput, dan resource utilization.
Performece juga dipengaruhi oleh:
Ketersediaan resource pada system
Seberapa bagus resource tersebut digunakan dan dishare
Secara umum, kamu dapat melakukan tuning pada sistem untuk meningkatkan costbenefit ratio. Tujuan spesifiknya ialah:
Memproses lebih besar, atau lebih menuntut, workloads tanpa meningkatkan
processing cost.
Mendapatkan sustem respone time lebih cepat, atau keluaran lebih tinggi,
tanpa meningkatkan processing costs
Mengurangi procesing cost tanpa menurunkan layanan pada user.
Beberapa keuntungan dari performence tuning, seperti lebih efficient menggunakan
resource dan kemampuan menambah user pada system. Keuntungan lain, seperti
kepuasan user lebih baik karena lebih cepat merespone time secara nyata.

Hal- Hal yang perlu dimonitor dan dimanage

System architecture
Table space design
Database design
Resource utilization
Data organization
Aplication design
Lock management
Explicit hierarchical locking for DB2 for scale environment
Query optimization

Performance tuning tools and methodology

Benchmark testing
Benchmark testing melakukan pada system untuk menentukan performence saat ini
dan dapat digunakan untuk meningkatkan performence dari aplikasi. Jika aplikasi
code telah ditulis secara effisien, additional performance mungkin dapat
direalisaskan oleh tuning database dan database manager configuration.

Perbedaan tipe dari benchmark test adalah digunakan untuk merangkup jenis
spesifik dari informasi. Sebagai contoh:
Sebuah infrastruktur benchmark menentukan kemapuan throughput dari
database manager pada kondisi terbatas laboratory yang pasti.
Sebuah application benchmark menentukan kemapuan throughput dari
database manager pada kondisi yang lebih lekat menggambarkan production
environment.
Benchmark test execution
Step 1
Keluar DB2 registry, database dan database manager configuration parameters,
dan bufferpools pada standart recommended values, yang dapat dimasukkan:
Values yang diketahui untuk diperlukan pada proper dan error-free aplication
Values yang dibutuhkan meningkatkan performence selama prior tuning.
Values yang disugestikan oleh AUTOCONFIGURE command
Default values; meskipun, ini mungkin tidak diperbolehkan :
o Untuk parameters yang significant untuk workload dan untuk objectives
dari test
o Untuk log sizes, yang harus ditentukan selama unit dan sistem testing.
o Untuk paramater apapun yang harus diganti untuk dapat menjalankan
aplikasi
Jalankan set dari iterations pada initial case ini dan hitung rata-rata eapsed time,
throughput, atau processor time. Hasilnya harus konsisten dan mungkin, idealnya
berbeda oleh tidak lebih dari beberapa persentase poin dari run to run. Mengukur
performence yang lebih signifikan dari run to run dapat dilakukan tuning sangat sulit.
Step 2
Select one and only one method or tuning parameter to be tested, and change its
value. Pilih satu dan hanya satu method atau tuning parameter untuk ditest, dan
mengganti value tersebut
Step 3
Jalankan himpunan iterasi lain dan hitung rata-rata elapsed time atau processor
time.
Step 4
Berdasarkan pada hasil dari benchmark test, lakukan salah satu berikut:
Jika performences meningkat ganti nilai dari parameter yang sama dan
kembali ke step 3. Pertahankan penggantian parameter ini sampai maximum
benefit muncul.
Jika performence menurun atau tetap, menghasilkan parameter sebelumnya,
kembali step 2, dan pilih parameter baru. Ulangi prosedur ini sampai semua
parameter telah ditest.
Contoh benchmark analysis testing

Basic set of system performance monitor elements

11 metric dari system menghasilkan good basic set untuk digunakan dalam usaha on-going
operational monitoring.

Ada ratusan metric yang dapat dipilih, tapi mengumpulkan semuanya dapat
mengakibatkan counter-productive pada sheer volume dari data yang diproduksi.
Metric yang anda inginkan ialah:
Easy to collect - Kamu tidak ingin untuk menggunakan complex atau
expensive tool setiap hari untuk monitoring, dan kamu tidak melakukan
monitoring untuk secara signifikan membebani system.
Easy to understand - Kamu tidak ingin melihat pengertian dari metric setiap
kali dilihat.
Relevant to your system - Tidak semua metric menghasilkan informasi yang
berarti pada semua environment.

Sensitive, but not too sensitive - Perubahan dalam metric harus

mengindikasikan perubahan dalam system secara nyata; metric harus tidak
berubah-ubah.

11 metric awal :

1. Jumlah dari transaction yang dieksekusi:

TOTAL_APP_COMMITS

Hal ini menghasilkan base level measurement dari system activity yang
unggul.
2. Buffer pool hit ratios, diukur terpisah pada data, index, XML storage object,
dan temporary data:
o Data pages: ((pool_data_lbp_pages_found pool_async_data_lbp_pages_found - pool_temp_data_l_reads) /
pool_data_l_reads) 100
o Index pages: ((pool_index_lbp_pages_found pool_async_index_lbp_pages_found - pool_temp_index_l_reads) /
pool_index_l_reads) 100
o XML storage object (XDA) pages: ((pool_xda_lbp_pages_found pool_async_xda_lbp_pages_found - pool_temp_xda_l_reads) /
pool_xda_l_reads) * 100
o Temporary data pages: ((pool_temp_data_l_reads pool_temp_data_p_reads) / pool_temp_data_l_reads) 100
o Temporary index pages: ((pool_temp_index_l_reads pool_temp_index_p_reads) / pool_temp_index_l_reads) 100
3. Buffer pool physical reads dan writes per transaction:
(POOL_DATA_P_READS + POOL_INDEX_P_READS + POOL_XDA_P_READS
POOL_TEMP_DATA_P_READS + POOL_TEMP_INDEX_P_READS)
/ TOTAL_APP_COMMITS
(POOL_DATA_WRITES + POOL_INDEX_WRITES + POOL_XDA_WRITES)
/ TOTAL_APP_COMMITS

Metric ini mirip dengan bufferpool hit ratios, tapi sedikit berbeda pada
tujuannya. Meskipun kamu dapat menentukan target value dari hit ratio, tidak
ada target yang mungkin dari read dan write per transaction.
4. Ration dari database rows yang dibaca ke rows yang dipilih:
ROWS_READ / ROWS_RETURNED

Perhitungan ini memberikan indikasi dari rata-rata jumlah dari baris yang
dibaca dari tabel-tabel database untuk menemukan baris yang memenuhi
syarat. Jumlah yang sedikit adalah indikasi dari efisiennya pengalokasian
data, dan secara umum menunjukkan index-index yang telah digunakan
secara effisien.
5. Jumlah dari waktu yang dihabiskan untuk mengurutkan per transaksi:
TOTAL_SORT_TIME / TOTAL_APP_COMMITS

Hal ini jalan yang effisien untuk menangani sort statistics, karena banyak
extra time pada sorting yang ditumpahkan secara automatic.
6. Jumlah dari lock wait time diakumulasikan per seribu transactions:
1000 * LOCK_WAIT_TIME / TOTAL_APP_COMMITS

Excessive lock wait time sering diterjemahkan dalam respone time yng buruk,
jadi penting untuk dimonitor. Hasil dinormalisasikan ke satu ribu transaksi
karena lock wait time pada satu transaksi secara khas sedikit rendah. Secara
teori satu ribu transaction dapat mengukur lebih mudah untuk ditangani.

7. Jumlah deadlocks dan lock timeouts per seribu transactions:

1000 * (DEADLOCKS + LOCK_TIMEOUTS) / TOTAL_APP_COMMITS

Meskipun deadlock jarang dibandingkan dalam hampir semua system yang

diproduksi, lock timeout merupakan sesuatu yang lazim. Memonitor rate lock
timeout yang terjadi membantu menghindari kasus dimana banyak deadlock
atau lock timeout mengendalikan secara signifikan extra load pada system
tanpa DBA khawatir.
8. Jumlah dari dirty steal triggers per seribu transactions:
1000 * POOL_DRTY_PG_STEAL_CLNS / TOTAL_APP_COMMITS

Dirty steal adalah jalan terakhir yang dipilih untuk membersihkan trigger buffer
pool. Secara essensial, proses dari SQL satement yang diperlukan sebuah
bufferpool page baru diinterupt selama mengupdate pada victim page yang
ditulis ke disk. Jika dirty steal diperbolehkan sering terjadi, hal ini secara
signifikan dapat memengaruhi throughput dan respone time.
9. Jumlah dari package cache sisipan per seribu transactions:
1000 * PKG_CACHE_INSERTS / TOTAL_APP_COMMITS

Package cache sisipan merupakan bagian yang normal dari eksekusi pada
system; meskipun dalam jumlah besar, mereka secara signifikan dapat
menghabiskan CPU time.
10. Waktu dari sebuah agent menunggu untuk log records diperbarui pada disk:
LOG_WRITE_TIME
/ TOTAL_APP_COMMITS

Transaksi log secara signifikan memiliki potensi menyebabkan sebuah system

bottleneck, dimana terjadi high level dari akctivity, atau konfigurasi yang tidak
benar, atau penyebab lain.
11. Dalam partitioned database environments, jumlah dari fast communication
manager (FCM) buffersdikirim dan diterima antar partitions:
FCM_SENDS_TOTAL, FCM_RECVS_TOTAL

Hal ini memberikan kecepatan aliran data antara beda partisi dalam cluster,
dan secara khusus, aliran diseimbangkan. Perbedaan signifikan dalam jumlah
buffer yang diterima dari partisi berbeda mungkin mengindikasikan sebuah
ketidakbenaran dalam jumlah data yang dihash pada setiap partisi.