From: Serdar KÖYLÜ (serdarkoylu@fisek.com.tr)
Date: Thu 04 Jul 2002 - 13:55:41 EEST
Selamlar..
On Thu, 4 Jul 2002 01:23:42 +0300
Orhan <drgunalan@gamebox.net> wrote:
>
>
>
> Selam
>
> On 04 Jul 2002 01:02:48 +0300
> Murat Koc <murat.koc@frontsite.de> wrote:
>
> >
> >Selam,
>
> >SWAPPING
> >--------
> >
> >Nedir bu swapping? amaci nedir diye bakacak olursak, aslinda temel
> >olarak iki amaci var bunlardan birincisi bir process in kullanabilecegi
> >adress space i arttirmak ikincisi ise process leri yuklemek icin dinamik
> >RAM(*) miktarini arttirmak.
Genel olarak bakildiginda SWAP'in amaci bu.Biraz daha genellestirirsek, SWAP, Virtual Machine sisteminde, process yukunun artmasi ile VM isteklerinin fiziksel RAM ile karsilanamaz duruma dusmesinde kurtarici olarak kullanilir. Bir process'in dinamik olarak kullandigi RAM (DATA segment) gibi, process'in kendiside (TEXT segment) SWAP'a konabilir. Bu dogru tarif degil tam olarak ama, sunu anlamak icin faydali olur. Bazi isletim sistemleri uzun sure Sleep durumunda kalan uygulamalari otomatikman SWAP'a koyabilir. SWAP'ten bir process'in tekrar yuklenmesi, process'in yeniden baslatilmasindan kat kat hizlidir. Bu nedenle bilhassa yuksek yuke gore dizayn edilmis sistemlerde, process'ler yuke binmeden baslatilir, bir sure sonra OS bunlari SWAP'e koyar. Ihtiyac oldugunda bunlari yuklemek daha kolay olur. Linux bu konuda biraz zayiftir. Fakat Solaris ve AIX bu isi cok iyi becerirler. Fakat Linux copy-and-execute yapabilir, yani calisan bir sureci hafizadan kopyalayarak yeni bir surec olusturabilir. Boylece bu sorun da
ha etkili olarak cozulmus olur.
SWAP isinde en can alici nokta, Murat'in belirttigi swap-out kismidir. 386 Mimarisinde bellek Virtual86 modunda kullanilir. Bu modda, bellek 4K sayfalar halinde tutulur ve swap-out kolaylasir (nispeten). MMU sagolsun.. Ama, bir process'in user level thread modeli, kernel tarafindan bilinmeyebilir. Eger, pthread gibi bir user-level thread sistemi kullaniyorsaniz, thread onceliklerinizi belirleyemeden onlarin SWAP out'a fazla dusmesi mumkun olur, bu da performans kaybina yol acar. Nasil ?
Bir user-space thread, kernel tarafindan process'in bir parcasi gibi gorunur. Kernel threadlari ise kernel tarafindan bilinir ve daha iyi SWAP ve process yonetimi saglar. Demekki, pthread "POSIX thread" kullanmak swap mevcut olan bir sistemde cok verimli olmaz :(( Ama penguenciler uyaniktir. Bakin ne yapmislar: POSIX threadlarini implement eden pthread library'sin libc'ye gommusler ve clone() ile bunlarin bir kernel-thread olarak calismasini saglamislar. Ama user space sync-thread (fiber) destegide yokolmus otomatikman. Gerci buyuk bir kayip degil.
Thread ile SWAP arasindaki baglanti, thread'in scheduling que'de sirasi gelince isleniyor olmasindan kaynaklanir. Eger sirasi gelen thread swap'ta ise veya bos bellek yoksa, SWAP islevi baslar. Bu da kernelin tek bir thread (one-to-many) olarak gordugu bir process'i SWAP'a gereksiz yere atmasiyla sonuclanabilir.
Peki bunlari neden yaziyoruz ? SWAP yonetimi, boy pos tespiti vs. sistemin kullandigi thread modeliyle son derece alakalidir. Bu tur bir thread yonetimi, SWAP yonetiminide kolaylastirir. Demekki, SWAP'a ihtiyaciniz varsa, uygulamalarin thread modelini cok fazla dusunmeden bir SWAP modeli cikarabilirsiniz.
ORACLE'in UNIX sistemlerinde "daha cok process isletebilirsiniz, bu nedenle daha fazla lisans odemelisiniz" yaklasiminin temelinde bu thread/swap yonetimi yatar. Eger bu konuyu (sanirim ilerde uzun bir mail seminer cikaririz) iyi dusunerek process olusturursaniz, sistemin verimi kat kat artar.
> Verdiğiniz bilgiler için teşekkürler Yine bu konuda bir şey sormak isterim Ayrılan swap alanı genelde ram'in 2 katı olması şeklinde öneriliyor. Daha fazla ayırmanın hiç bir şekilde ek getirisi olamazmı yoksa tamamen gereksizmi ?
Bu degerlendirme tamamen sistemin ve process'lerin thread yapisina bagli. Eski UNIX'lerde bu kernel threadlari cok kullanilirdi. Dahasi multi-thread yerine multi process tercih edilirdi. Bu tur bir sistemde boyle bir formul cogu zaman gecerli olur. Windows 3 ile birlikte ciddi olarak SWAP konusu Windows'a tasindi. Windows thread modeli VMS'ten esinlendigi icin, daha cok sync user-space threadlere (fiber) yatkindi. Bilhassa RAM'in yetersiz olmasi nedeniyle Win 3 serisinde SWAP buyuklugu fiziksel RAM'in iki kati olarak secildi. Fakat ilerleyen donemde bu degerin bu tur thread modeli icin anlamsiz oldugu goruldu ve swap space'in dinamik olarak artirilmasi/azaltilmasi gundeme geldi. Elbette buna paralel olarak, sistem yuku artti ve stabilite performans kayiplari basladi. UNIX'ler ise, biraz daha sansliydilar. Genelde para harcamaktan cekinmeyen insanlar tarafindan kullanildilar. Onlarda gani gani RAM ile makineler aldilar. SWAP buyuklugunu vs. tespit etmek cok kritik olmadi. Yok demeyecek kadar bir SWAP bile ise
yairyordu. Diger yandan library kodlarinin paylasilabilir olmasi gibi ozellikler bellek kullanimini azaltiyordu zaten. Fakat, Linux'la birlikte cok sey degisti. Artik herkes onundeki 386 icin Linux isteyebiliyordu, ve elinde cok fazla parasi yoktu. RAM fiyatlari ise o donemde hem can yakiyordu, hemde makinelere oyle bolca RAM takamiyordunuz. 386SX'lerin 24 Adres hatti vardir ve 16M RAM Takabilirsiniz en fazla. SWAP gene onemli olmaya basladi. Bir masaustu makinesinde ne zaman ne kadar RAM ihtiyaci olacagini kestirmek guctur. Fakat, RAM ile harddisk arasindaki hiz farkinin binlerce kat oldugu dusunulurse, belli bir noktadan sonra harddisk erisimiyle kullanilan RAM in hiz olarak yetersiz kalacagini tahmin edebilirsiniz. Bu nedenle guncel sistemlerde SWAP alani hesabi biraz daha komplike dusunmek istiyor.
Oncelikle sisteminizin min, averaj, maksimum ve peak fiziksel RAM ihtiyaci degerlerini bilmelisiniz. Tipik olarak konsolun calismasi icin 4 MB kadar RAM gerekiyor. X11 ise, 16 MB civarinda RAM ihtiyaci gosteriyor. Uzerine KDE2 koyarsaniz bu deger 24 MB'a ulasiyor. Bunlar minimum degerler. Diyelimki OpenOffice kullaniyorsaniz, 32 MB kadar RAM ihtiyaci var. X11 + KDE (24) ve OOo (32) = 56 MB Min RAM istiyor. Dosya acarken veya yaninda bir browser acarsaniz bu deger'e bir kac MB daha ekleniyor. Demekki OpenOffice kullaancak bir makinenin Min degeri 56 MB. Averaj degeri ise 64 MB. Fakat siz o esnada baska bir seyler daha calistirirsiniz, sylpheed, saat, wget vs. bunlarla sisteminizin maksimum degerine ulasirsiniz. Kabaca bu 80 - 90 MB civarinda olur. Bunada sistemin Maximum ihtiyaci deriz. Size en ideali bu kadar RAM olmasidir. Fakat bazen, find vs. yaparken, OpenOffice ile resim islerken diger yandan mail client calisirken Flash vs. yukleyen bir browser acarsiniz. Sistem bir an icin cok fazla bellek ihtiyaci du
yar. Buna peak deger denir. Bunu tespit etmek guctur. Fakat bir masaustu sistem icin peak degeri 256 MB olabilir kabaca. Simdi bakariz elimizde ne kadar RAM var ? Diyelim ki 64 MB var. Peak Deger 256 MB olduguna gore bize en azindan 164 MB SWAP gerekir. Fakat, averaj degerimiz 64 MB. Buda her zaman bir seylerin SWAP'ta olacagi anlamina gelir. Tavsiye edecegimiz, Averaj degeri ile MAX degerinin ortalamasi kadar fiziksel RAM olmasidir. Bu durumda sizin 80 MB RAM sahibi olmaniz tavsiye edilirken, bunun yaninda Peak degerini saglamak uzere 256 - 80 = 176 MB kadar bir SWAP alani ihtiyaciniz olur. Sistemin peak degerine cok ender ulasacagini dusunurseniz bu mantikli bir degerdir ve farkediyorsaniz, 80 x 2'ye yakindir. Fakat, 32 MB RAM'iniz varsa, Peak ihtiyacinizi karsilamak icin koyacaginiz 150 MB sizin icin cok fazladir. Bu ornekte gorduyseniz, size minimum 56 MB RAM gerekli. Bunu SWAP ile kapatmaya calisirsaniz, performans katlanamayacaginiz kadar dusecektir. Sizin en azindan min degeri kadar fiziksel RAM sahib
i olmaniz gerekirken, Averaj degeri ile MAX'in ortalamasi kadar fiziksel RAM'inizin bulunmasi faydali olacaktir. Bu arada, peak degerini saglamak icin SWAP kullanabilirsiniz. Cunku peak degeri, cok ender olarak ulasilan ve hemen ardindan tekrar eski seviyelere donen fiziksel RAM ihtiyacidir.
Bir server sisteminde ise calisacak process'in bellek ihtiyaclari dusunulur. Apache+PHP baglanti basina ortalama 1 MB Ram ihtiyacina sahiptir. MySQL tablo buyuklugune ve sorgu yapisina bagli olarak belli bir buffer ihtiyaci gosterir. Diyelimki, MySQL ile 1 GB Veritabani kullaniyorsunuz. Oncelikle size bunun 1/8'i kadar (bu deger tartisilabilir) MySQL bufferi lazim. 128 MB RAM onun icin. Servere bir anda kac kullanici baglaniyor ? Ortalama 50 ise, bir 50 MB oradan. Etti 178 MB. Disk buyuklugunun MB'i basina 4096 bayt disk cache dusunursek (Mantikli bir degerdir), 1GB veritabani, 1GB log, executables, temp dizinler vs. icin olusturulacak cache, 2048 * 4096 = 8 MB edecektir. Etti 186 MB. Sistemin kendi arabellekleri ve kendi ihtiyaclari icin bir 32 MB eklerseniz, 218 MB Min RAM ihtiyaciniz var demektir. Bu serverin 256 MB Fiziksel RAM tasimasi gerekir. Diyelimki bir anda bu servere maksimum 300 kisi baglaniyor. Bu durumda 50 MB ayirdigimiz deger 300 MB olacaktir, tepe degeri 468 MB olacaktir. Iste SWAP ile bir
256 MB daha ekleriz ve bu tepe degerinin kullanimda olmasini saglariz. Tipik browserler, bir anda 4-5 baglanti ile serverde yeni processler acarlar ve 50 kullanici icin gercek process yuku 200'e kolayca yukselir. Bunlari da gozonune alirsaniz, 512 MB RAM ile 50 Kullaniciya hizmet verirsiniz rahatca. Peak degeri karsilayacak kadar bir swap yeterli olur. Fakat, iyi bir SCSI HDD bile, 256 MB veriyi trnasfer etmek icin bir hayli bogusacaktir. Aklinizin bir kenarinda tutun. SWAP'a yuklenmek sadece, ender olusan peak durumlarinda kabul edilebilir. Peak degerin serverin averaj yukune yakin oldugu intranet serverler, file serverler vs. icin fiziksel RAM'in peak degerini karsilayabilir olmasi gerekebilir. Cunku 256 MB buyuk bir rakam ve Harddiskten transfer cok yavas olabilir.
Serverler icin hesap yapilirken meshur "que" teorisine basvurulur. Boylece sistemin buffer ihtiyaci, cache ihtiyaci, RAM ihtiyaci, CPU ihtiyaci, CPU Cache ihtiyaci kolayca belirlenir. Fakat, bu hesabi yapmak yukardaki kabaca hesaplari yapmaktan cok daha maliyetlidir. Kabaca 50 kullanici 50 MB RAM, 32 MB buffer, 128 MB'ta MySQL icin (50 kullaniciya 2'ser MB veri alani) dersek, 256 MB RAM yeterli olur. Ne olur ne olmaz gibisinden bir 128 MB SWAP kenarda bulunabilir. Dahasi 384 MB RAM (=60$ + KDV) takip, "bye bye SWAP" demek daha mantikli olur.
En iyi SWAP secimi "queue theorem" ile soyle boyle yapilir ama, muhendislik okuyanlar sanirim ders olarak gormuslerdir bu kuyruk teorisini, nasil karmasik bir sey oldugunu bilirler. Genelgecer olarak su kistaslari alabiliriz (bence, her tur elestiriye ve karsi fikre acigim):
Masaustu sistemler icin,
64 MB'a kadar = RAM x 2 SWAP Space..
128 MB'a kadar = toplami 192 MB edecek kadar bir SWAP space.
256 MB'a kadar = toplami 256 MB edecek kadar bir SWAP space
256 MB ve ustu = No Swap Space :))
Serverler icin:
128 MB'a kadar = RAM x 2 SWAP Space
256 MB'a kadar = 128 MB SWAP Space
512 MB'a kadar = Toplami 512 MB yapacak SWAP space.
2 GB'a kadar = No Swap Space..
2 GB ve ustu = SWAP, RAM vs. size yetmez. Acilen bir Cluster olusturun. Yada NUMA-Q vs. kullanan high-end sistemlere terfi edin.
Evet, RAM gibi CPU'larin, veriyollarinin vs. limitleri vardir. RAM'i dusundugunuz kadar onlarida dusunun. CPU basina RAM miktarinin 256'MB'i asmamasini saglayin. Bilhassa Buffer istegi yogun olmayan, CPU yuku yuksek olan Apache, Terminal Server vs. islerinde. SQL serverler genellikle RAM'i hesap yapmak icin degil, CACHE ve buffer olarak kullanirlar. Bu nedenle CPU yukleri cok fazla olmaz, CPU basina 512MB iyi bir tercih olabilir. Diger yandan MB Basina 512 Bayt CPU Cache gerekecektir, tipik X86 serisinde. Yeni PIII'ler 512K Cache'leriyle cok cekici duruyorlar.
Bu mesaj icin son soz olarak, en iyi swap, olmayan swap'tir demek isterim. SWAP cok kullanislidir ama, sistemin verimini cok fazla dusurur. Eski dump terminal doneminde, baglantilar vs. zaten yavasken, RAM fiyatlari yuksekken, devasa RAM miktarlari takilabilecek kartlar yokken ortalikta, SWAP etkili bir cozumdu. Ama bilhassa sunucu sistemler icin SWAP yerine RAM koymak, guncel durumlarda cok daha ucuza cikabilir. Hatta milletin beklerken harcayacagi elektrik ile bile amortisman edilebilir. Diger yandan, masasustu sistemleri icin calisirligi garanti etmenin en hesapli yolu, peak degeri karsilayacak SWAP kullanimidir. Kisaca, serverler icin SWAP'tan kacarken, masaustlerinde iyi hesaplanmis bir SWAP+RAM kombinasyonu en iyi neticeyi verecektir. En iyi netice, her zaman saglanmak zorunda degildir. Cogunlukla en optimum netice istenir. Yani kirk yilin basi kullanilacak RAM'a bir suru para baglamak yerine bir SWAP space yaratmak.. Sanirim bu mesajdaki bilgiler bu konuda size bazi ipuclari vermis olacaktir.
Gene tipik bir SKoylu semineri olup uykunuzu getirdiyse, kusura kalmayin artik.. Biraz tepki alalim, boyumuzun olcusunu gorelim, devamini sonra getiririz.
Saygi ve sevgilerimi sunarken, SWAP ihtiyaci olmayan gunler dilerim herkese..
-----------------------------------------------------------------------
Liste üyeliğiniz ile ilgili her türlü işlem için
http://liste.linux.org.tr adresindeki web arayüzünü kullanabilirsiniz.
Listeden çıkmak için: 'linux-request@linux.org.tr' adresine,
"Konu" kısmında "unsubscribe" yazan bir e-posta gönderiniz.
-----------------------------------------------------------------------