NUMA Nedir, VM Performansına Etkisi

İki soketli, 64 çekirdekli, 512 GB bellekli devasa bir sunucu aldın. Üzerinde çalışan veritabanın, aynı iş yükünü tek soketli daha küçük bir makinede çalıştırdığından daha yavaş. Kaynak grafiklerinde CPU boşta, disk rahat, ağ temiz — ama sorgu gecikmeleri açıklanamaz şekilde dalgalanıyor. Bu tabloyu gördüğümde ilk baktığım yer NUMA yerleşimi olur, çünkü çok soketli sistemlerde performansın en sessiz katili budur.

NUMA (Non-Uniform Memory Access, yani tekdüze olmayan bellek erişimi), birden fazla işlemci soketi olan sunucularda belleğin soketler arasında bölünmesi ve her işlemcinin kendi belleğine diğerlerininkinden daha hızlı erişmesi anlamına gelir. Bu rehberde NUMA'nın donanım seviyesinde ne olduğunu, sanal makine yerleşiminin neden bu kadar kritik olduğunu, çapraz düğüm erişiminin maliyetini hangi komutlarla ölçebileceğini ve bir VM'i NUMA açısından doğru konumlandırmak için hipervizör tarafında neler yapabileceğini anlatacağım.

NUMA Donanım Seviyesinde Ne Demek#

Tek soketli bir sunucuda hikâye basittir: tek bir işlemci vardır, tüm bellek modülleri o işlemcinin bellek denetleyicisine bağlıdır ve her çekirdek her bellek adresine aynı gecikmeyle erişir. Buna UMA (Uniform Memory Access) denir. İki ya da dört soketli bir sunucuda ise her soketin kendi bellek denetleyicisi ve kendi fiziksel bellek yuvaları vardır. Soket 0'a bağlı bellek modülleri "düğüm 0"ı, soket 1'e bağlı olanlar "düğüm 1"i oluşturur.

Soket 0'daki bir çekirdek, düğüm 0'daki belleğe doğrudan erişir. Aynı çekirdek düğüm 1'deki bir adrese erişmek istediğinde, isteğin soketler arası bağlantı üzerinden (Intel'de UPI/QPI, AMD'de Infinity Fabric) karşı sokete gitmesi, orada bellekten okunması ve geri dönmesi gerekir. Bu çapraz düğüm erişimi (remote access), yerel erişime göre tipik olarak %30 ile %100 arasında daha uzun sürer ve bant genişliği de düşer. Yükü ağırsa bu fark doğrudan uygulama gecikmesine yansır.

Sunucunun NUMA topolojisini görmek için ana makinede:

# Düğüm sayısı, her düğümdeki çekirdekler ve bellek miktarı
numactl --hardware

# Örnek çıktı:
# available: 2 nodes (0-1)
# node 0 cpus: 0 1 2 3 4 5 6 7 32 33 34 35 36 37 38 39
# node 0 size: 257512 MB
# node 1 cpus: 8 9 10 11 12 13 14 15 40 41 42 43 44 45 46 47
# node 1 size: 257512 MB
# node distances:
# node   0   1
#   0:  10  21
#   1:  21  10

Çıktının en sonundaki mesafe matrisi işin özüdür. 10 değeri yerel erişimin referans maliyetidir; 21 ise karşı düğüme erişimin yaklaşık iki katı maliyetli olduğunu söyler. Bu sayılar donanım üreticisinin bildirdiği göreli değerlerdir, mutlak nanosaniye değil — ama sıralama olarak gerçeği doğru yansıtırlar.

Sanal Makineler NUMA'dan Nasıl Etkilenir#

Bir sanal makinenin vCPU'ları ve belleği, hipervizör tarafından fiziksel kaynaklara eşlenir. İdeal durumda bir VM tamamen tek bir NUMA düğümüne sığar: dört vCPU'su düğüm 0'daki çekirdeklere, 16 GB belleği düğüm 0'daki bellek modüllerine yerleşir. Bu VM, çapraz erişim yapmadan çalışır ve performansı öngörülebilir olur.

Sorun iki durumda çıkar. Birincisi, VM tek düğüme sığmayacak kadar büyükse: 40 vCPU'lu bir makineyi 16 çekirdekli düğümlere dağıtmak zorundasındır, dolayısıyla bir kısmı zorunlu olarak uzaktaki belleğe erişecektir. İkincisi ve çok daha yaygını, VM sığdığı halde hipervizörün onu iki düğüme dağıtmasıdır. Zamanlayıcı, anlık boşluğa göre vCPU thread'lerini bir düğümden diğerine taşıyabilir; bellek ise ilk ayrıldığı düğümde kalır. Sonuç: vCPU düğüm 1'de çalışırken belleğinin tamamı düğüm 0'dadır ve her bellek erişimi çapraz olur.

