CPU Topolojisi: Socket, Core, Thread ve Cache

Ön koşul: iş yükü, latency, throughput, eşzamanlılık ve ölçüm sözleşmesi kavramlarını kullanarak compute baseline kurabilmelisin. Bu dersin sonunda socket, package, physical core, hardware thread ve işletim sistemindeki logical CPU sayılarını birbirine karıştırmadan açıklayabilecek; çekirdek sayısını doğrudan performans kabul etmeden uygulamanın paralellik sınırını sorgulayabilecek; cache paylaşımı ile veri yerelliğinin etkisini gösterebilecek; frekans, core yoğunluğu, güç ve lisans arasında kanıtlanabilir karar kaydı oluşturabileceksin. Yaklaşık 27 dakika anlatı ve örnek, 16 dakika Arven çalışması ve 10 dakika kontrollerdir. Belirli işlemci modeli veya üretici kazananı seçmek bu dersin kapsamı değildir.

Socket, sistem kartındaki işlemci bağlantısıdır; işlemci package bu bağlantıya takılan fiziksel bileşendir. Bir package içinde birden çok fiziksel core bulunur. Core komutları yürüten bağımsız işlem kaynaklarını taşır. Simultaneous multithreading etkinse tek physical core işletim sistemine birden fazla hardware thread veya logical CPU gösterebilir. Linux topoloji gösterimi package → core → thread → Linux CPU ilişkisini açıklar. Bu nedenle `lscpu` çıktısındaki `CPU(s)` satırı fiziksel işlemci sayısı değildir. Örneğin iki socket, socket başına 16 core ve core başına iki thread bulunan bir sistem 32 physical core ve 64 logical CPU gösterebilir. Bu aritmetik kapasiteyi tanımlar; 64 bağımsız core performansı kanıtlamaz. Aynı core üzerindeki hardware thread’ler bazı yürütme kaynaklarını paylaşır. İkinci thread, birinci thread’in kullanamadığı kaynaklardan yararlanarak throughput sağlayabilir; kazanım iş yüküne bağlıdır ve iki kat varsayılamaz. Topology yalnız sayım değildir. Hangi core’ların cache, memory controller, interconnect ve I/O yollarını paylaştığını gösterir. Modern sistem bir socket içinde bile birden fazla locality domain sunabilir. İşletim sistemi, hypervisor ve uygulama bu topolojiyi farklı biçimde görebilir. Fiziksel host, VM guest ve container için ayrı görünümü kaydet. VM’e sekiz vCPU verilmesi bunların sekiz ayrı core, aynı socket veya aynı NUMA node üzerinde sabit kaldığı anlamına gelmez. Envanter kaydında üretici/model, socket, core/socket, thread/core, online logical CPU, NUMA node, cache hiyerarşisi, aktif güç profili, firmware, hypervisor ve ölçüm tarihi bulunur. `lscpu`, `numactl --hardware` ve `lstopo` gibi araçlar başlangıç kanıtı sağlar. Çıktıyı topoloji şemasıyla ve platform yönetim katmanıyla doğrula; eski dokümanı canlı sistem gerçeği sayma.

Daha çok core ancak iş daha fazla bağımsız parçaya ayrılabiliyor ve paylaşılan kaynaklar bunu besleyebiliyorsa yarar sağlar. Tek thread üzerinde ilerleyen kritik bölüm, global lock, seri transaction, sınırlı bellek bant genişliği veya I/O beklemesi core eklendikçe aynı kalabilir. Amdahl yaklaşımının pratik dersi formül ezberlemek değil, toplam sürenin hangi bölümünün paralelleşmediğini bulmaktır. Batch içinde 100 iş bağımsız çalışabiliyorsa throughput artabilir; tek sorgunun latency’si aynı oranda azalmaz. İş yükünün thread modeli kanıtlanmalıdır: kaç runnable thread oluşuyor, aynı anda kaç core verimli kullanılıyor, işlem başına CPU zamanı nasıl değişiyor, lock ve context switch davranışı ne, core arttığında throughput eğrisi nerede yataylaşıyor? Uygulama veya veri tabanı üreticisinin desteklediği topology, scheduler ve lisans sınırı da kayda girer. Paralel kopya sayısı ile tek işin thread sayısı aynı ölçü değildir. Frekans bir core’un zaman içindeki clock hızını ifade eder; ancak aynı GHz farklı mikro mimari, komut karışımı, cache davranışı ve güç koşullarında aynı işi üretmez. Base, boost/turbo ve ölçülen etkin frekans ayrılır. Boost değeri bütün core’ların sürekli aynı hızda çalışacağını garanti etmez. Aktif core sayısı, güç/ısı sınırı, firmware profili ve iş yükü kullanılan frekansı etkileyebilir. GHz × core gibi basit bir çarpım güvenilir platform karşılaştırması değildir. Core yoğunluğu toplam throughput, sanallaştırma konsolidasyonu ve lisans maliyetine olumlu veya olumsuz etki edebilir. Daha az, hızlı core seri veya core başına lisanslanan iş yükünde avantajlı olabilir; daha çok core paralel throughput ve VM yoğunluğu için uygun olabilir. Bunlar evrensel sonuç değildir. Aynı yazılım sürümü, veri ve kabul ölçütüyle kontrollü test; platform maliyeti, enerji ve lisans kısıtıyla birlikte değerlendirilir.

