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.
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:
- 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.
- 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.
- 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.
- 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ı:
(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)"
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. RAC ortamında yük dengeleme için şu yazımı inceleyebilirsiniz.
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 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))/1000000) /
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ı gerçek zamanlı olarak oturum içinden 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.sidand 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.sidand V$SESSION_EVENT.AVERAGE_WAIT > 100;
SID Event Avg Wait Bytes Program
---------- ------------------------ ---------- ------- -----------
18 SQL*Net message from cli 1458 19 MVXLAWSON.exe
18 SQL*Net message from cli 1458 150 MVXLAWSON.exe
18 SQL*Net message from cli 1458 4 MVXLAWSON.exe
18 SQL*Net message from cli 1458 11122 MVXLAWSON.exe
18 SQL*Net message from cli 1458 274712 MVXLAWSON.exe
18 SQL*Net message from cli 1458 143896 MVXLAWSON.exe
18 SQL*Net message from cli 1458 1114450960 MVXLAWSON.exe
18 SQL*Net message from cli 1458 1114450960 MVXLAWSON.exe
18 SQL*Net message from cli 1458 76 MVXLAWSON.exe
18 SQL*Net message from cli 1458 76 MVXLAWSON.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 resime 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
ROUND((.snap_id,w1.time_waited_micro/1000000/total_waits),4) "Avg_wait_sec",
LAG OVER(ROUND((w1.time_waited_micro/1000000/total_waits),4)) (ORDER BY ROUND((w1.time_waited_micro/1000000/total_waits),4)) prev_value,
ROUND OVER((w1.time_waited_micro/1000000/total_waits),4) - LAG(ROUND((w1.time_waited_micro/1000000/total_waits),4)) (ORDER BY ROUND((w1.time_waited_micro/1000000/total_waits),4)) delta_value
FROM stats$snapshot s1,stats$system_event w1
WHERE s1.snap_id BETWEEN 44050 AND 44125
AND s1.snap_id = w1.snap_id
AND w1.event like 'SQL%'
ORDERBY 1
ROUND((.snap_id,w1.time_waited_micro/1000000/total_waits),4) "Avg_wait_sec",
LAG OVER(ROUND((w1.time_waited_micro/1000000/total_waits),4)) (ORDER BY ROUND((w1.time_waited_micro/1000000/total_waits),4)) prev_value,
ROUND OVER((w1.time_waited_micro/1000000/total_waits),4) - LAG(ROUND((w1.time_waited_micro/1000000/total_waits),4)) (ORDER BY ROUND((w1.time_waited_micro/1000000/total_waits),4)) delta_value
FROM stats$snapshot s1,stats$system_event w1
WHERE s1.snap_id BETWEEN 44050 AND 44125
AND s1.snap_id = w1.snap_id
AND w1.event like 'SQL%'
ORDERBY 1
SNAP_TIME EVENT SNAP_ID Avg_wait_sec PREV_VALUE DELTA_VALUE
18-July-2011 SQL*Net message to dblink 44055 0,0005
18-July-2011 SQL*Net message to client 44055 0,0007 0,0005 0,0002
18-July-2011 SQL*Net more data to client 44055 0,0384 0,0007 0,0377
18-July-2011 SQL*Net more data to dblink 44055 0,0534 0,051 0,0024
18-July-2011 SQL*Net break/reset to client 44055 0,2145 0,2144 0,0001
18-July-2011 SQL*Net more data from dblink 44055 25,9425 25,9205 0,022
18-July-2011 SQL*Net message from client 44055 81,9232 26,0809 55,8423
18-July-2011 SQL*Net message from dblink 44055 4,0499 4,038 0,0119
18-July-2011 SQL*Net break/reset to dblink 44055 0,1175 0,0534 0,0641
18-July-2011 SQL*Net more data from client 44055 0,051 0,0509 0,0001
...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_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
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,
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
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
oracle 2327 2318 12 19:50:09 pts/2 0:00 grep oracleD
- 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"
- 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:
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 ayarların kullanımı ilgili detaylar için şu yazımı inceleyebilirsiniz. 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
- 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:
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
Kayıtlar
0 yorum:
Yorum Gönder