Oracle 11g RAC mimarisinde GCS ve GES performansını izleme ve iyileştirme tavsiyeleri

Oracle 11g RAC mimarisinde performans izleme ve iyileştirme noktasında GCS ve GES servislerinin iyileştirilmesi, private bağlantının(interconnect) network performansının artırılması önem kazanmaktadır. Bunları detaylı olarak aşağıda incelemeye başlayalım.

Global Cache Services(GCS) kalıcı okumalarının(cr) izlenmesi

Kalıcı okumaların(consistent read-cr) performansını izlemek için alttaki formül kullanılır.

 (gc cr block receive time × 10) / (gc cr blocks received)

Yukardaki formulün sonucunda instance için milisaniye değerinde kalıcı blok okuması taleplerinin ortalama zamanı dönmektedir ve Enterprise Manager RAC performans görünümlerinde gözlemlediğimiz global bellek blok transfer oranı (Global Cache Block Transfer Rate) metrikidir. Bu değer interconnect performansını belirlemek için kullanılan en önemli değerdir.

Veri blokları için global kaynak talepleri, talep eden instance’ın ön belleği içinde meydana gelir. Talep, GCS talep kuyruğuna girmeden önce Oracle, SGA içinde talebin durumunu izleyecek ve bu kaynak yapıları üzerinde istatistik toplayacak veri yapılarını tahsis eder.

SQL> SELECT

> gc_cr_block_receive_time AS "Receive Time",

> gc_cr_blocks_received AS "Blocks Received",

> (gc_cr_block_receive_time * 10) /

> gc_cr_blocks_received AS "Average Latency (MS)"

> FROM

> (

> SELECT value AS gc_cr_block_receive_time FROM v$sysstat

> WHERE name = 'gc cr block receive time'

> ),

> (

> SELECT value AS gc_cr_blocks_received FROM v$sysstat

> WHERE name = 'gc cr blocks received'

> );

Alttaki sonuç yukardaki raporun çalışması sonucu alınan bir örnek sonuçtur:

Receive Time   Blocks Received          Average Latency (MS)

--------------         --------------------           --------------------

5405                    3869                            23.9681803

Kalıcı blok talep gecikmesi, orijinal talep ile lokal instancetaki kalıcı blok imaj alındısı arasında geçen zamandır.Gigabit Ethernet bağlatısı ile, bu değer normalde 5ms altında olmalı ve 15ms üzerine çıkmamalı, bununla beraber bu değer sistem konfigürasyonu ve hacimdende etkilenebilmektedir. Yukardaki örnekte gecikme süresi 24ms dir. Linux içerisinden “netstat” komutunu kullanarak network paket alımı ve gönderimi gibi bir network yapılandırma sorunu olup olmadığı anlaşılabilir. Bunun yanında, “top” ve “sar” komutları ile düğümler üzerindeki yükü ölçmelisiniz.  

Ayrıca RAC düğümündeki failover performansını artırmak için;

AIX sistemlerde; rto_length, rto_low, ve rto_high network parametre değerleri düzenlenerek failover süresi azaltılabilir. rto_length değerinin varsayılan değeri 13'tür ve bu değer ne kadar paketin işlendiğini gösterir.Böylece, AIX sistemlerde varsayılan timeout değeri 9.3 dakika olmaktadır, halbuki rto_length değeri 7 olarak değiştirildiğinde varsayılan timeout süresi 2.5 dakikaya düşmektedir.

Linux sistemlerde; aşağıdaki parametreler Metalink Note:249213.1 ve Note:265194.1 tarafından tavsiye edilen değerlere göre değiştirildiğinde failover performansı artış gösterir.


Eğer “interconnect” düzgün bir şekilde yapılandırıldıysa ve hala yüksek ortalama gecikme süreleri varsa, bu durumda DB_FILE_MULTIBLOCK_READ_COUNT parametresinin değerini düşürün. Bu değer tekli operasyonda beher proses için ne kadar bloğun belirler. Proses tüm blokların dönmesini bekleyeceğinden dolayı muhtemelen yüksek bekleme oranlarına sebebiyet verebilir. Bu parametreyi düzenlemeden önce, tüm işyükündeki etkisini gözden geçirin.

