Halihazırda Linux çekirdeğinde BPF tabanlı performans analizi araçları geliştiren DTrace geliştiricilerinden Brendan Gregg, Netflix'in Cassandra DBMS'yi CentOS'tan Ubuntu'ya geçirirken karşılaştığı performans sorunlarını analiz ederek elde ettiği deneyimi özetledi. Xen'i temel alan Amazon EC2 bulutu. Geçişten sonra CPU yükü %30 arttı ve yazma işlemleri sırasındaki gecikmeler de yaklaşık aynı miktarda arttı. Anlaşıldığı üzere, zaman bilgisini yoğun bir şekilde talep eden uygulamaların performansı, sistemde seçilen tam zaman kaynağına oldukça bağlıdır.
İlk başta, performanstaki düşüşün nedeni açık değildi ve teşhis, top ve execsnoop yardımcı programlarını kullanarak sürekli çalışan veya periyodik olarak başlatılan kaynak yoğun sistem işlemlerinin olası etkisinin izlenmesiyle başladı. Ancak her şey, özellikle Java ile yazılmış Cassandra DBMS'de kaynak tüketiminin arttığını gösteriyordu. CentOS ve Ubuntu'da paralel olarak çalışan ve aynı sorguları işleyen iki Cassandra işleminin profil oluşturma ölçümleri karşılaştırıldığında, toplam sürenin yaklaşık %32'sinin geçerli saat hakkında bilgi edinmek için kullanılan os::javaTimeMillis() çağrılmasıyla harcandığı ortaya çıktı. .
Bundan sonra, System.currentTimeMillis() yöntemini yüz milyon kez bir döngüde çağıran basit bir Java uygulamasının yazıldığı bir deney yapıldı. Uygulamayı çalıştırmak, CentOS'ta tamamlanmasının 13 saniye sürdüğünü ve Ubuntu'da yaklaşık 68 saniye sürdüğünü gösterdi. 5 kat daha yavaş. C'de gettimeofday() işlevini yüz milyon kez çağıran benzer bir program yazıldı, ancak çalıştırıldığında benzer sonuçlar elde edildi.
Sorunun kaynağının şimdiki zamanı döndürme işlevi olduğu anlaşıldığından, sistemdeki farklı kesin zaman kaynaklarını seçerken dikkatler göstergelerdeki değişikliklere çevrildi. “/sys/devices/system/clocksource/clocksource0/current_clocksource” içeriğine bakılırsa, konuk sistemde Linux çalıştırırken varsayılan olarak “xen” zamanlayıcısı kullanıldı. Zaman kaynağını "tsc" olarak değiştirdikten sonra Ubuntu'daki test uygulamasının yürütme süresi 68 saniyeden 3.3 saniyeye düştü, yani. 20 kat daha hızlı oldu. Ek olarak kvm-saat zaman kaynağının performans testi gerçekleştirildi ve bu test, TSC'ye kıyasla gecikmelerde %20 oranında artış olduğunu gösterdi. $ cat /sys/devices/system/clocksource/clocksource0/available_clocksource xen tsc hpet acpi_pm $ cat /sys/devices/system/clocksource/clocksource0/current_clocksource xen $ zaman java TimeBench gerçek 1m8.300s kullanıcı 0m38.337s sys 0m29.875s $ echo tsc > /sys/devices/system/clocksource/clocksource0/current_clocksource $ zaman Java TimeBench gerçek 0m3.370s kullanıcı 0m3.353s sys 0m0.026s
Bir TSC kaynağı seçerken zamanı elde etmek için, yürütülmesi bir sistem çağrısı gerektirmeyen RDTSC işlemci talimatı kullanılır (talimat yükseltilmiş ayrıcalıklar gerektirmez ve CPU'da yerleşik zaman sayacından bir değer üretir). Varsayılan olarak TSC etkinleştirilmemiştir çünkü eski günlerde bu kaynak, diğer işlemcilerde daha doğru okumalar elde etmek için yazılım tarafından ayarlanan kademeli zaman kaymasını hariç tutmazdı. İşlemci geliştirme konusunda uzman bir mühendise göre, TSC kullanılırken zaman kaymalarına ilişkin korkular uzun süredir doğru değil ve modern işlemcilerde bu kaynak, yıllarca istikrarlı okumalar üretebiliyor.
Netflix'teki üretim sunucularının bir TSC kaynağına geçirilmesi, yazma gecikmesinde %43'lük bir azalma sağladı ve Ubuntu kullanıldığında, CentOS'u "xen" zaman kaynağıyla çalıştıran yapılandırmalardan 4 kat daha hızlı sonuçlar elde edildi. Çalışmanın sonuçları Amazon'a aktarıldı ve Amazon, resmi olarak Xen hipervizörünü temel alan AWS EC2 ortamlarında varsayılan TSC zaman kaynağının kullanılmasını önerdi (Nitro hipervizörünü temel alan ortamlarda kvm saati tavsiye edilmeye devam ediyor).
Kaynak: opennet.ru