Oracle Network Konfigürasyonun Optimizasyonu


Oracle veritabanları büyük ölçekli firmalarda genellikle coğrafik olarak farklı bölgelere dağıtılmıştır, böylece Oracle veritabanları uzmanları için veritabanının network bağlantılarından nasıl etkilendiğinin anlaşılması önemli bir görev olmaktadır. Oracle tarafından sağlanan Transparent Network Substrate(TNS), veritabanları arasında dağıtık bağlantılara izin vermektedir.


Dağıtık işlemlerin performansı bu yazıda yer alan bazı değişiklikler ile arttırılabilecektir. Bu değişiklikler sqlnet.ora, tnsnames.ora ve protocol.ora dosyaları içindeki parametreler olacaktır. Bu parametreler, konfigürasyonu ve TCP paketlerinin boyutunu değiştirmek için kullanılır. Bu parametrelerin ayarlanmasının, tüm Oracle işlemlerinin çıktısını geliştirmek için, temel network taşıma katmanı üzerinde çok yoğun bir etkisi vardır. 


Oracle Net, veritabanı uzmanlarına temel network ayarlarını iyileştirebilecek yeterliliğe izin vermez ve network trafiğinin çoğunluğu Oracle yapısı içerisindende iyileştirilmez. Çünkü Oracle Net, OSI modeli içinde network spesifik protocol yığını üstünde bulunur.



Network paketlerinin sıklığı ve büyüklüğü Oracle DBA tarafından kontrol edilir. Oracle, paket sıklığı ve büyüklüğünü değiştirmek için zengin araçlara sahiptir. Network üzerinden paket taşımasının sıklığı ve büyüklüğü, aşağıdaki parameter dosyaları içinde yer alan ayarları kullanılarak etkilenir:

 

·         protocol.ora dosyası – tcp.nodelay parametresi

·         sqlnet.ora server dosyası – automatic_ipc parametresi

·         tnsnames.ora ve listener.ora dosyaları – SDU ve TDU parametreleri

 

 

protocol.ora dosyası içindeki tcp.nodelay parametresi


Oracle Net, varsayılan olarak verinin iletilmesinden önce tampon dolana kadar bekler. Bu yüzden, talepler hedeflerine her zaman anında gönderilmemektedir. Bu olay, çoğu zaman büyük miktarda verilerin bir sondan bir diğerine akıp gittiği zamanda yaygın bir olaydır ve Oracle Net tampon dolana kadar paketleri işlemez. protocol.ora dosyası eklemek ve tampon taşıma gecikmelerini durdurmak için tcp.nodelay değerinin belirtilesi bu sorunun üstesinden gelebilir.


protocol.ora dosyası tüm TCP/IP yapılandırmaları için veri tamponlamasının olmamasını göstermek için belirtilir. Bu parameter, hem istemci hemde sunucu üzerinde kullanılabilir.  protocol.ora içinde bu  parametrenin kullanımı:


  

      tcp.nodelay = yes


Bu paramerenin tanımlanması TCP tamponlamanın es geçilmesine sebep olur, böylece tüm talepler hemen ve anında gönderilir. Ancak unutmamak gerekirki, network trafiği daha küçük ama sık paket işlemesi sebebiyle artar, bu da networkte ağırlaşmaya sebep olur. tcp.nodelay parametresi, sadece TCP zaman aşımı ile karşılaşıldığı zamanlarda kullanılmalıdır. tcp.nodelay parametresinin ayarlanması, veritabanı sunucuları arasında yüksek hacimde trafik olduğunda performansı aşırı oranda geliştirmeye sebep olabilir.

Sqlnet.ora dosyasındaki “automatic_ipc” parametresi

automatic_ipc parametresi network katmanını atlar, böylece veritabanına local bağlantıları hızlandırır. automatic_ipc değeri ON olarak ayalandığında, Oracle Net local veritabanının aynı alias ile belirtilip belirtilmediğini kontrol eder. Eğer aynı alias ile belirtilmişse, bağlantı direkt olarak local IPC bağlantılarına çevrildiğinden network katmanları atlanır. Bu veritabanı sunucuları için kullanışlıdır, ancak Oracle Net istemcileri için kesinlikle gereksizdir.

 