Bu durumun bir VM'in içinden fark edilmesi son derece zordur, çünkü misafir işletim sistemi genellikle tek düz bir bellek alanı görür. Belirtiler dolaylıdır:

Bu belirtilerin CPU aşırı tahsisiyle karışması çok olağandır; ikisini ayırmak için önce steal time'a bakmak gerekir. CPU steal time nedir yazısındaki eşiklerle karşılaştırdığında steal düşük ama gecikme yüksekse, şüphe listende NUMA üst sıraya çıkar.

Kendi Sistemindeki NUMA Davranışını Ölçmek#

Ana makineye erişimin varsa ölçüm nettir. numastat komutu, süreç bazında hangi düğümden ne kadar bellek sayfası okunduğunu ve kaç tanesinin "uzak" olduğunu gösterir:

# Düğüm bazında sistem geneli sayaçlar
numastat

#                            node0           node1
# numa_hit              1284537219      1190348811
# numa_miss                  482913        11294427
# numa_foreign            11294427          482913
# local_node            1283901220      1189772004
# other_node                 635999          576807

# Belirli bir sürecin (örneğin qemu misafiri) düğüm dağılımı
numastat -p $(pgrep -f 'qemu.*musteri-vm' | head -1)

Buradaki numa_miss ve numa_foreign sayaçları, istenen düğümde yer bulunamadığı için başka düğümden karşılanan tahsisleri sayar. numa_hit'e oranla %1'in altındaki değerler normaldir; %5'i geçiyorsa yerleşimin bozulduğunu düşünebilirsin. Bir misafirin bellek dağılımını doğrudan libvirt üzerinden de görebilirsin:

# Misafirin vCPU'ları hangi fiziksel çekirdeklerde
virsh vcpuinfo musteri-vm | grep -E 'VCPU|CPU:'

# Misafirin bellek düğümü ayarları
virsh numatune musteri-vm

Misafirin içindeyken elin daha kısıtlıdır ama tamamen boş değil. Modern hipervizörler sanal NUMA topolojisini misafire aktarabilir; aktarılmışsa misafirin içinde de numactl --hardware birden fazla düğüm gösterir ve uygulamanı buna göre ayarlayabilirsin. Tek düğüm görüyorsan ya makine tek düğüme sığıyordur ya da topoloji gizlenmiştir.

VM'i Doğru NUMA Düğümüne Yerleştirmek#

Düzeltme yöntemi, VM'in vCPU'larını ve belleğini aynı düğüme sabitlemektir. libvirt/KVM tarafında bu iki ayarın birlikte yapılması gerekir; yalnızca birini yapmak sorunu çözmez, hatta bazen kötüleştirir.

# 1) Belleği düğüm 0'a sabitle (strict: başka düğümden tahsis etme)
virsh numatune musteri-vm --nodeset 0 --mode strict --live --config

# 2) vCPU'ları da aynı düğümün fiziksel çekirdeklerine pinle
virsh vcpupin musteri-vm 0 0 --live --config
virsh vcpupin musteri-vm 1 1 --live --config
virsh vcpupin musteri-vm 2 2 --live --config
virsh vcpupin musteri-vm 3 3 --live --config

strict modunda hipervizör, belirtilen düğümde yer bulamazsa tahsisi reddeder — bu, sessizce çapraz erişime düşmekten iyidir ama düğüm dolduğunda misafirin başlamamasına yol açabilir. Daha esnek olmak istersen preferred modunu kullanabilirsin: mümkünse o düğümü kullanır, olmazsa diğerine taşar.

Uygulama seviyesinde de aynı şeyi yapabilirsin. Ana makinede doğrudan çalışan bir veritabanı sürecini tek düğüme bağlamak için:

# Süreci düğüm 0'ın çekirdeklerinde ve düğüm 0 belleğiyle başlat
numactl --cpunodebind=0 --membind=0 /usr/sbin/mysqld --defaults-file=/etc/my.cnf

# Belleği tüm düğümlere eşit dağıtmak istersen (bant genişliği odaklı iş yükleri)
numactl --interleave=all /opt/uygulama/bin/servis