Core veriyi doğrudan her seferinde ana bellekten beklememek için cache hiyerarşisini kullanır. L1 core’a en yakın ve küçük, sonraki seviyeler daha büyük fakat daha uzaktır; son seviye cache birden çok core tarafından paylaşılabilir. Tam boyut ve paylaşım sınırı mimariye göre değişir. Cache kapasitesi tek başına başarı ölçüsü değildir: iş yükünün working set’i, erişim düzeni, cache hit/miss, veri paylaşımı ve core yerleşimi sonucu belirler. Aynı veriyi kullanan thread’lerin ortak cache sınırında kalması veri hareketini azaltabilir. İlgisiz ve büyük working set’ler aynı cache’i paylaştığında birbirinin verisini çıkarabilir. False sharing durumunda farklı thread’lerin ayrı verileri aynı cache line’da bulunur ve tutarlılık trafiği doğar. Pre-Sales bu ayrıntıları uygulama kodu düzeyinde çözmek zorunda değildir; fakat “daha çok cache iyidir” iddiasını benchmark, profiler veya üretici uzmanıyla doğrulanacak hipotez olarak kaydetmelidir. Hardware thread’ler aynı core’un yürütme ve cache kaynaklarının bir bölümünü paylaşır. SMT, bir thread beklerken diğerine çalışma fırsatı sağlayabilir; zaten core kaynaklarını doyuran iş yükünde kazanım sınırlı veya olumsuz olabilir. SMT açık ve kapalı karşılaştırması ancak aynı güç, affinity, veri ve iş hacminde anlamlıdır. Güvenlik, deterministik latency veya yazılım desteği gibi nedenlerle politika farklı olabilir; uzman ve üretici desteği doğrulanır. Cache ve topology ölçümü kararın sınırına göre seçilir. `lscpu -e`, `lstopo`, `perf stat` ve uygun platform araçları physical/logical yerleşim ile cache miss sinyali sağlayabilir. Sayaçlar sanallaştırılmış ortamda eksik veya farklı semantikte olabilir. Profiling overhead’i ve üretim riski değerlendirilir. Hedef, tek bir düşük seviye metriği optimize etmek değil, hizmet sonucuna etki eden veri hareketini kanıtlamaktır.

Arven iki seçenek inceler. A seçeneği socket başına daha çok core, daha düşük base frekans ve geniş toplam cache; B seçeneği daha az core, daha yüksek frekans sunar. Satış ekibi A’yı “daha güçlü”, uygulama ekibi B’yi “daha hızlı” ilan eder. İki ifade de iş yükü kanıtı olmadan eksiktir. ERP batch paralel kopyaları, tek thread muhasebe servisi, portal eşzamanlılığı ve core başına lisanslanan bileşen ayrı karar ölçülerine sahiptir. Önce topoloji doğrulanır: socket, physical core, thread/core, NUMA domain, cache paylaşımı ve VM vCPU görünümü. Sonra iş yükü matrisi kurulur. Batch için işler/saat ve pencere; muhasebe servisi için p95 latency ve tek thread CPU zamanı; portal için eşzamanlı throughput, tail latency ve hata oranı; sanallaştırma için bakım durumundaki host kapasitesi ölçülür. Her senaryoda güç profili, SMT durumu, yazılım sürümü, veri seti ve diğer yükler sabit veya açıkça kaydedilir. Lisans maliyeti teknik topolojiden ayrı tutulamaz fakat lisans kuralı tahmin edilmez. Hangi ürünün socket, physical core, assigned vCPU veya başka metriği kullandığı güncel sözleşme ve üretici kaynağıyla uzman tarafından doğrulanır. Daha çok core performans getirirken toplam maliyeti yükseltebilir; daha az core latency hedefini karşılarken bakım kapasitesini daraltabilir. Arven karar kaydı sonuç, trade-off, kanıt, varsayım ve yeniden test koşulu taşır.