SSD mi NVMe mi? Hosting'de Gerçekten Fark Eder mi

SSD mi NVMe mi sorusu hosting sayfalarında hep aynı cümleyle cevaplanıyor: "NVMe, SATA SSD'den yaklaşık 10 kat hızlıdır." Bu cümle bir yalan değil ama sizin sorunuzun cevabı da değil. O 10 kat, büyük dosyaların sıralı okunmasında ölçülen bir megabayt/saniye rakamıdır ve bir web sitesinin diskle kurduğu ilişkiye hemen hiç benzemez. Sizin siteniz diskten 3 GB'lık bir video dosyasını baştan sona okumuyor; onlarca küçük PHP dosyasını, birkaç yüz kilobaytlık bir tema klasörünü ve veritabanının rastgele sayfalarını okuyor. Bu iş yükünde belirleyici olan metrik MB/s değil, IOPS ve gecikmedir.

Bu yazıda önce iki teknolojinin farkını arayüz düzeyinde açıyoruz, sonra reklamlarda kullanılan rakamın neden yanıltıcı olduğunu gösteriyoruz. Ardından asıl soruya geliyoruz: sizin sitenizde darboğaz gerçekten disk mi? Paylaşımlı hostingte gördüğüm yavaşlamaların büyük çoğunluğunda darboğaz disk değil; PHP işlem süresi, veritabanı sorgusu, harici API beklemesi veya aynı sunucudaki komşu hesapların yarattığı kuyruk. Bunu tahmin etmeyeceğiz, ölçeceğiz — top, iostat, fio ve MySQL yavaş sorgu günlüğüyle. Sonunda NVMe'nin gerçekten fark ettiği ve hiç fark etmediği senaryoları liste halinde vereceğiz.

SSD ile NVMe Arasındaki Fark Teknik Olarak Nedir#

Fark disk hücrelerinde değil, diskin anakarta bağlandığı yol ve konuştuğu protokoldedir. SATA SSD, sabit disk çağından kalma bir arayüz ve AHCI protokolü kullanır; NVMe ise doğrudan PCI Express hatlarına bağlanır ve flash bellek için tasarlanmış bir protokol konuşur.

Bu mimari farkın üç somut sonucu vardır:

En kritik satır "komut kuyruğu" satırıdır. SATA tek bir kuyruk üzerinden komut kabul eder; NVMe aynı anda çok sayıda kuyruğu paralel işleyebilir. Bu, tek bir kullanıcının tek bir dosyayı okumasında hiçbir şey değiştirmez. Ama sunucuda aynı anda yüzlerce eşzamanlı istek varsa, yani kuyruk derinliği yükseldiğinde, SATA doyuma ulaşırken NVMe ölçeklenmeye devam eder. NVMe'nin gerçek avantajı hız değil, eşzamanlılıktır.

Neden "10 Kat Hızlı" Rakamı Sizi Yanıltıyor#

Çünkü o rakam sıralı okuma testinden gelir ve web sitenizin disk erişim deseniyle uyuşmaz. Sıralı okuma, diskteki büyük ve bitişik bir bloğu baştan sona okumaktır: video kopyalamak, büyük bir yedek arşivini açmak, bir veritabanı dökümünü geri yüklemek. Bu işlerde arayüzün bant genişliği belirleyicidir ve NVMe gerçekten kat kat öndedir.

Bir web isteğinin disk deseni ise şudur: PHP yorumlayıcı wp-config.php dosyasını okur, ardından wp-includes altındaki onlarca dosyayı, sonra aktif temanın ve eklentilerin dosyalarını okur. Her biri birkaç kilobayt. Bunlar diskin farklı yerlerinde durur. Yani bu rastgele (random) okumadır ve burada belirleyici metrik saniyede kaç işlem yapılabildiğidir — IOPS.

İkinci yanıltıcı nokta şu: bir paylaşımlı hosting hesabında zaten diskin tüm IOPS kapasitesine sahip değilsiniz. Sunucu yüzlerce hesap tarafından paylaşılır ve çoğu modern platformda hesap başına IOPS limiti tanımlıdır. Yani "sunucuda NVMe var" cümlesi, size NVMe'nin tepe performansının verildiği anlamına gelmez; size ayrılan pay kadarını alırsınız. Bu limitlerin nasıl işlediğini paylaşımlı hosting kaynak limitleri yazısında ayrıntılı anlatıyoruz.