automatic_ipc parametresi sadece Oracle Net bağlantısının local veritabanına yapılması zorunlu olduğu durumlarda kullanılmalıdır. Eğer lokal bağlantılar gerekmezse veya zorunlu değilse, bu parametrenin değerinin OFF olarak ayarlanması gerekir ki  böylece tüm Oracle Net istemcilerinin performansı artar.


tnsnames.ora  dosyası içindeki SDU ve TDU parametreleri


Oturum veri birimi(SDU) ve taşıma zaman birimi(TDU) parametreleri tnsnames.ora ve listener.ora dosyaları içinde yer alır.


Oturum veri birimi(SDU), network üzerinden veriyi göndermeden önce SQL*Net ‘in veriyi tampona almasıdır. SDU, tampon dolu olduğunda veya uygulama veriyi okumaya çalıştığında, veriyi bu tamponda saklanmak üzere gönderir. Büyük miktarda veriler alınırken ve paket büyüklüğü sürekli aynı olduğunda, varsayılan SDU büyüklüğünü genişletmek için alım hızını artırabilir. En uygun SDU büyüklüğü normal paket büyüklüğüne bağlıdır. Bir sniffer ile frame büyüklüğü bulunabilir veya izleme işlemi gönderilen ve alınan paket sayılarını kontrol etmek için en yüksek seviyeye ayarlanabilir, ve fragmente olup olmadıkları görülebilir. Fragmentasyonun miktarını sınırlandırmak için sistem iyileştirilmelidir. Bunun için bir formül olmadığından dolayı farklı büyüklükte tamponlar ile denemeler yapılması gerekmektedir. Varsayılan SDU büyüklüğü 2,048’dir ve 512 ile 32K arasında genişletilebilir.

 


SDU büyüklüğü hem istemci hemde sunucu tarafında ayarlanmalı ve genelde aynı olmak zorundadır. Eğer istemci ve sunucu tarafında farklı büyüklükte SDU büyüklüklerine gereksinim duyulursa, SDU büyüklüğünün iki alt aşağı seviyede olması şeklinde düzenlenebilir.

 


İdeal olarak SDU büyüklüğü MTU büyüklüğünü aşmamalıdır. MTU, kullanılan network yapılandırmasına bağlı olan bir sabit değerdir. Oracle, SDU büyüklüğünün MTU ile aynı değerde ayarlanmasını tavsiye etmektedir. SDU büyüklüğü, normal taşıma frame büyüklüğünün katı olarak ayarlanmalıdır.Ethernet frame büyüklüğünün günümüzde en az 1,024 olmasından itibaren, Ethernet protokolu üzerinden en verimli SDU büyüklüğü 1,024 ün katı olmalıdır, ancak 1,024 toplamının dört katından fazla olmamalıdır.


TDU, verileri birlikte gruplamak için Oracle Net içinde kullanılan varsayılan paket büyüklüğüdür. TDU parametresi ideal olarak SDU parametresinin katı olmalıdır. Hem SDU hemde TDU’un varsayılan değeri 2,048 dir ve maksimum değeri ise 32,767 byte’dır.


SDU ve TDU için geçerli kılavuz noktalar aşağıda yer almaktadır:

 

1.       SDU hiç bir zaman TDU’dan büyük olmamalıdır çünkü her bir paket içinde gerksiz alanın taşınmasıyla network kaynakları gereksiz yere kullanılır.

2.       Eğer kullanıcılar modem hatları üzerinden bağlanıyorsa, SDU ve TDU değerlerinin, modem hatları üzerinden meydana gelen çok sık yeniden göndermeler yüzünden daha küçük değerlere düşürülmesi istenebilir.

3.       Hızlı network bağlantılarında(T1 ve T3),  SDU ve TDU büyüklüğünü MTU ile aynı değere ayarlamak gerekmektedir. Standart ethernet networklerde varsayılan MTU büyüklüğü 1,514 bytes’dır.

