“CPU Time” Oracle bekleme olayı ve CPU önceliklerinin değiştirilmesi

“CPU Time” olayını, performans olaylarını incelerken genellikle Top5 bekleme olayı listesi içinde gözlemleriz. DBA penceresinden bakınca yaygın düşünce, CPU bekleme olayının bir darboğaz olduğu şeklindedir.  Aslında Oracle dökümanlarında da CPU tüketimi ilgili bir takım bekleme olaylarının darboğaz oluşturduğu şeklinde açıklamalar vardır.

Peki eğer sistem içindeki istatistiklerde CPU Tüketimi(%Util ve Çalışma Kuyruğu) kabul edilebilir seviyeler içindeyse ve yeterli kapasiteye sahiplerse, ancak Oracle hala CPU Time bekleme olayını Top 5 bekleme olayı içerisinde listeliyorsa ne yapılmalıdır?

Bu arada yüksek derecede istemsiz içerik değişmesi(Solaris üzerinde mpstat ile) veya içerik değişmesi(Linux üzerinde vmstat ile) gözlemlenebilir.  Burada açık olarak söylemek gerekirse bazı şeylerin doğru hesaplanmadığı anlaşılmaktadır.

CPU süresi, bir prosesin aşağıdaki iki noktadan birisi anlamına geldiğini gösterir;

• CPU üzerinde bu proses için zamanlanmış bir çalışma kuyruğu beklemesi vardır.
• Veya, proses bir CPU üzerinde halihazırda çalışmaktadır. 

Aslında bir DBA olarak bu durumda bizi ilgilendiren noktalar;

• Çalışma kuyruğu üzerinde bekleme süresini azaltarak, oturumun CPU üzerinde en kısa süre içinde çalışabilmesini sağlamak. Bu prosesin önceliğinin ele alınmasıyla ayarlanabilir.
• CPU üzerinde çalışmaya başlangıcından görev sonlanana kadar bir prosesin kesintiye uğramadan çalışmasının sürdürülmesi. CPU üzerinde proses için uygun zaman miktarı “Time Quanta-Zaman Ayarı” olarak tanımlanmaktadır.

Yukardaki her iki görüşte OS Zamanlayıcısı veya OS Dispatcher tarafından kontrol edilmektedir. Aşağıda bilgisayar terminolojisinde zamanlamanın(scheduling) ne anlama geldiğini açıklayan bir açıklama yer almaktadır.

"Zamanlama(scheduling) kavramı bilgisayar çoklu görevlerinde, çoklu proses işletim sistemlerinde ve gerçek zamanlı işletim sistemi tasarımlarında anahtar rol oynayan bir kavramdır. Modern işletim sistemlerinde çalışan pekçok proses, bu proseslerin toplamına yetecek CPU sayısı olmasa bile sorunsuzca çalışmaktadır. Zamanlama, bir prosesin çalışması için uygun bir CPU kaynağının atanması anlamına gelmektedir. Bu atama işlemi yazılım dünyasında zamalanlayıcı(scheduler) veya bazen dispatcher olarak tanımlanmaktadır." Zamanlayıcının CPU kaynaklarını nasıl paylaştğını anlamak, “CPU Time” bekleme olayını ve bunun sisteme olan etkisini anlamaya yardımcı olacaktır.

Herhangi bir UNIX platformunda, diğerler proseslerden daha yüksek önceliğe sahip prosesler mevcuttur. Bir prosesi daha yüksek önceliğe taşımak, “scheduling-zamanlama” sınıflarının uygulaması üzerinden ve “nice” komudu ile yapılabilmektedir.

Zamanlama sınıfını ve bir prosesin mevcut önceliğini belirlemenin en kolay yolu ps komutu kullanımı ile olabilmektedir. "-flycae" argumanı ile hem zamanlayıcı sınıfı, hemde mevcut öncelik görülebilmektedir.  Ancak,  bir proses ile ilişkili CPU zaman payı görülemez.

$ ps -flycae |egrep "ora_" |more

S   UID    PID   PPID   CLS   PRI  CMD
S   oracle 221   1      TS    24  ora_p000_DW
S   oracle 226   1      TS    24  ora_p001_DW

CLS ve PRI kolonları öncelikli olarak dikkate alınmalıdır. Yukardaki örnekte, TS(Time Scheduling) zamanlama sınıfı altında çalışan Oracle arkaplan prosesleri 24 önceliğine sahiptir. PRI kolonunda raporlanan yüksek numerik değer, yüksek önceliği işaret etmektedir. 

Kullanıcı prosesi için varsayılan zamanlayıcı TS veya Time Share olarak adlandırılır ve Solaris ve Linux sistemler üzerinde oldukça yaygındır. TS zamanlayıcısı, en son işlemci kullanımına dayanan prosesler için öncelikleri ve CPU zaman payını değiştirir.

CPU kaynaklarının bol şekilde görüldüğünden bu yana, varsayılan (TS) zamanlama sınıfının yeterince iyi görünmediği sonucu çıkarılabilir. Zamanlayıcının yeterli CPU payı tahsis edememesi(ki  bu durum istemsiz içerik değişmesine sebep olur), yada  bir prosese yeterince yüksek öncelik verilmemesi bu prosesin diğer proseslerden daha sonra zamanlayıcı tarafından işleneceğini işaret edebilecektir.

