Üretim hizmetlerini işletmek, içeride neler olduğunu bilmeyi gerektirir; ancak ölçüm eklemek ücretsiz değildir. InfoQ'ta yayımlanan bir sunumda, IOP Systems'ın kurucu ortağı Brian Martin, bir uygulama ile diğeri arasındaki farkın sayaç güncellemesini yaklaşık 5 nanosaniyeye mal olan bir işlemden 1 mikrosaniyeyi aşan bir işleme dönüştürebileceğini açıklıyor. Histogramlarda ise fark, iş parçacıkları arasında rekabet olduğunda yaklaşık 7 nanosaniyeden onlarca mikrosaniyeye çıkabilir.
Sunumun temel fikri belirli bir Rust kütüphanesini seçmek değil, ölçümü performans tasarımının bir parçası olarak ele almaktır. Milyonlarca kez çağrılan bir yola yerleştirilen metrik, küçük bir maliyeti bile büyütür; ölçümün yokluğu ise yavaşlığı ve üretim olaylarını teşhis etmeyi ve performansı iyileştirmeyi zorlaştırır.
Veri türünü ve güncelleme maliyetini anlayarak başlayın
Martin, üç temel metrik türünü birbirinden ayırıyor: istek sayısı gibi genellikle azalmayan sayaç; kuyruk derinliği gibi mevcut bir değeri temsil eden anlık ölçüm; ve yanıt süreleri gibi değerlerin dağılımını tanımlayan histogram. Bu ayrım önemlidir; çünkü her tür farklı işlemler gerektirir ve histogramlar tek bir toplam sayacın sağlayamayacağı bilgileri sunar.
En basit durumlarda, tamsayı sayaçlar için atomic fetch_add uygundur. Karşılaştırma ve değiştirme döngüleri veya CAS, birden fazla iş parçacığı aynı konum için rekabet ettiğinde genellikle yeniden deneme gerektirir. Maliyetin önemli bir bölümü, önbellek satırlarının çekirdekler arasında senkronize edilmesinden kaynaklanır. Sunum, 32 sanal işlem birimine sahip bir AWS Graviton makinesindeki ölçümleri aktarıyor: düşük maliyetli atomik güncellemeyle teorik işlem kapasitesi saniyede yaklaşık 119 milyon isteğe ulaşırken, Prometheus ile daha yüksek maliyetli bir uygulamada bu değer yaklaşık 23 milyonda kaldı.
İşlemciye göre bölümleme ile rekabeti azaltın
Tüm iş parçacıkları tek bir sayacı paylaştığında, önbellek satırı çekirdekler arasında sürekli hareket eder. Martin bunun yerine işlemci başına ayrı bir sayaç oluşturmayı öneriyor; böylece yazma işlemleri neredeyse rekabetsiz gerçekleşir ve değerler okuma sırasında toplanır. Bu yaklaşım okuma maliyetini bir miktar artırır, ancak her istekle tekrarlanan sıcak yazma yolunu korur.
Burada false sharing olgusuna dikkat edilmelidir. Mantıksal olarak ayrı sayaçlara sahip olmak yeterli değildir; sayaçlar tek bir önbellek satırına yerleştirilirse sorun devam eder. Satır boyutu 64 bayttır; bu da 64-bit türünde sekiz sayacın yan yana bulunabileceği anlamına gelir. Bu nedenle sunum, sayaçların ayrı önbellek satırlarını kaplayacak şekilde gruplanmasını ve doldurulmasını öneriyor. Sunulan rakamlara göre performans, atomik sayaçla saniyede yaklaşık 119 milyon istekken uygun bölümleme kullanıldığında saniyede yaklaşık 6,4 milyar isteğe çıkabilir.
Histogramları güncelleme yolu için tasarlayın
Histogram maliyeti, değerin hangi kovaya ait olduğunu belirlemekle başlar. Kova listesinde doğrusal arama en basit ve en yavaş seçenektir; ikili arama karşılaştırma sayısını azaltır, ancak yine de kova sayısına bağlıdır. Daha hızlı alternatif, kovayı aramak yerine değer üzerinden kova numarasını hesaplayan doğrudan indekslemedir.
Bu indekslemenin bazı ödünleşimleri vardır. Doğrusal aralıklara bölme hızlıdır, ancak küçük değerlerde görece büyük bir hataya yol açabilir. Logaritmik indeksleme görece hatayı daha iyi korur; ancak logaritmanın kendisini hesaplamak maliyetlidir. Martin, HDR Histogram ve H2Histogram'da olduğu gibi, hassasiyeti ayarlayan alt kovalarla birlikte Log2 tabanlı dış aralıkların kullanılmasını gösteriyor. Atomik olmayan bir testte kovanın belirlenmesi ve güncellenmesi HDR Histogram'da yaklaşık 2,65 nanosaniye, H2Histogram'da ise yaklaşık 2,15 nanosaniye sürdü.
Yaklaşık tutarlılık ne zaman kabul edilebilir?
Histogram maliyeti yalnızca indeksleme yöntemiyle belirlenmez. Bazı uygulamalar her işlemde birden fazla atomik günceller, değerlerin toplamı için CAS kullanır veya tutarlı bir anlık görüntü elde etmek amacıyla kilit uygular. Sunum, bazı uygulamaların 2 mikrosaniyeyi, hatta 32 çekirdekte onlarca mikrosaniyeyi aştığını; doğrudan indeksleme ve tek bir atomik güncellemeye dayanan uygulamanın ise sayaç maliyetine daha yakın olduğunu belirtiyor.
Alternatif, yaklaşık tutarlılıktır: Histogram okunurken bazı kovalar değişebilir, ancak ölçümler zaten yaklaşık olduğunda iki ardışık okuma arasındaki fark yine de yararlı kalır. Bu evrensel bir kural değildir; tamamen tutarlı bir anlık görüntüye ihtiyaç duyan sistemler, maliyetine rağmen senkronizasyonu tercih edebilir.
certi.news'in editoryal değerlendirmesi
Pratikte değişen şey, metrik ekleme kararının yalnızca metrik adlarını değil, güncelleme mimarisini de kapsaması gerektiğidir. Atomik sayaç, işlemciye göre bölümleme ve doğrudan indeksleme, ölçümü hassas yollar içinde kullanılabilir hâle getirebilir; eşzamanlı veya dinamik olarak ölçeklenebilen histogramlar ise yük altında yüksek bir maliyet getirebilir. Sunum, her kütüphane veya hizmet için geçerli tek bir reçete sunmuyor; esnekliğin, kütüphanenin başka projelerde kullanılabilirliğinin, tutarlılığın ve performansın kısmen birbiriyle çatışan hedefler olduğunu gösteriyor. Bu nedenle kütüphanenin adına veya rekabetsiz durumdaki sonucuna güvenmek yerine, gerçek uygulama hedeflenen rekabet düzeyleri ve işlem hacmi altında test edilmelidir.
Martin ayrıca çekirdek kodunu değiştirmeden, Rezolus projesi üzerinden eBPF kullanarak Linux çekirdeğinden; zamanlayıcı, sistem çağrısı yolları ve TCP yığını dahil olmak üzere hassas metrikler elde etmeyi de anlatıyor. Açık soru, her durumda ne kadar hassasiyet ve tutarlılığa ihtiyaç duyulduğu ve sistem genişletildiğinde okuma veya parçaları birleştirme maliyetinin kabul edilebilir kalıp kalmayacağıdır.