4.       Eğer Multi-Threaded Server (MTS) kullanılıyorsa, mts_dispatchers değeri düzgün bir MTU TDU yapılandırmasıyla ayarlanmalıdır.

 

SDU ve  TDU ayarları hostlar arasındaki bağlantı hızı direkt fonksiyonudur. Hızlı T1 hatlarda SDU=MTU=TDU şeklinde ayarlama yapılmalıdır.

 


Aşağıdaki örnek, 4,202 bytes MTU değerine sahip T2 networkü için yapılan parametre değerleridir..


tnsnames.ora  dosyası:

ARDA =
  (DESCRIPTION =
    (SDU=4202)
    (TDU=4202)
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = LINUX1)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SID = ARDA)
      (SERVER=DEDICATED)
    )
  )
 


  listener.ora dosyası:

 


   SID_LIST_LISTENER =     
      (SID_LIST =
        (SID_DESC =
          (SDU = 4202)
          (TDU = 4202)
          (SID_NAME = ARDA)
          (GLOBAL_DBNAME = ARDA)        
        )     
      )


SDU büyüklüğü aşağıdaki durumlarda yeniden düzenlenmelidir:

 

·         Sunucudan geri gelen veriler farklı paketlere fragmente olduğunda.

·         Uzun gecikmelerin olduğu WAN bağlantıları içinde bulunulduğunda.

·         Paket büyüklüğü devamlı aynı olduğunda.

·         Büyük miktarlarda veri döndüğünde.

·         SQL*Net tabanlı bekleme olayları içinde “more data from/to” tipi bekleme olaylarının çok büyük ortalama oranlarıyla sık sık meydana geldiği gözlemlendiğinde.

 


SDU büyüklüğü aşağıdaki durumlarda değiştirilmemelidir:

 

·         Uygulama gecikmelerini yakalamak için iyileştirilmesi gereken durumlarda.

·         Uygulama sunucusunda meydana gelen bu gecikmeler, aslında “SQL*Net message from client” bekleme olayının büyük ortalama oranlarında sık sık meydana gelmesi ile tespit edilebilmektedir. Bu durumda, Oracle sunucusundan uygulama sunucusuna gönderilen veri paketleri aynı hızda uygulama sunucusundan geri alınamamakta ve bu bekleme olayı meydana gelmektedir.

·         Data işleme etkisinin önemsiz ve göz ardı edilebilir olduğu yüksek hızda networka sahip olunduğu durumlarda

·         İstemci taleplerinin sunucudan küçük miktarlarda veri döndürdüğü durumda

 


Aşağıdaki eylemlerden birisi uygulanmadığı takdirde, Oracle veritabanı instance!ları otomatik olarak listener.ora dosyasına kayıt eder:

 

·         Otomatik servis kaydının devre dışı olduğu durumda. Bunu yapmak için local_listener adlı init.ora parametresinde, listener.ora dosyasında tanımlananTCP portundan başka bir portun ayarlanması gerekmektedir.

·         MTS uygulandığında ve aşağıdaki örnekteki gibi init.ora dosyasındaki mts_dispatchers parametresi tanımlanmadığında:

 


MTS_DISPATCHERS=”(DESCRIPTION=(SDU=8192)(TDU=8192)
ADDRESS=(PARTIAL=TRUE)(PROTOCOL=TCP)(HOST=linux1)))
(DISPATCHERS=1)”

 

·         tnsnames.ora dosyasının connect_data bölümünde service_name=global_dbname kullanıldığında. Bu ayar, global_dbname kullanımının desteklenmediği TAF kullanımını devredışı bırakacaktr.

 

Listener yük dengelemesinin kullanılması

Listener yük dengelemesi, sunucuya pek çok bağlantı talebinin olduğu durumlarda kullanışlıdır. Bu talepleri karşılamak için birden fazla listenera sahip olarak, tekil bir listener üzerindeki sorumluluk azaltılır ve bağlantı hızı artar. Listener yük dengelemesi ayrıca replike sunucular için dinleme yapan birçok listener olan çoklu sunucu ortamında oldukça kullanışlıdır.

 


Problemin tespiti


