Yazının orijinal tarihi: 2006-02-23


Bu konu o kadar derin ve uzun ki nereden başlayacağımı baya bir düşündüm, karar veremedim, rastgele başladım konuya.

4 işlemcili bir sunucu alıp hava atmayı her admin ister. Fakat kritik mesele sunucu üstünde hangi servislerin çalışacağıdır. Mesela, IIS çalışacaksa 4 işlemcili bir makina almak yerine 4 tane tek işlemcili makina almak çok daha yüksek performans ve felaket yönetimine katkı sağlar.

4 işlemcili makinamızdan devam edersek, genelde bu tip server alımlarını büyük firmalar proje olarak değerlendireceklerinden fiyat kuruma/şirkete göre inanılmaz fark eder. Aynı sunucu için bir şirkete 1ytl bile indirim yapmayan firma, bir başka şirket için %65 indirimlere kadar çıkabilir.

Ortalama bir rakam olarak 10.000$-15.000$ (12.500$) diyelim ve bu sunucuda MSSQL (örneği bir başka SQL firmasından da verebilirdim ama birazdan anlatacağım yapıda çalışıp çalışmadığını tam olarak bilmediğimden MS üstünden yazdım, büyük ihtimal tüm SQL'ler aşağıda ki biçimde çalışıyorlardır) çalışıyor farz edelim;

CPU, 4 x 2.4GHZ
RAM, 2 x 2GB 800MHZ veya 1600MHZ
Disk, 6 x 72GB SCSI Ultra Wide320
Raid Controller, 64bit Dual Channel

Temel özellikleri bu şekilde olsun. Şimdi bu örnekten yola çıkarak SQL ne yapacak bunu değerlendirelim.
SQL Standart Edition'a cpu'ları tanıtmak için lisans, 4 x cpu lisans toplam: 17.700$ (fiyat, puan durumuna göre değişken, liste fiyatını aldım).
Windows 2003 Standart Edition, 4 x cpu lisans toplam: 2.400$ (fiyat, puan durumuna göre değişken, ben ortalama aldım).
Windows makinasına kullanıcıların bağlanabilmesi için CAI lisans 10 x lisans toplam: 300$ (fiyat, puan durumuna göre değişken, ben ortalama aldım).

Şimdi SQL üstünde ne çalışacak, genelde SQL'i şirketlerde öncelikli olarak muhasebe yazılımları kullanır. Daha sonra şirketin kendi yazdığı özel programlar vb.. olarak bu sıra devam eder.
Günümüzde;
Microsoft: Exchange, Active Directory, WinFS (henüz alpha aşamasında) ve SharePoint
Antivirus Sunucularından bildiklerim: McAfee ve TrendMicro
Muhasebe/Otomasyon sunucularından bildiklerim: Logo, Link ve Posibble
Çeşitli SQL sunucularını veya tekniklerini kullanmaktadırlar.

Sunucumuzda SQL'in (MS) tek instance olarak kurulduğunu varsayalım (%99 SQL sunucularda yapı böyledir).

Toplamda ortalama sunucumuzun maliyetimiz: 12.500$ + 17.700$ + 2.400$ + 300$ = 32.900$ = 42.770YTL + KDV = 50.468YTL <-Üstünde çalışacak olan muhasebe/kendi yazılımınızın maliyeti hariç.

Makinamız kurulu, herşey hazırlandı ve kullanıcılar bağlanarak çalışıyorlar.
Muhasebe yazılımlarındaki "onarma" ve "tamir" gibi işlemleri arada bir çalıştırıyorsunuz... Veri boyutu arttıkça bu işlemlerde dakikalardan saatlere doğru sistemi bekletmekte.

Muhasebe verileri her geçen gün büyümekte ve raporlar istendikçe raporların üretim süresi git gide artmakta.

Aynı işlemi P4 3GHZ client makinasında denediğinizde çok daha hızlı yaptığını görmektesiniz!

Sizse 4 işlemcili canavar gibi makinanın neden bu kadar kasıldığını anlamaya çalışıyorsunuz.

İlk iş task manager'ı açın ve sql server task'ına bakın, göreceksinizki SQL ram'de 1.7GB'dan daha fazla yer kaplamakta! Geri kalan ram boş olarak durmaktadır.
Tüm ram'i kullanması için SQL'e girip ayarları yaptınız, kapatıp açtınız makinayı işlemi başlattınız fakat gene 1.7GB'dan fazlasını görmedi!
Bunun üzerine düşünürken hızlıca bu yazı aklınıza geldi, hemen boot.ini dosyasını açıp;
"multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows Server 2003, Enterprise" /fastdetect" satırını,
"multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows Server 2003, Enterprise" /3GB /fastdetect" olarak değiştirdiniz, makinayı kapatıp açtınız.
SQL işlemini başlattınız, SQL artık sizin ayarladığınız kadar ram'i kullanıyor, güzel ama yavaşlık problemi hala istediğiniz kadar giderilmiş değil. Birşeylerin sorunlu olduğunu hissediyorunuz ama ne?
SQL işlemini başlatın Task manager'ı açın ve cpu usage'e göz atın amanın o da ne %25'i geçmiyor cpu.. eee cpu'ya bile bu kadar yük binmiyorsa sunucumuz neden bir client makinasından bile yavaş?

Geldik bir başka kritik noktaya: SQL'e ulaşan application server yazılımı (örneğin muhasabe yazılımları) aynı anda kaç adet sql thread açmakta.
Benim gördüğüm tüm muhasebe yazılımları aynı anda sadece 1 thread açarlar (Muhasebenin doğası gereği). Bunun dışında SharePoint ve Exchange'de gene aynı şekilde 1 thread ("Jet ESE" .edb dosyaları) açarlar.
Ve bu noktada yavaşlığın sebeplerinden birini daha bulduk, 1 thread açıldığından SQL toplam cpu gücünün sadece 1 birimini kullanmakta bu da 100birim/4cpu=25'e tekabül etmekte ve bu yüzden toplam işlemci gücümüzün ancak 4/1'ini kullanabiliyoruz.

Bunun önüne geçmek için yapılacak tek şey application server yazılımının aynı anda birden fazla thread açmasını sağlamak yani yazılımı değiştirmek (firma yanaşmayacaktır buna). Yazılımı siz geliştiriyorsanız buda zaman ve paraya mal olacaktır.

BaÅŸka ne yapabiliriz?
Veri tabanımız birden fazlaysa bunları farklı instance'lara bölmek performansı büyük ölçüde arttıracaktır.
SQL makinasına yapılan yatırıma bakınca değdimi acaba?? Bunun yerine tek işlemcili üstünde raid controller'ı bulunan oem makina toplamak daha hızlı bir SQL Sunucu makinasına ve çok daha az maliyete (hem donanım olarak hemde lisans bedelleri olarak) sebep olur.
Biz admin'lerin en çok hata yaptığı noktada budur, plan ve fayda/maliyet analizini hiç yapmayız veya yanlış yaparız. Bence bir admin'in en iyi bilmesi gereken konuların başında bu gelmeli.

Tabi bunda SQL üreticilerinin hatası yokmu? Var tabi, şu kadar işlemci bu kadar ram destekliyoruz gibi lafların arkasında bunları anlatmazlar veya binlerce dökümanın içinde bir yere tek bir cümlecik olarak sıkıştırırlar böylece biz yazdık siz okumamışsınız diyebileceklerdir.

Bir başka yavaşlıkta (<-sadece sql değil tüm sunucular için geçerli) şundan kaynaklanır;
Makinamız süper bir sürü disk'i ve raid'i var iyi güzel hoş ama şuna bakmak lazım geçen 10 yıl içerisinde network, cpu ve ram hızları/büyüklükleri 25 kat artmışken disk'ler de durum sadece 4 kattır.
Disk'ler mekanik cihazlar olduklarından teknolojileri yavaş yavaş gelişir. Aradaki 21 katlık açığı kapatmak için farklı elektronik teknolojileri devreye girer, raid controlller cache, disk cache gibi...
Raid controller'lar da ki cache'ler genelde read/write back/write thru olarak üçe ayrılır.
Write Back: Ram'den raid controller'a gelen veri controller tarafından disk(lere) gönderilir ve disklerden gelen yazıldı bilgisini geri gönderir. Bu süre boyunda disklere yazım yapılmaz. Yavaştır, güvenlidir.
Write Thru: Ram'den raid controller'a gelen veri controller tarafından disk(lere) gönderilir ve ram'e "hazırım" bilgisi gönderilir. Hızlıdır, güvensizdir.

Disk'lere gelince, büyük server üreticilerinin kendi markalarına ait olan disklerde read buffer özelliğinin yanısıra write buffer'da mevcuttur.

Bu teknolojilerin tümü, disklerin yavaşlık problemlerini elektronik olarak çözmeye yöneliktir.

Peki hala yavaşsa, bu durumda raid controller kartımızın içindeki işlemcinin hızının önemi ortaya çıkar. ultra320 teknolojisindeki bir kart 64bit dahi olsa, işlemcisi üreticilere göre farklılık göstermekle birlikte 50-200MHZ arasında değişir, bu da anlık işleyebileceği paket miktarını belirtir.

Bunuda hallettik diyelim, 200MHZ işlemcili 64bit raid controller'ımızı taktık hızımızı arttırdık, fakat hala içinizdeki o his devam ediyor bir yerlerde bişiler yanlış diyor size...
Disklere bakalım tekrar ultra320 teknolojisini kullanıyor ama acaba bu ne demek, genelde admin'lerin yaptığı en büyük hatalardan biri tipte bir diskin 320MB/saniye hızında okuma/yazma yapabileceğine inanmasıdır, büyük hata!
Ultra320 teknolojisi bir veriyoludur ve 320MB saniye hızındadır ama bu hız disklerin kendi aralarında yaptığı işlemler ve raid controller'ın yaptığı işlemler ile sürekli olarak meşguldur, normal kullanım için kalan veriyolunda ise en fazla 80MB/saniyelik hıza ulaşılabilir.

Ne yapacağız?
Diskleri fiber array ile değiştirmek, 8 portlu fiber switch kalitesine ve üstündeki dolu/boş portlara göre 1.500$-6.000$ arasındadır.
Tabi bu da yetmeyecek diskleride deÄŸiÅŸtirmek gerekli, tanesi 1.000$-1.500$.

Eeee ne oldu bizim server makinası işlemcilerin gerçek performansını kullanabilmek için sürekli olarak ek birşeylere ihtiyaç duymakta ve işin kötüsü değişen parçaların eskileride elimize kalıyor ve gerçek anlamda o parçaları kullanamıyoruz.

Tüm bunları yapmamıza rağmen hala içimizde his gitmiş değil. Bu seferde cpu ve disk i/o performanslarına baktığımızda herşey güzel görünmesine rağmen hala birşeyler ters..
Daha sonra günlerce sürecek pdf okumaları vb.. işlerle meşgul olurken gene bu yazıyı hatırladınız, yazıda şöyle diyordu:
"Bir sunucu makinasının gerçek işlem gücünü, üstündeki cpu'ların sayısı ve hızı değil, FSB hızı belirler." Pdf'lerden hatırlamaya çalıştınız FSB hızı neydi? Ama hatırlayamadınız, genelde hiçbirinde yazmaz...

/Hatalıysam düzeltin...

/Düzeltme immortal.