--interleave=all ilk bakışta ters görünür ama belirli iş yükleri için doğru cevaptır: eğer uygulama zaten tüm düğümlere yayılmak zorundaysa, belleği dengeli dağıtmak en kötü durumu (tüm belleğin tek düğümde olması) engeller ve toplam bellek bant genişliğini artırır. Analitik sorgular ve büyük veri işleme genellikle bu kategoriye girer.

Büyük Sayfalar, Bellek Aşırı Tahsisi ve NUMA Etkileşimi#

NUMA'yı tek başına ele almak eksik olur; bellek yönetiminin diğer mekanizmalarıyla iç içe çalışır. Huge pages (büyük sayfalar) bunların en önemlisidir. Standart 4 KB'lik sayfalar yerine 2 MB'lik sayfalar kullanıldığında, adres çeviri tablosu (TLB) çok daha az girdiyle aynı bellek alanını kapsar; TLB ıskalamaları azalır ve çapraz düğüm erişiminin maliyeti kısmen telafi edilir. Büyük bellekli veritabanı misafirlerinde ölçülebilir kazanç sağlar.

# Düğüm bazında ayrılmış büyük sayfa sayısını gör
cat /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages
cat /sys/devices/system/node/node1/hugepages/hugepages-2048kB/nr_hugepages

# Düğüm 0'a 8192 adet 2 MB'lik sayfa ayır (16 GB)
echo 8192 > /sys/devices/system/node/node0/hugepages/hugepages-2048kB/nr_hugepages

İkinci etkileşim bellek aşırı tahsisiyledir. Balloon sürücüsü bir misafirden bellek geri aldığında, geri verilen sayfalar rastgele düğümlerden gelir; misafir tekrar bellek istediğinde ise hipervizör o an nerede yer varsa oradan verir. Bu döngü, başlangıçta düzgün yerleşmiş bir VM'in zamanla iki düğüme dağılmasına yol açar. Balloon mekanizmasının nasıl çalıştığını ve hangi durumlarda devreye girdiğini RAM balloon ve bellek aşırı tahsisi yazısında ayrıntılı anlattım — NUMA hassasiyeti olan misafirlerde balloon'u kapatmak sık başvurulan bir çözümdür.

Üçüncü etkileşim, otomatik NUMA dengeleme ile olur. Linux çekirdeği, sayfaları erişildikleri düğüme taşımaya çalışan bir mekanizma içerir. Çoğu zaman faydalıdır ama pinlenmiş misafirlerde gereksiz sayfa taşımaları yaratır:

# Otomatik NUMA dengelemeyi kapat (pinleme yaptıysan mantıklı)
sysctl -w kernel.numa_balancing=0
# Kalıcı yapmak için
echo 'kernel.numa_balancing = 0' >> /etc/sysctl.d/99-numa.conf

Sık Yapılan Hatalar ve Tuzaklar#

En yaygın hata, VM'i olabildiğince büyük yapmak. "Nasılsa fazlası zarar vermez" mantığıyla 48 vCPU tanımlanan bir makine, 16 çekirdekli düğümlere sahip bir sunucuda zorunlu olarak üç düğüme yayılır ve her bellek erişimi kumar haline gelir. Aynı iş yükü, tek düğüme sığan 16 vCPU'luk bir makinede çoğu zaman daha hızlı çalışır. Boyutlandırmayı düğüm sınırlarına göre yap; çekirdek sayısını düğüm başına düşen çekirdek sayısının katları olarak seç.

İkinci hata, belleği pinleyip vCPU'yu pinlememek (ya da tersi). Yalnızca belleği düğüm 0'a sabitlersen, zamanlayıcı vCPU'ları düğüm 1'e taşıdığında tüm erişimler çapraz olur — hiç pinlemesen daha iyi olurdu. İkisi her zaman birlikte yapılmalıdır.

Üçüncü tuzak, canlı göç sonrası yerleşimin bozulması. Bir misafiri başka bir ana makineye taşıdığında hedef makinedeki NUMA topolojisi farklı olabilir ve pinleme kuralların anlamsızlaşır, hatta misafiri yanlış çekirdeklere bağlayabilir. Göç sonrası virsh numatune ve virsh vcpupin çıktılarını mutlaka yeniden doğrula.

Dördüncü ve en sinsi tuzak, NUMA'yı gereksiz yere suçlamak. Tek soketli bir sunucuda NUMA yoktur; numactl --hardware tek düğüm gösteriyorsa aradığın sorun başka yerdedir. Küçük VM'lerde ve tek soketli makinelerde bu konuya harcanan zaman genellikle boşa gider — önce disk gecikmesini, steal time'ı ve uygulama profilini eleyerek gel.