Aşağıdaki sorgu, sunucu veya istemci için ortalama bekleme süresinin, ayrı ayrı sunucu veya istemciden bir mesaj için bekleme süresine bağlı kaydının, Oracle perspektifinden, network performansı belirleme metodunu göstermektedir.

 


select event, average_wait
from v$session_event

where event in (‘SQL*Net message from client’,’SQL*Net message to client’, ‘SQL*Net more data to client’, ‘SQL*Net more data from client’)  and average_wait > 0;

Bunun yanında STATPACK raporlarından geçmiş ile ilgili aynı veriye erişmek için aşağıdaki sorgu oldukça kullanışlıdır ve Oracle 9i ve Oracle 10g veritabanlarında sorunsuzca çalışmaktadır.

 

select

   to_char(snap_time,’yyyy-mm-dd HH24′)  mydate,

   e.event,

   e.total_waits – nvl(b.total_waits,0)  waits,

   ((e.time_waited_micro – nvl(b.time_waited_micro,0))/100) /

   nvl((e.total_waits – nvl(b.total_waits,0)),.01)  avg_wait_secs

from

   stats$system_event b,

   stats$system_event e,

   stats$snapshot     sn

where

   e.snap_id = sn.snap_id

and

   b.snap_id = (e.snap_id-1)

and

   b.event = e.event

and

   e.event like ‘SQL*Net%’

and

   (e.total_waits – b.total_waits )> 100

and

   (e.time_waited_micro – b.time_waited_micro) > 100

order by 1 desc;

 

 

Aşağıdaki sorgu istemci ve sunucu için ortalama bekleme süresini ve fiilen transfer edilen bytes’ları göstermektedir.


select v$sesstat.sid, substr(v$session_event.event,1,30) “Event”,v$SESSION_EVENT.AVERAGE_WAIT “Avg Wait”,

v$sesstat.value “Bytes”,substr(v$session.program,1,20) “Program”
from v$session_event,v$session_wait, v$sesstat, v$session,v$statname
where v$session_wait.event in (‘SQL*Net message from client’,’SQL*Net message to client’,’SQL*Net more data to client’,’SQL*Net message from dblink’)
and v$session_wait.event=v$session_event.event
and v$session_wait.sid = v$sesstat.sid
and v$session_wait.sid = v$session_event.sid
and v$statname.statistic#=v$sesstat.statistic#
and v$statname.name like ‘bytes%’
and v$sesstat.value > 0
and v$session.sid = v$sesstat.sid
and V$SESSION_EVENT.AVERAGE_WAIT > 100;


       SID Event                      Avg Wait  Bytes  Program
———- ———————— ———- ——- ———–
        18 SQL*Net message from cli    1458         19 MVXLAWSN.exe
        18 SQL*Net message from cli    1458        150 MVXLAWSN.exe
        18 SQL*Net message from cli    1458          4 MVXLAWSN.exe
        18 SQL*Net message from cli    1458      11122 MVXLAWSN.exe
        18 SQL*Net message from cli    1458     274712 MVXLAWSN.exe
        18 SQL*Net message from cli    1458     143896 MVXLAWSN.exe
        18 SQL*Net message from cli    1458 1114450960 MVXLAWSN.exe
        18 SQL*Net message from cli    1458 1114450960 MVXLAWSN.exe
        18 SQL*Net message from cli    1458         76 MVXLAWSN.exe
        18 SQL*Net message from cli    1458         76 MVXLAWSN.exe
        14 SQL*Net message from cli    5510         31 service.exe
        14 SQL*Net message from cli    5510         77 service.exe
        14 SQL*Net message from cli    5510      22912 service.exe
        14 SQL*Net message from cli    5510     145648 service.exe
        14 SQL*Net message from cli    5510        111 service.exe
        14 SQL*Net message from cli    5510         77 service.exe


Oracle tarafından network iyileştirmesindeki tüm mesele networkun münkün olduğunca küçük miktarlarda kullanılmasıdır. Muhtemelen en önemli faktör SQL komutlarının işlemler içinde gruplandırılması olacaktır. Örneğin; 10 satır alıp getirilecekse(fetch), bu on satır için tek bir talebin gönderilmesi, her bir satır için on talep gönderilmesinden daha verimli ve efektif olacaktır. Networkun veritabanı sunucusundan veya istemci makineden daha yavaş olmasından itibaren, bu yaklaşım önemlidir.

 