Üçüncüsü ve en önemlisi: modern bir sitede diske gidilen istek sayısı zaten düşüktür. OPcache PHP dosyalarını derlenmiş halde bellekte tutar, işletim sistemi sık okunan dosyaları sayfa önbelleğinde saklar, veritabanı motoru kendi tampon havuzunu belleğe kurar. Yani ikinci istekten itibaren diskin devreye girme oranı ciddi biçimde düşer. Bellekten okunan bir sayfa için SATA ile NVMe arasında hiçbir fark yoktur.

Bir Web İsteği Diskten Ne İster#

Tipik bir dinamik sayfa isteği, birkaç yüz küçük dosya okuması ve bir avuç veritabanı sayfası erişimi üretir. Bunun somut karşılığını görmek isterseniz bir WordPress isteğinde açılan dosya sayısını sayabilirsiniz:

strace -f -e trace=openat -c php -r 'require "wp-load.php";' 2>&1 | tail -5

Sonucu gördüğünüzde şaşırmayın: temiz bir kurulumda bile yüzlerce dosya açılır, eklenti sayısı arttıkça bu sayı katlanır. Ama kritik nokta şudur — bu dosyalar her istekte diskten okunmaz. OPcache açıksa ilk istekten sonra bellekten servis edilir:

php -i | grep -E 'opcache.enable|opcache.memory_consumption|opcache.max_accelerated_files'

Çıktıda opcache.enable => On görmüyorsanız, NVMe'ye geçmeden önce yapılacak iş budur ve etkisi disk değişiminden büyüktür. OPcache yapılandırmasının ayrıntıları için php opcache yazısına bakabilirsiniz.

Veritabanı tarafında da benzer bir tampon vardır. InnoDB tampon havuzu veri sayfalarını bellekte tutar; havuz veri setinizden büyükse sorgular diske hemen hiç inmez:

SHOW ENGINE INNODB STATUS\G

Çıktıdaki Buffer pool hit rate satırı 1000/1000'e yakınsa veritabanınız diski kullanmıyor demektir. Bu değer düşükse çözüm daha hızlı disk değil, daha büyük tampon havuzudur. Bu ayarların nasıl yapıldığını mysql mariadb performans optimizasyonu yazısında bulabilirsiniz.

Sitenizin Darboğazı Gerçekten Disk mi#

Diskin darboğaz olup olmadığını tek bir sayı söyler: I/O bekleme oranı. top çıktısındaki wa sütunu, CPU'nun disk cevabını beklerken geçirdiği zamanın yüzdesidir.

top -bn1 | head -3

Örnek bir çıktı:

%Cpu(s): 62.1 us,  8.4 sy,  0.0 ni, 28.9 id,  0.3 wa,  0.0 hi,  0.3 si

Buradaki 0.3 wa şunu söyler: CPU zamanının binde üçü diski bekliyor. Bu sunucuda disk darboğaz değildir; 62.1 us yani kullanıcı alanı CPU tüketimi asıl yüktür ve bu genellikle PHP demektir. Böyle bir sunucuda NVMe'ye geçmek ölçülebilir bir kazanç vermez.

Aynı çıktının şöyle geldiğini varsayalım:

%Cpu(s): 11.2 us,  4.1 sy,  0.0 ni, 22.5 id, 61.8 wa,  0.0 hi,  0.4 si

61.8 wa ciddi bir disk baskısıdır. Bu noktada devam edip hangi cihazın zorlandığına bakılır:

iostat -xz 2 5

Bu çıktıda üç sütuna bakın: %util (cihazın meşguliyeti), aqu-sz (ortalama kuyruk uzunluğu) ve r_await / w_await (istek başına ortalama bekleme, milisaniye). %util sürekli 90'ın üstündeyken aqu-sz de yükseliyorsa disk gerçekten doymuştur. w_await değeri iki haneli milisaniyelere çıkıyorsa istekler kuyrukta bekliyor demektir.

Paylaşımlı hosting kullanıyorsanız iostat'a erişiminiz olmayabilir; o durumda cPanel içindeki kaynak kullanımı ekranı size I/O ve IOPS limitlerinize ne kadar yaklaştığınızı gösterir. Limite dayanma sayısı sıfırdan büyükse, sorununuz diskin teknolojisi değil, hesabınıza ayrılan pay olabilir — çözüm NVMe değil, üst pakete geçmek ya da sunucuya taşınmaktır.