Peki bu durum nasıl değiştirilebilir? Aslında yapmak istediğimiz;

• Oracle prosesleri için sabit bir öncelik atayarak bu proseslerin diğer rakip proseslerden daha önce çalışabilmesini sağlamak
• Oracle prosesleri için sabit bir zaman payı atayarak CPU üzerinde tamamlanmak üzere çalışabilmelerini sağlamak.

Solaris ve Linux üzerinde yukardaki iki isteği yerine getirmenin en kestirme yolu zamanlama sınıfını Oracle prosesleri için değiştirmektir. Hem Linux hem Solaris işetim sistemleri, zamanlama sınıfının sabit öncelikler ve sabit CPU zaman payı ile birlikte kullanımını destekler. Buradaki “sabit” kelimesi terminolojik olarak, bir prosesin yaşam süresince sabitlendiği, ancak herhangi bir zaman diliminde değişen gereksinimleri karşılayabilmek için değiştirilebileceği anlamına gelmektedir.

Linux sistemlerde RT sınıfı, Solaris sistemlerde ise bu FX sınıfıdır. Zamanlama sınıfını değiştirmenin en basit yolu priocntl aracını kullanmaktır. Solaris üzerinde “native binary” iken, Linux üzerinde Heirloom Project üzerinden kullanılır.

Linux üzerinde, CPU zaman paylarını değiştirmek için renice komutu kullanılırken, Solaris üzerinde priocntl komutu hem zamanlama sınıfını, hemde zaman payını değiştirmek için kullanılmaktadır.

Aşağıda bunlarla ilgili örnekler yer almaktadır.

Linux üzerinde Log Writer(LGWR) prosesi için zamanlama sınıfı ve zaman payının değiştirilmesi;

# ./priocntl -l

CONFIGURED CLASSES
==================

TS (Time Sharing)
Configured TS User Priority Range: -19 through 20

RT (Real Time Round Robin)
Maximum Configured RT Priority: 99

FF (Real Time First In-First Out)
Maximum Configured FI Priority: 99

Yukardaki sonuçta kullanıma uygun 3 zamanlama sınıfının olduğunu görüyoruz. Aşağıda LGWR prosesinin TS(Time Sharing) sınıfında 23 önceliği ile çalıştığını görüyoruz.

# ps -flycae |grep ora_lgwr
S   UID    PID   PPID CLS   PRI   CMD
S   oracle 21021 1    TS    23    ora_lgwr_AYSUN

# ./priocntl -d 21021
TIME SHARING PROCESSES
PID      TSUPRI 21021     0

Şimdi LGWR prosesine RT(Real Time) sınıfında 50 önceliğini atıyoruz.

# ./priocntl -s -c RT -p 50 -i pid 21021

# ./priocntl -d 21021
REAL TIME PROCESSES
PID     RTPRI   TQNTM 21021   50      99

Yukarda da görüldüğü gibi, RT önceliği 50 ve Zaman Payı ise 99 olarak ayarlanmıştır.

# ps -flycae |grep ora_lgwr
S  UID    PID    PPID  CLS  PRI  CMD
S  oracle  21021 1     RR   90   ora_lgwr_AYSUN

RT önceliği 50 olarak atanmasına rağmen ps komutu PRI önceliğini 90 olarak göstermektedir. Şimdi LGWR prosesi için zaman payını değiştiriyoruz.

 # renice +2 21021
21021: old priority 0, new priority 2

# ps -flycae |grep ora_lgwr
S   UID    PID   PPID CLS PRI CMD
S   oracle 21021 1    RR  90 ora_lgwr_AYSUN


RT prosesinin önceliğini yeniden değiştirdikten sonra PRI içinde bir değişiklik olmamıştır.

# ./priocntl -d 21021
REAL TIME PROCESSES
PID      RTPRI  TQNTM
21021    50      89

Ancak priocntl komutu ile kontrol ettiğimizde zaman payının 89 olarak değiştiğini görüyoruz(daha önceden 99 idi). Şimdi zaman payını arttırabilecekmiyiz bir bakalım.

# renice -3 21021
21021: old priority 2, new priority -3

# ./priocntl -d 21021
REAL TIME PROCESSES
PID     RTPRI    TQNTM
21021    50       459

Evet, zaman payı 459’a çıktı şimdi. Zaman payının yüksek değerde olması, prosesin CPU üzerinde içerik değişmesi öncesinde o kadar fazla zaman harcayacağına imkan verecektir.

Solaris için "priocntl" komutu, zamanlama sınıfı ve zaman payının aynı anda ayarlanması için kullanılmaktadır.

$ ps -flycae |grep ora_lms
S    UID    PID   PPID CLS   PRI   CMD
S    oracle 9074  1    RR    41    ora_lms0_AYSUN
S    oracle 9078  1    RR    41    ora_lms1_AYSUN

# ./priocntl -d 9074
REAL TIME PROCESSES
PID     RTPRI    TQNTM
9074    50       99