Bunun yanında STATSPACK snapshotları arasındaki değişimlerin(delta değerlerinin) izlenmeside pek çok SQL*Net tabanlı bekleme olayının iyileştirilmesinde genel reime bütün olarak bakabilmek noktasında faydalı olmaktadır. Aşağıdaki örnekte 44050 ve 44125 numaralı snapshotlar arasındaki SQL*Net tabanlı bekleme olaylarının değişimleri yer almaktadır. Örnekte sıkıntı yaşanan alanın “SQL*Net message from client” bekleme olayı olduğu yüksek delta değerlerinden anlaşılmaktadır. bu noktada, uygulama sunucusu veritabanı sunucusundan aldığı veri paketlerini aynı hızda işleyememekte ve bu noktada bu uygulama sunucusunda paket cevaplarında gecikmeler meydana gelmektedir.

 

SELECT s1.snap_time,

w1.event,

s1.snap_id,

w1.total_waits,

LAG(w1.total_waits)

OVER (ORDER BY w1.total_waits) prev_val,

w1.total_waits – LAG(w1.total_waits)

OVER (ORDER BY w1.total_waits) delta_val

FROM stats$snapshot s1,

stats$system_event w1

WHERE s1.snap_id BETWEEN 44100 AND 44125

AND s1.snap_id = w1.snap_id

AND w1.event in (‘SQL*Net message from client’,’SQL*Net message from dblink’, ‘SQL*Net more data from client’)

ORDER BY w1.event, s1.snap_id;

 

SNAP_TIME    EVENT                        SNAP_ID   TOTAL_WAITS    PREV_VAL   DELTA_VAL

———-   ————————–  ——-   ———–    ——–    ———-

 

19-July-2011 SQL*Net message from client        44110    21053209911      61434967    20991774944

19-July-2011 SQL*Net message from client        44115    21058681336      21053209911     5471425

19-July-2011 SQL*Net message from client        44116    21062289324      21058681336     3607988

19-July-2011 SQL*Net message from client        44125    21068495873      21062289324     6206549

19-July-2011 SQL*Net message from dblink       44110    61434121                           

19-July-2011 SQL*Net message from dblink       44115    61434967             61434121            846

19-July-2011 SQL*Net message from dblink       44116    61434967             61434967              0

19-July-2011 SQL*Net message from dblink       44125    61434967             61434967              0

 

 

Ayrıca, geçici olarak yüksek seviye izlemeyi ayarlamak için sqlnet.ora dosyasındada düzenleme yapılmalıdır, böylece o an kullanımda olan ne kadar “pipeline” büyüklüklerinin olduğu görülebilir. Aşağıda bununla ilgili düzenlemenin olduğu örnek yer almaktadır:

 

                trace_level_client=16
                trace_directory_client=/u01/app/oracle/admin/network
                trace_file_client=client.trc
                trace_unique_client = true

                trace_level_server=16
                trace_directory_server=/u01/app/oracle/admin/network
                trace_file_server=server.trc

 