Diski Kendi Sunucunuzda Ölçme: fio ile Doğru Test#

Doğru test, sıralı MB/s değil 4K rastgele okuma IOPS'udur. fio bunun standart aracıdır:

fio --name=rastgele-okuma --filename=/tmp/fio-test --size=1G \
    --rw=randread --bs=4k --iodepth=32 --numjobs=4 --direct=1 \
    --runtime=60 --time_based --group_reporting

Parametrelerin anlamı önemlidir:

• --bs=4k: blok boyutu 4 kilobayt. Web iş yükünün gerçek birimi budur, 1 MB değil.
• --rw=randread: rastgele okuma. Sıralı test (read) size pazarlama rakamını verir, gerçeği değil.
• --iodepth=32: kuyruk derinliği. SATA ile NVMe arasındaki farkı görmek istiyorsanız burayı yükseltmelisiniz. --iodepth=1 ile test ederseniz iki disk arasında dramatik bir fark göremezsiniz; çünkü tek kuyrukta NVMe'nin paralellik avantajı devreye girmez.
• --direct=1: işletim sistemi önbelleğini atla. Bunu yazmazsanız diski değil RAM'i ölçersiniz ve sonuç anlamsız derecede yüksek çıkar.

Aynı testi --iodepth=1 ve --iodepth=64 ile iki kez çalıştırın. İki sonuç arasındaki eğri size şunu söyler: derinlik arttıkça IOPS artmaya devam ediyorsa cihaz iyi ölçekleniyordur; erken düzleşiyorsa arayüz doyuma ulaşmıştır. NVMe'nin SATA'ya üstünlüğü tam olarak bu eğrinin sağ tarafında ortaya çıkar.

Yazma testi yapacaksanız üretim sunucusunda dikkatli olun; --rw=randwrite gerçek veri yazar ve diski meşgul eder. Test dosyasını iş bitince silin:

rm -f /tmp/fio-test

NVMe'nin Gerçekten Fark Ettiği Senaryolar#

NVMe farkı, disk üzerinde eşzamanlı ve rastgele erişimin yoğunlaştığı yerlerde hissedilir. Somut liste:

1. Yoğun veritabanı yazması. Sürekli sipariş, stok ve sepet güncellemesi yapan bir e-ticaret sitesi InnoDB günlüğüne durmadan yazar. Kampanya saatlerinde eşzamanlı yazma sayısı yükseldiğinde SATA kuyruğu şişer. Bu senaryo için e-ticaret için hosting seçimi yazısındaki kapasite planlaması yaklaşımı işinizi görür.
2. Tampon havuzuna sığmayan veri seti. Veritabanınız 20 GB, sunucudaki bellek 4 GB ise sorguların önemli bölümü diske iner. Burada disk gerçekten sıcak yoldadır.
3. Çok sayıda küçük dosya barındıran uygulamalar. Görsel kütüphanesi büyümüş bir medya sitesi, cache dosyası üreten eklentiler, mail sunucusundaki Maildir yapısı.
4. Yedekleme ve geri yükleme pencereleri. Gece alınan yedek, gündüz trafiğiyle çakışırsa SATA'da site fark edilir ölçüde yavaşlar. Yedek stratejisi kurarken rsync ile yedekleme yazısındaki artımlı yaklaşım bu baskıyı da azaltır.
5. Sanallaştırma yoğunluğu. Aynı fiziksel diskte çok sayıda sanal sunucu varsa, hepsinin rastgele erişimi tek bir kuyrukta toplanır. Bu, VDS tarafında NVMe'nin en net kazandığı durumdur.
6. Büyük log ve analiz işleri. Günlük dosyalarını tarayan, indeks kuran veya toplu içe aktarma yapan işler.

NVMe'nin Neredeyse Hiç Fark Etmediği Senaryolar#

Buna karşılık şu durumlarda disk değişimi ölçülebilir bir kazanç vermez:

1. Statik ağırlıklı, düşük trafikli tanıtım sitesi. Sayfa zaten önbellekten servis ediliyorsa disk hemen hiç devreye girmez.
2. Tam sayfa önbelleği açık WordPress. Ziyaretçi HTML dosyasını alıyorsa PHP bile çalışmaz. Önbellek kurulumu için wordpress önbellek rehberi doğru başlangıçtır.
3. Darboğazın PHP olduğu siteler. wa düşük, us yüksekse sorun kodda veya eklenti sayısındadır. Bunun tanısını site neden yavaş açılıyor yazısında adım adım kuruyoruz.
4. Darboğazın ağ veya harici servis olduğu siteler. Ödeme sağlayıcısına, kargo API'sine veya harici bir yazı tipi sunucusuna yapılan bekleme diskle ilgili değildir. Bu bekleme TTFB'ye doğrudan yansır; ayrıntı için ttfb nedir nasıl düşürülür.
5. Belleğe sığan küçük veritabanları. Birkaç yüz megabaytlık bir veritabanı InnoDB tampon havuzuna tamamen sığıyorsa okuma zaten RAM'den yapılır.
6. Komşu yükünün baskın olduğu paylaşımlı sunucular. Aynı makinedeki başka bir hesap diski doyurmuşsa, cihazın NVMe olması sizin payınızı büyütmez.

Karar: Disk Seçimini Neye Göre Yapmalısınız#

Sıralama şudur: önce önbellek, sonra bellek, sonra disk. Bu üçünü tersten yaparsanız en pahalı çözümü en az fayda için almış olursunuz.

Pratik özet: yeni bir paket seçiyorsanız ve aradaki fark makulse NVMe'yi tercih edin, çünkü ileride eşzamanlılık arttığında sizi koruyacak tampon odur. Ama mevcut siteniz yavaş diye NVMe'ye geçmeyi çözüm sanmayın; önce top çıktısındaki wa sütununa bakın. O sayı düşükse disk değiştirmek hiçbir şey kazandırmaz. Barındırma sunucusunun coğrafi konumundan kaynaklanan gecikmeler de sık sık disk sanılır; bu ayrımı yapmak için yurt içi mi yurt dışı hosting mi yazısındaki ölçüm yöntemleri işe yarar. Disk alanı doluluğunun ayrı bir konu olduğunu da unutmayın; kotayı yönetmek için cpanel disk kullanımı yazısı yeterli olacaktır.

Sıkça Sorulan Sorular#

NVMe SATA SSD'den kaç kat hızlıdır#

Sıralı okuma testinde birkaç kat ile on kat arasında bir fark ölçülür, ancak bu rakam bir web sitesinin performansını temsil etmez. Web iş yükü küçük ve rastgele erişimlerden oluşur; burada ölçülen metrik IOPS ve gecikmedir ve fark, kuyruk derinliği yükseldikçe açılır. Tek kullanıcının tek dosya okuduğu senaryoda iki disk arasında hissedilir bir fark yoktur. Yani "kaç kat" sorusunun cevabı, sunucudaki eşzamanlı istek sayısına bağlıdır.

Paylaşımlı hostingte NVMe fark eder mi#

Kısmen eder ama beklediğiniz kadar değil, çünkü paylaşımlı ortamda diskin tüm kapasitesi size ait değildir. Hesap başına tanımlı IOPS ve I/O limitleri, altta hangi disk olursa olsun sizin alabileceğiniz maksimum payı belirler. Sunucu genel olarak daha az kuyruklandığı için dolaylı bir iyileşme hissedilir, ancak sitenizin darboğazı PHP veya eklenti yüküyse hiçbir değişiklik göremezsiniz. Önce kaynak kullanım ekranınızdan limite dayanma olup olmadığına bakın.

Sitem yavaş, NVMe'ye geçersem düzelir mi#

Yalnızca darboğazınız gerçekten diskse düzelir ve bunu bir komutla anlayabilirsiniz. top çıktısındaki wa (I/O wait) değeri düşükse disk beklemiyorsunuz demektir; o durumda disk değiştirmek ölçülebilir bir kazanç vermez. Yavaşlığın en yaygın üç sebebi önbelleğin kapalı olması, eklenti yükü ve yavaş veritabanı sorgularıdır. Bu üçünü düzeltmek çoğu sitede disk değişiminden çok daha büyük bir fark yaratır.

IOPS nedir ve hosting için neden önemli#

IOPS, diskin saniyede gerçekleştirebildiği giriş/çıkış işlemi sayısıdır. Bir web sunucusu büyük dosyalar yerine çok sayıda küçük dosya okuduğu için performansı belirleyen şey saniyede kaç megabayt aktarıldığı değil, saniyede kaç ayrı isteğin karşılandığıdır. Aynı sunucuda yüzlerce eşzamanlı ziyaretçi olduğunda bu istekler birikir ve IOPS kapasitesi tükendiğinde her istek kuyrukta beklemeye başlar. Sayfa açılış süresindeki ani sıçramaların çoğu bu kuyruklanmadan gelir.