net.ipv4.tcp_keepalive_time

net.ipv4.tcp_keepalive_intvl

net.ipv4.tcp_retries2

net.ipv4.tcp_syn_retries

Yüksek ortalama gecikme süreleri, yüksek sayıdaki gelen çağrılar veya birçok proses çağrıları LMS prosesine dağıtması yüzünden meydana gelebilir. Ortalama LMS servis süresi aşağıdaki formul ile hesaplanabilir.

average LMS service time = average latency - average time to build consistent read block - average time to wait for log flush - average time to send completed block

• Kalıcı okuma bloğu inşa etmek için gereken ortalama zaman hesaplaması:

gc cr block build time / gc cr blocks served

• Redo log flush işlemi için ortalama bekleme süresi hesaplaması:

gc cr block flush time / gc cr blocks served

• Tamamlanmış bloğun ortalama gönderim süresi hesaplaması:

gc cr block send time / gc cr blocks served

Alttaki sorgu, kalıcı blok okuması için gereken ortalama LMS servis süresini hesaplamaktadır.

SQL> SELECT

> average_latency AS "Average Latency",

> average_build_time AS "Average Build Time",

> average_flush_time AS "Average Flush Time",

> average_send_time AS "Average Send Time",

> average_latency - average_build_time - average_flush_time - average_send_time

> AS "Average LMS Service Time"

> FROM

> (

> SELECT

> (gc_cr_block_receive_time * 10) / gc_cr_blocks_received AS average_latency,

> (gc_cr_block_build_time * 10) / gc_cr_blocks_served AS average_build_time,

> (gc_cr_block_flush_time * 10) / gc_cr_blocks_served AS average_flush_time,

> (gc_cr_block_send_time * 10) / gc_cr_blocks_served AS average_send_time

> FROM

> (

> SELECT value AS gc_cr_block_receive_time FROM v$sysstat

> WHERE name = 'gc cr block receive time'

> ),

> (

> SELECT value AS gc_cr_blocks_received FROM v$sysstat

> WHERE name = 'gc cr blocks received'

> ),

> (

> SELECT value AS gc_cr_block_build_time FROM v$sysstat

> WHERE name = 'gc cr block build time'

> ),

> (

> SELECT value AS gc_cr_block_flush_time FROM v$sysstat

> WHERE name = 'gc cr block flush time'

> ),

> (

> SELECT value AS gc_cr_block_send_time FROM v$sysstat

> WHERE name = 'gc cr block send time'

> ),

> (

> SELECT value AS gc_cr_blocks_served FROM v$sysstat

> WHERE name = 'gc cr blocks served'

> ) );

Oratalama gecikme süresi ve ortalama inşa, boşaltma ve gönderme zamanı arasındaki farklılık, LMS servisi içindeki harcanan zamanı ve “interconnect” üzerinden mesaj işlerken geçen süreyi temsil eder. Aşağıdaki sorgu sonucu buna bir örnek teşkil etmektedir.

Average           Average           Average           Average           Average

Latency           Build Time       Flush Time      Send Time       LMS Service Time

-----------          -----------          -----------          ------------         ----------------

41.8455403     0.039572616   0.696264345   0.03661535    40.957365

Yukardaki örnekte görüldüğü üzere doğrusu LMS servis zamanında baya yüksek bir bekleme oranı mevcuttur. netstat- l ile TCP/UDP paketleri incelenmelidir. Oracle Net hizmetlerinde RECV_BUF_SIZE ve SEND_BUF_SIZE parametrelerinin BDP (Bandwidth Delay Product) değerinin 3 katına eşit olmasını sağlanması gerekmektedir. Bu sayede network çıktısında büyük artışlar sağlanacaktır.