Sıkça Sorulan Sorular#

NUMA her sunucuda var mı#

Hayır. NUMA yalnızca birden fazla işlemci soketi olan ya da tek yongada birden fazla bellek denetleyicisi bulunan sistemlerde anlamlıdır. Tek soketli tipik bir sunucu ya da masaüstü sınıfı bir makine tek NUMA düğümü olarak görünür ve çapraz erişim diye bir kavram oluşmaz. Sunucunda durumun ne olduğunu numactl --hardware ya da lscpu | grep NUMA komutuyla saniyeler içinde görebilirsin.

VPS kullanıyorum, NUMA benim sorunum mu#

Doğrudan müdahale edemezsin ama sonuçlarını yaşarsın. Yerleşim kararını hipervizörü yöneten sağlayıcı verir; sen yalnızca semptomu ölçebilirsin. Küçük ve orta boy sanal sunucularda etki genellikle ihmal edilebilir düzeydedir çünkü makine zaten tek düğüme sığar. Yüksek çekirdekli ve büyük bellekli sanal makineler kiralıyorsan, sağlayıcıya makinenin tek NUMA düğümüne yerleştirilip yerleştirilmediğini sormak yerinde bir sorudur.

Çapraz NUMA erişimi ne kadar yavaşlatır#

Donanıma ve iş yüküne göre değişir; gecikme tarafında tipik olarak %30 – %100 ek maliyet, bant genişliği tarafında ise ölçülebilir bir düşüş görülür. Uygulaman bellek erişim yoğun değilse (örneğin çoğunlukla ağ bekliyorsa) bu fark neredeyse hiç hissedilmez. Veritabanı, önbellek sunucusu ve bellek içi analitik gibi iş yüklerinde ise doğrudan yanıt süresine yansır.

NUMA ayarlarını misafirin içinden değiştirebilir miyim#

Kısmen. Hipervizör sanal bir NUMA topolojisi sunuyorsa misafirin içinde numactl ile süreçleri belirli sanal düğümlere bağlayabilirsin ve bu gerçek bir kazanç sağlar. Ancak sanal düğümlerin fiziksel düğümlere doğru eşlendiğinden emin olamazsın; asıl karar ana makinededir. Topoloji aktarılmamışsa misafir tek düğüm görür ve yapabileceğin bir şey kalmaz.

numactl kurulu değil, nasıl yüklerim#

Çoğu dağıtımda tek paket olarak gelir. Debian/Ubuntu tarafında apt install numactl, RHEL türevlerinde dnf install numactl komutu yeterlidir. İzleme sayaçları için numastat da aynı paketin içindedir. Ek olarak lscpu ve /sys/devices/system/node/ altındaki dosyalar hiçbir paket gerektirmeden temel topoloji bilgisini verir.

Büyük sayfalar NUMA sorununu çözer mi#

Çözmez ama etkisini azaltır. Büyük sayfalar adres çevirisi sırasındaki TLB ıskalamalarını düşürdüğü için bellek erişim başına toplam maliyet azalır, dolayısıyla çapraz erişimin cezası da görece küçülür. Yine de asıl çözüm, vCPU ile belleği aynı düğümde tutmaktır. En iyi sonucu ikisini birlikte uyguladığında alırsın: doğru yerleşim artı büyük sayfa desteği.

Kapanış#

NUMA, çok soketli sunucularda "hepsi aynı bellek" varsayımının geçersiz olduğunu hatırlatan bir gerçekliktir. Sanal makine dünyasında bu gerçeklik, öngörülemeyen gecikmeler ve açıklanamayan yavaşlamalar olarak karşına çıkar. Akılda tutulması gereken dört alışkanlık var: VM'leri düğüm sınırlarına göre boyutlandır, vCPU ile belleği her zaman birlikte pinle, numastat sayaçlarını periyodik olarak kontrol et ve canlı göçten sonra yerleşimi yeniden doğrula.

Kendi hipervizörünü yönetmek yerine kaynakların doğru yerleştirildiği hazır bir altyapı istiyorsan, VDS ve dedicated sunucu paketlerimizde çekirdek ve bellek eşlemesi baştan planlanmış olarak gelir; esneklik öncelikliyse bulut sunucu tarafına bakabilirsin. Yerleşim, pinleme ve performans ayarlarını uzmanına bırakmak istersen sunucu yönetimi hizmetimiz bu işi baştan sona üstlenir.