Bu, basit bir SQL*Plus oturumu oluşturup kullandığından dolayı  uçsuz bucaksız miktarlarda verinin izleme dosyalarına üretilmesine sebep verir. Bir çift izleme dosyası üzerinden tarama yapılırsa, açık bir IPC bağlantısıyla ve multi-threaded sunucunun çalışmadığı izleme dosyasından aşağıdaki gibi satırlar bulunacaktır.

 

                nsprecv: 187 bytes from transport
                nsprecv: tlen=187, plen=187, type=1
                nsprecv:packet dump
                nsprecv:00 BB 00 00 01 00 00 00  |……..|
                nsprecv:01 35 01 2C 08 01 7F 80  |.5.,….|
                nsprecv:7F FF 73 08 00 00 00 01  |..s…..|
                nsprecv:00 89 00 32 00 00 08 00  |…2….|
                nsprecv:09 09 00 00 00 00 00 00  |……..|
                nsprecv:00 00 00 00 00 00 00 00  |……..|
                nsprecv:00 00 28 44 45 53 43 52  |..(DESCR|
                nsprecv:49 50 54 49 4F 4E 3D 28  |IPTION=(|
                nsprecv:73 64 75 3D 33 32 36 34  |sdu=3264|
                nsprecv:30 29 28 43 4F 4E 4E 45  |0)(CONNE|
                nsprecv:43 54 5F 44 41 54 41 3D  |CT_DATA=|
                nsprecv:28 53 49 44 3D 44 37 33  |(SID=ARD|
                nsprecv:34 29 28 43 49 44 3D 28  |A)(CID=(|
                nsprecv:50 52 4F 47 52 41 4D 3D  |PROGRAM=|
                nsprecv:29 28 48 4F 53 54 3D 68  |)(HOST=l|
                nsprecv:70 37 31 32 29 28 55 53  |inux1(US|
                nsprecv:45 52 3D 6A 70 6C 29 29  |ER=hr)))|
                nsprecv:29 28 41 44 44 52 45 53  |(ADDRESS|
                nsprecv:53 5F 4C 49 53 54 3D 28  |LIST=(AD|
                nsprecv:41 44 44 52 45 53 53 3D  |DRESS=(P|
                nsprecv:28 50 52 4F 54 4F 43 4F  |ROTOCOL=|
                nsprecv:4C 3D 49 50 43 29 28 4B  |IPC)(KEY|
                nsprecv:45 59 3D 44 37 33 34 29  |=D734)))|
                nsprecv:29 29 29 00 00 00 00 00  |)…….|
                nsprecv: normal exit
                nscon: got NSPTCN packet
                nsconneg: entry
                nsconneg: vsn=309, lov=300, opt=0x801, sdu=32640, tdu=32767,  

      ntc=0x7308
                nsconneg: vsn=309, gbl=0x801, sdu=32640, tdu=32767
                nsconneg: normal exit

 

Bu sunucu ve istemci arasında kullanılacak SDU yu belirlemek için yapılan düzenlemenin bir parçasıdır. İlk bölümde istemci tarafından geçilen bağlantı verisi görülür, ikinci bölümdeki satırlarda ise ne yapılacağı ve nasıl bir düzenlemeye ulaşıldığı ile ilgili sunucu raporları yer almaktadır. Buradaki nsconneg,Network Substrate CONnection NEGotiation(Ağ Yüzey Bağlantı Düzenlemesi) anlamına gelir.

 


Varsayılan kurulumda, SDU muhtemelen 32,640 yerine 2,048 olacaktır.Ayrıca, iki nsconneg satırının SDU için iki farklı değeri gösterdiği görülmektedir, istemci ve sunucu tarafında ne yapacakları hakkında bilgi. Sonuç bölümü ise her iki teklifin düşürülmesidir.

 


Onaylama:

SQL Net izleme dosyasından SDU büyüklüğünün beklenen değerde ayarlanmasının görülmesinin yanında, “pipeline” büyüklüklerini büyülten oturumları belirlemek için diğer bir alternatif ise Unix ps komutudur

 

 

                ps -ef | grep oracleSID


                oracle 2324    1  0 19:49:40 ?     0:01 oracleD734  

     (DESCRIPTION=(LOCAL=NO)(SDU=32640))
                oracle 2327 2318 12 19:50:09 pts/2 0:00 grep oracleD

 

Network ayarlarının düzenlenmesi

1.       Network adaptor ayarlarının değiştirilmesi

 

 

Network adaptörlerinin hızını ve ayarlarını kontrol etmek için ethtool komutu kullanılabilir. Aşağıda eth0 network arayüzünün ayarları konrol edilir:

 

# ethtool eth0

 

Hızı 1000 full duplex olarak değiştirmek için;

 

# ethtool -s eth0 speed 1000 duplex full autoneg off

 

 

Hız değişikliğini eth0 için kalıcı olarak ayarlamak  için /etc/sysconfig/network-scripts/ifcfg-eth0 dosyasına ETHTOOL_OPT değişkeninin eklenmesi gerekmektedir.Bu şekilde network servisinin her başlatılmasında network scriptleri içerisine bu ortam değişkeni eklenecektir.

 

ETHTOOL_OPTS=”speed 1000 duplex full autoneg off”

 

2.       Kernel ayarlarının değiştirilmesi

 

Oracle instanceler arasında cache fusion tampon transferleri gibi süreçlerarası bağlantılar için varsayılan olarak UDP protokolünü kullanmaktadır. Ancak, Oracle 10g itibariyle network ayarları standalone veritabanları içinde ayarlanmalıdır.


Oracle varsayılan ve maksimum gönderme tampon büyüklüğünü (SO_SNDBUF soket seçeneği) ve alım tampon büyüklüğünü (SO_RCVBUF soket seçeneği) 256 KB olarak ayarlanmasını tavsiye etmektedir. Okuma esnasında uygulama için alınan veriyi tutmak için TCP ve UDP ile alım tamponları kullanılır. Bu tampon dışa taşmaz, çünkü gönderim partisinin bu veriyi tampon boyut penceresi ötesinde göndermesine izin verilmez. Bu demektir ki, datagramlar alım tamponu içine sığmazsa iptal edilecektir.Bu da göndericinin alıcıyı ezmesine sebep verecektir.


Varsayılan ve maksimum pencere büyüklükleri sistemi yeniden başlatmaya gerek kalmadan proc dosyası içinden değiştirilebilir:

 

# sysctl -w net.core.rmem_default=262144  # Soket alım tamponunun bytes değerinden varsayılan değeri

# sysctl -w net.core.wmem_default=262144  # Soket gönderim tamponunun bytes değerinden varsayılan değeri

# sysctl -w net.core.rmem_max=262144      # SO_RCVBUF soket seçeneğini kullanarak maksimum soket alım tampon büyüklüğü ayarlanabilir

# sysctl -w net.core.wmem_max=262144      # SO_RCVBUF soket seçeneğini kullanarak maksimum soket gönderim tampon büyüklüğü ayarlanabilir

 

Değişikliklerin bir sonraki sistem açılışlarında da kalıcı olmasını sağlamak için aşağıdaki satırlar /etc/sysctl.conf dosyası içine eklenir:

 

net.core.rmem_default=262144

net.core.wmem_default=262144

net.core.rmem_max=262144

net.core.wmem_max=262144

 

RAC platformunda failover performasını geliştirmek için aşağıdaki IP kernel parametrelerini değiştirmeyi iyice gözönünde bulundurmak gerekir. Bu parametrelerin optimal ayarları ile ilgili bilgi almak için Metalink Note:249213.1 ve Note:265194.1 bakabilirsiniz.

 

net.ipv4.tcp_keepalive_time

net.ipv4.tcp_keepalive_intvl

net.ipv4.tcp_retries2

net.ipv4.tcp_syn_retries

 

Red Hat Linux sistemlerde 9i ve 10g için TCP ve UDP trafiğinde kullanılmasına izin verilen port aralığı çok kısıtlıdır. Bu ayarlar aşağıdaki gibi değiştirilerek bu sıkıntının önüne geçilebilir.

 

# sysctl -w net.ipv4.ip_local_port_range=”1024 65000″

 

Bu değişikliği kalıcı olarak ayarlamak için aşağıdaki satır /etc/sysctl.conf dosyası içine eklenmelidir.

 

net.ipv4.ip_local_port_range=1024 65000

 

3.       e1000 NIC ler için akış kontrolü

 

e1000 NIC ler 2.6 kernel sistemlerde(mesela RHEL 4) akış kontrol etkin değildir. Eğer ağır bir trafik varsa, bu durumda RAC interconnect bağlantılarda blok kayıpları olabilir(bakınız Metalink Bug:5058952).


e1000 NIC ler için alım akış kontrolünü etkinleştirmek için aşağıdaki satır /etc/modprobe.conf dosyası içerisine eklenir:

 

options e1000 FlowControl=1

 

 

Umarım faydalı bir makale olmuştur. Bir sonraki makalemde görüşmek dileği ile esen kalın.

Exit mobile version