Yüksek LMS değerleri aynı zamanda interconnect veya sunucu bazlı sorunlar olduğuna işaret eder.Bununla beraber yüksek “average pin time” değerleri olduğunda, LGWR prosesinin işlem önceliğini artırın. Redo log dosyaları üzerinde yazma performansının artması tüm RAC ortamında blok işlemlerinde performans artışı sağlayacaktır. Örneğin, Solaris host için aşağıdaki gibi LGWR prosesine öncelik verebilirsiniz.

priocntl -e -c class -m userlimit -p priority

priocntl -e -c RT -p 59 `pgrep -f ora_lgwr_${ORACLE_SID}`

priocntl -e -c FX -m 60 -p 60 `pgrep -f ora_lms[0-9]*_${ORACLE_SID}`

Bunun yanında Linux 2.16 versiyon üzerinde maksimum UDP tampon büyüklüğü 4MB'dır ve alım tarafında otomatik iyileştirm etkindir.  udp_max_buffer parametresini 8MB 'ye artırarak maksimum UDP tampon büyüklüğünün genişletilmesi gerekmektedir. Bunun neticesinde de udp_xmit_hiwat ve udp_recv_hiwat değerlerini 256KB'ya yükselterek, yetersiz UDP alım/işleme tampon büyüklüğü yüzünden düşen paket sayısını önemli oranda azaltmak mümkün olacaktır. Bunun yanında eğer networkunuz jumbo frame destekliyorsa, jumbo frameleri kullanın. Tipik olarak MTU büyüklüğü 1500 bytes büyüklüğündedir, bu değeri yaklaşık 9000 bytes sınırına çıkarın.

Soket tampon büyüklüğü hem işletim sistemi seviyesinde hemde Oracle net servisleri seviyesinde atanabilir. Bazı Linux işletim sistemi versiyonlarında bu değerler olduğundan fazla yüksek olabilir.Bu  durumda bu değerleri optimal seviyeye indirmeniz gerekmektedir. Düğümlerdeki sqlnet.ora dosyalarına aşağıdaki eklemeler yapılabilir.

RECV_BUF_SIZE= <soket tampon büyüklüğü>

SEND_BUF_SIZE= <soket tampon büyüklüğü>

Kuyruk büyüklüğünü kernel network alt sistemleri ve ethetnet kartı sürücüsü arasındada düzenleyebiliriz. Herhangi bir kuyruk tekrardan boyutlandırılabilir, böylece local tampon aşırı yüklemeleri sebebiyle kayıplar meydana gelmez. Bu yüzden yüksek bant genişliğindeki networklerde etkili iyileştirme yapmak için kuyruk büyüklüklerinin mevcut network bağlantımıza uygun olduğundan emin olmamız gerekmektedir. Kuyruk büyüklükleri için Linux’ta 2 kuyruk tipi önemlidir, arayüz iletim kuyruğu ve network alım kuyruğu. ifconfig ile gönderim tarafında TXQUEUELEN arayüzü seçeneğini artırın, alım tarafında ise NET_DEV_MAX_BACKLOG kernel parametre değerini artırın.

100ms latency ye sahip 1 gigabitlik network için bir örnek altta yer almaktadır.Bu şartlarda network için TXQUEUELEN değeri en az 10000 olmalıdır. İdeal değerler için Linux üreticilerinin tavsiyeleri alınabilir.

echo 20000 > /proc/sys/net/core/netdev_max_backlog

echo 1 > /proc/sys/net/ipv4/route/flush

ifconfig eth0 txqueuelen 10000

Mevcut Bloklar

SQL*Plus kullanarak EM RAC performans görünümlerindeki Global Cache Block Transfer Rate oranı ile mevcut blok aktivitesini izleyebiliriz. Mevcut bloklar için işlem gören çağrılar içinde baştan sona ortalama gecikme süresi aşağıdaki formül ile bulunabilir.

SQL> SELECT