Kuyruk derinliği ne demek ve neden fark yaratıyor#

Kuyruk derinliği, diske aynı anda gönderilmiş ve henüz cevaplanmamış istek sayısıdır. SATA arayüzü tek bir komut kuyruğu üzerinden çalışır, NVMe ise çok sayıda kuyruğu paralel işleyebilir. Derinlik düşükken yani sunucu boştayken iki teknoloji birbirine yakın davranır; derinlik yükseldiğinde SATA doyuma ulaşırken NVMe ölçeklenmeye devam eder. Bu yüzden NVMe'nin gerçek faydası yoğun saatlerde ortaya çıkar, gece testinde değil.

VDS alırken NVMe şart mı#

Şart değil ama çoğu senaryoda doğru tercihtir, özellikle aynı fiziksel makinede çok sayıda sanal sunucu barındırılıyorsa. Sanallaştırılmış ortamda tüm sanal makinelerin rastgele erişimleri aynı fiziksel diskte toplanır ve bu tam olarak NVMe'nin kazandığı durumdur. Buna karşılık statik içerik sunan, düşük trafikli veya tamamen bellekte çalışan bir uygulama için SATA da yeterlidir. Karar verirken diskin türü kadar size ayrılan IOPS payının garantili olup olmadığını da sorun.

fio testini üretim sunucusunda çalıştırabilir miyim#

Okuma testini dikkatli biçimde çalıştırabilirsiniz ama yazma testini yoğun saatte yapmayın. --rw=randread ile yapılan bir test diski meşgul eder ancak veriye zarar vermez; buna karşılık test süresince sitenizin cevap süresi yükselir, bu yüzden düşük trafikli bir saati seçin. Yazma testleri gerçek veri üretir ve diski daha ağır meşgul eder, üretim veritabanının bulunduğu bir birimde önerilmez. Test dosyasını iş bitince mutlaka silin, aksi halde boş yere disk alanı tutar.

NVMe diskin ömrü SATA SSD'den kısa mı#

Genel olarak hayır; ömrü belirleyen şey arayüz değil, flash hücre tipi ve toplam yazma dayanıklılığıdır. Aynı hücre teknolojisine sahip iki diskten NVMe olanı daha kısa ömürlü değildir. Barındırma tarafında zaten sunucu sınıfı diskler kullanılır ve bunların yazma dayanıklılığı tüketici disklerinden yüksektir. Kullanıcı olarak sizin açınızdan asıl kritik konu diskin ömrü değil, sağlayıcının yedekleme politikası ve sizin kendi yedeğinizin olup olmadığıdır.

Kapanış#

SSD mi NVMe mi sorusunun dürüst cevabı şudur: NVMe daha iyi bir teknolojidir ve eşzamanlılık arttığında farkını kesin olarak gösterir, ama bir web sitesinin yavaşlığının en yaygın sebebi disk değildir. Reklamlarda geçen "10 kat hızlı" ifadesi sıralı okuma testine aittir; sizin siteniz küçük ve rastgele okumalar yapar ve orada belirleyici metrik IOPS ile kuyruk derinliğidir. Karar vermeden önce yapılacak tek doğru iş ölçmektir: top çıktısındaki wa sütununa bakın, gerekirse iostat -xz ile cihaz doygunluğunu ve fio --bs=4k --rw=randread ile 4K rastgele okuma performansını doğrulayın. Bu üç ölçüm size disk mi yoksa PHP mi suçlu olduğunu net biçimde söyler.

Yeni bir barındırma seçiyorsanız ve iş yükünüz statik ağırlıklıysa web hosting paketleri, ürün sayısı ve eşzamanlı sipariş yoğunluğu yüksek bir mağaza işletiyorsanız e-ticaret hosting tarafı bu yükü karşılamak üzere yapılandırılmıştır. Ölçtüğünüz wa değeri yüksek çıkıyor ve paylaşımlı ortamdaki IOPS payınıza sürekli dayanıyorsanız, kaynağın tamamının size ait olduğu VDS sunucu tarafına geçmek disk teknolojisini değiştirmekten daha kalıcı bir çözüm olur; yoğun veritabanı yazması olan yükler için performans sunucu paketleri bu senaryoya göre kurgulanmıştır.