> gc_current_block_receive_time AS "Receive Time",

> gc_current_blocks_received AS "Blocks Received",

> (gc_current_block_receive_time * 10) / gc_current_blocks_received

> AS "Average (MS)"

> FROM

> (

> SELECT value AS gc_current_block_receive_time

> FROM v$sysstat

> WHERE name = 'gc current block receive time'

> ),

> (

> SELECT value AS gc_current_blocks_received

> FROM v$sysstat

> WHERE name = 'gc current blocks received'

> );

Aşağıdaki çıktı örnek bir sonuç olabilmektedir.

Receive Time               Blocks Received          Average (MS)

------------                     ---------------                 ----------------

12279                          14222                          8.63380678

Bunun yanında yüksek bekleme olaylarıyla ilişkili veritabanı objelerini bulmak için aşağıdaki sorgu çalıştırılabilir.

SELECT INST_ID "Instance", name, kind, sum(forced_reads) "Forced Reads", sum(forced_writes) "Forced Writes" 

FROM gv$cache_transfer

WHERE owner# != 0

GROUP BY inst_id, name, kind

ORDER BY 1,4 desc,2;

Instance NAME                                   KIND             Forced Reads   Forced Writes

--------- ----------------------------             ----------          ----------------      -------------

        1 MOD_TEST_IND                    INDEX             308                     0

        1 TEST2                                      TABLE            64                       0

        1 AQ$_QUEUE_TABLES          TABLE             5                        0

        2 TEST2                                      TABLE             473                    0

        2 MOD_TEST_IND                     INDEX            221                    0     

Bunun yanında Cache Fusion Hit Ratio oranını bulmak için ise;

SELECT A.inst_id "Instance",

A.VALUE/B.VALUE "Cache Fusion Writes Ratio"

FROM GV$SYSSTAT A, GV$SYSSTAT B

WHERE A.name='DBWR fusion writes'

AND B.name='physical writes'

AND B.inst_id=a.inst_id

ORDER

BY A.INST_ID;

Instance           Cache Fusion Writes Ratio

---------             -------------------------

        1                .227487558

        2                .141465042

Yüksek orandaki Cache FusionWrite Ratio değeri, yetersiz büyüklükte bellek olmasından  veya yetersiz checkpointten veya bellek yerleştirmesi -yada -checkpoint yüzünden çok büyük tamponların yazılmasından kaynaklanmaktadır.

Global Kuyruğa Alma Servisinin izlenmesi

SQL> SELECT

> global_enqueue_get_time AS "Get Time",

> global_enqueue_gets_sync AS "Synchronous Gets",

> global_enqueue_gets_async AS "Asynchronous Gets",

> (global_enqueue_get_time * 10) /

> (global_enqueue_gets_sync + global_enqueue_gets_async)

> AS "Average (MS)"

> FROM

> (

> SELECT value AS global_enqueue_get_time

> FROM v$sysstat

> WHERE name = 'global enqueue get time'

> ),

> (

> SELECT value AS global_enqueue_gets_sync

> FROM v$sysstat

> WHERE name = 'global enqueue gets sync'

> ),

> (

> SELECT value AS global_enqueue_gets_async

> FROM v$sysstat

> WHERE name = 'global enqueue gets async'

> );

Get Time         Synchronous Gets       Asynchronous Gets     Average (MS)

----------            ----------------                -----------------               ------------

159674            98861                          10555                          15.3954835

“Synchronous gets”  değerleri genellikle kilitleme olaylarını işaret ederken yüksek orandaki “asynchronous gets” ise instanceler arası engelleyici olmayan prosesler yüzünden meydana gelir.

Yukardaki örnekte ortalama global kuyruğa alma zamanı yaklaşık olarak 15.4 ms, ki bu değer kabul edilebilir sınırlar içindedir. Eğer bu oran 20ms üzerinde olursa, çalıştırdığınız uygulamada sorunların ve beklemelerin olduğu anlamına gelir.