Container Service for Kubernetes:Use the nearby memory access acceleration feature on multi-NUMA instances

Ön koşullar

Başlamadan önce aşağıdakilere sahip olduğunuzdan emin olun:

• Kubernetes 1.18 veya sonraki bir sürümü çalıştıran bir ACK Pro kümesi. Daha fazla bilgi için bkz. ACK yönetilen kümesi oluşturma.

• Kümeyle bağlantı kurmuş bir kubectl istemcisi. Daha fazla bilgi için bkz. Kümenin kubeconfig dosyasını alma ve kubectl ile kümeye bağlanma.

• ack-koordinator (eski adıyla ack-slo-manager) 1.2.0-ack1.2 veya sonraki bir sürümün yüklü olması. Daha fazla bilgi için bkz. ack-koordinator (eski adıyla ack-slo-manager).

  Not

  ack-koordinator, resource-controller'daki tüm özellikleri içerir. Şu anda resource-controller kullanıyorsanız, ack-koordinator'u yüklemeden önce bunu kaldırın. Daha fazla bilgi için bkz. resource-controller'ı kaldırma.

• ecs.ebmc, ecs.ebmg, ecs.ebmgn, ecs.ebmr, ecs.ebmhfc veya ecs.scc örnek ailelerinden 5., 6., 7. veya 8. nesil Elastic Compute Service (ECS) örnekleri ve bunların çoklu NUMA örnekleri olarak dağıtılmış olması.

  Not

  Özellik, ecs.ebmc8i.48xlarge, ecs.c8i.32xlarge ve ecs.g8i.48xlarge türlerindeki 8. nesil ECS örneklerinde en iyi performansı gösterir. Daha fazla bilgi için bkz. ECS örnek aileleri.

• Topoloji duyarlı CPU zamanlaması kullanılarak CPU çekirdeklerinin bağlandığı, çoklu NUMA örnekleri üzerinde dağıtılan uygulamalar. Daha fazla bilgi için bkz. Topoloji duyarlı CPU zamanlamasını etkinleştirme.

Faturalama

ack-koordinator'u yüklemek veya kullanmak için ücret alınmaz. Ancak aşağıdaki senaryolarda ücretlendirme söz konusu olabilir:

• ack-koordinator, kurulduktan sonra worker düğüm kaynaklarını tüketen yönetilmeyen bir bileşendir. Kurulum sırasında her modülün talep edeceği kaynak miktarını belirtebilirsiniz.

• Varsayılan olarak ack-koordinator, izleme ölçümlerini (kaynak profilleme ve ayrıntılı zamanlama ölçümleri gibi) Prometheus ölçümleri olarak sunar. ack-koordinator için Prometheus ölçümlerini etkinleştirir ve Managed Service for Prometheus kullanırsanız, bu ölçümler özel ölçümler olarak sayılır ve ücretlendirilir. Etkinleştirmeden önce ücretsiz kota ve faturalama kurallarını anlamak için Managed Service for Prometheus'a ait Faturalama konusunu okuyun. Daha fazla bilgi için bkz. Gözlemlenebilir veri miktarını ve faturaları sorgulama.

Nasıl çalışır?

Çoklu NUMA mimarisinde, bir NUMA düğümünün sanal çekirdeğinde çalışan işlemlerin uzak bir NUMA düğümündeki belleğe erişmesi gerekebilir. Bu tür düğümler arası erişim QPI veri yolu üzerinden gerçekleşir ve yerel bellek erişimine göre daha uzun sürer. Yüksek bellek yükü altında—örneğin, aynı NUMA düğümündeki birlikte çalışan iş yükleri yerel belleği tükettiğinde—bir uygulamanın bellek sayfaları uzak bir NUMA düğümüne itilebilir. Bu durum yerel bellek isabet oranını düşürür ve performansı olumsuz etkiler.

ack-koordinator, bu çalışma zamanı bellek kaymasını giderir. Bir pod için bellek yerelliği etkinleştirildiğinde, her düğümdeki koordlet aracısı, pod'un hangi bellek sayfalarının uzak NUMA düğümlerinde bulunduğunu tespit eder ve bunları yerel düğüme taşır. Taşıma işlemi güvenlidir; pod'un yeniden başlatılmasını veya trafiğin kesilmesini gerektirmez.

Redis çalıştıran bir ecs.ebmc8i.48xlarge örneği üzerinde yapılan kıyaslamalar, tamamen yerel bellek kullanımının, rastgele dağıtılmış belleğe göre %10,52 daha yüksek QPS ve tamamen uzak belleğe göre %26,12 daha yüksek QPS sağladığını göstermektedir.

Kullanım senaryoları

Yakındaki bellek erişimi hızlandırma özelliği aşağıdakiler için uygundur:

• Bellek yoğunluklu iş yükleri — Büyük ölçekli Redis in-memory veritabanları ve bellek erişimi gecikmesinin doğrudan aktarım hızını etkilediği benzeri iş yükleri.

• DSA destekli ECS örnekleri — Intel Data Streaming Accelerator (DSA) ile entegre edilmiş ECS örnekleri, özellik performansını iyileştirebilir ve CPU tüketimini azaltabilir.

Sınırlamalar

• Örnek NUMA olmayan bir mimari kullanıyorsa veya işlem tüm NUMA düğümlerinde çalışıyorsa özellik atlanır. Her iki durumda da taşıma yapılacak bir uzak NUMA düğümü bulunmaz.

• Taşıma sırasında bir işlem sonlandırılırsa, ilgili işlemin taşıması başarısız olur. ack-koordinator, başarısız olan işlem kimliğini pod olayına kaydeder ve diğer işlemlerin taşınmasına devam eder.

• Periyodik hızlandırma kullanılırken (migrateIntervalMinutes > 0), yerel bellek oranındaki değişim veya hızlandırma sonucu %10'u aştığında yalnızca bir olay kaydedilir.

Yakındaki bellek erişimi hızlandırmayı etkinleştirin

kubectl annotate pod <pod-name> koordinator.sh/memoryLocality='{"policy": "bestEffort"}' --overwrite

kubectl describe pod <pod-name>

kubectl annotate pod <pod-name> koordinator.sh/memoryLocality='{"policy": "bestEffort","migrateIntervalMinutes":10}' --overwrite

Kıyaslama: Redis üzerindeki performans etkisi

Bu bölümde ecs.ebmc8i.48xlarge ve ecs.ebmg7a.64xlarge örnek türlerine ait kıyaslama sonuçları açıklanmaktadır.

Test ortamı

• Test edilen makineler: Redis uygulaması çalıştıran ecs.ebmc8i.48xlarge ve ecs.ebmg7a.64xlarge örnekleri

• Redis uygulaması: Çoklu iş parçacıklı, 4 sanal çekirdek, 32 GB bellek (görüntü: redis:6.0.5)

• Stres testi makinesi: Test edilen makineye istek gönderen ayrı bir makine

  Not

  Daha düşük teknik özelliklere sahip test makineleri için tek iş parçacıklı bir Redis örneği dağıtın ve CPU ile bellek isteklerini buna göre azaltın.

Test prosedürü

1. Aşağıdaki YAML kullanarak bir Redis uygulaması dağıtın. Test makinenizin teknik özellikleriyle eşleşecek şekilde redis-config değerini ayarlayın.

   ---
   kind: ConfigMap
   apiVersion: v1
   metadata:
     name: example-redis-config
   data:
     redis-config: |
       maxmemory 32G
       maxmemory-policy allkeys-lru
       io-threads-do-reads yes
       io-threads 4
   ---
   kind: Service
   apiVersion: v1
   metadata:
     name: redis
   spec:
     type: NodePort
     ports:
       - port: 6379
         targetPort: 6379
         nodePort: 32379
     selector:
       app: redis
   ---
   apiVersion: v1
   kind: Pod
   metadata:
     name: redis
     annotations:
       cpuset-scheduler: "true"        # Bind vCores using topology-aware CPU scheduling
     labels:
       app: redis
   spec:
     containers:
     - name: redis
       image: redis:6.0.5
       command: ["bash", "-c", "redis-server /redis-master/redis.conf"]
       ports:
       - containerPort: 6379
       resources:
         limits:
           cpu: "4"                    # Adjust based on test machine specifications
       volumeMounts:
       - mountPath: /redis-master-data
         name: data
       - mountPath: /redis-master
         name: config
     volumes:
       - name: data
         emptyDir: {}
       - name: config
         configMap:
           name: example-redis-config
           items:
           - key: redis-config
             path: redis.conf

2. Uzak NUMA bellek kaymasını simüle etmek için bellek yükünü artırın.

   1. Aşağıdaki kabuk betiğini kullanarak Redis'e iş verisi yazın. Betik, verileri ardışık düzenler (pipelines) aracılığıyla toplu iş olarak yazar. <max-out-cir> ve <max-in-cir> değerlerini kurulumunuz için uygun değerlerle değiştirin. 4 sanal çekirdekli, 32 GB'lık bir Redis örneği için max-out-cir=300 ve max-in-cir=1000000 kullanın.

      Not

      Büyük hacimli veri yazmak zaman alır. Yazma hızını en üst düzeye çıkarmak için betiği test edilen makinede çalıştırın.

      for((j=1;j<=<max-out-cir>;j++))
      do
              echo "set k$j-0 v$j-0" > data.txt
              for((i=1;i<=<max-in-cir>;i++))
              do
                      echo "set k$j-$i v$j-$i" >> data.txt
              done
              echo "$j"
              unix2dos data.txt  # Pipeline writes require DOS format
              cat data.txt | redis-cli --pipe -h <redis-server-IP> -p <redis-server-port>
      done

      Veri yazılırken, bellek kaymasını simüle etmek için aynı NUMA düğümündeki birlikte çalışan iş yüklerinin bellek yükünü artırın. İş yüklerini belirli bir NUMA düğümüne bağlamak için numactl --membind kullanın.

   2. Bellek baskısını artırmak için aşağıdaki komutu çalıştırın. <workers-num> değerini stres işlemi sayısı ile ve <malloc-size-per-workers> değerini işlem başına ayrılan bellek miktarıyla değiştirin.

      Not

      Sanal çekirdekler Redis pod'una bağlandığından, yerel bellek tükenip taşma uzak NUMA düğümlerine yayılana kadar yerel NUMA belleği öncelikli olarak ona ayrılır. NUMA düğümü başına bellek kullanımını kontrol etmek ve parametreleri buna göre ayarlamak için numactl -H komutunu çalıştırın.

      numactl --membind=<numa-id> stress -m <workers-num> --vm-bytes <malloc-size-per-workers>

3. Hızlandırma devre dışı ve etkin durumdayken stres testleri çalıştırın.

   1. Hızlandırma devre dışıyken stres testi

      redis-server üzerinde orta ve yüksek düzeyde yük oluşturmak için stres testi makinesinden istekler gönderin.

      • 500 eşzamanlı istek (orta yük):

        redis-benchmark -t GET -c 500 -d 4096 -n 2000000 -h <redis-server-IP> -p <redis-server-port>

      • 10.000 eşzamanlı istek (yüksek yük):

        redis-benchmark -t GET -c 10000 -d 4096 -n 2000000 -h <redis-server-IP> -p <redis-server-port>

   2. Yakındaki bellek erişimi hızlandırmayı etkinleştirin

      Redis pod'u için hızlandırmayı etkinleştirmek üzere aşağıdaki komutu çalıştırın:

      kubectl annotate pod redis koordinator.sh/memoryLocality='{"policy": "BestEffort"}' --overwrite

      Taşımanın tamamlandığını doğrulayın:

      kubectl describe pod redis

      Beklenen çıktı (büyük hacimli uzak belleğin taşınması zaman alabilir):

        Normal  MemoryLocalitySuccess  0s   koordlet-resmanager  migrated memory from remote numa: 0 to local numa: 1, cur local memory ratio 98, rest remote memory pages 28586

   3. Hızlandırma etkin durumdayken stres testi

      Orta ve yüksek düzeyde yük oluşturmak için a adımındaki stres testlerini tekrarlayın.

ecs.ebmc8i.48xlarge sonuçları

Bellek dağılımı: Hızlandırmadan önce %43 yerel, hızlandırmadan sonra %98 yerel.

• 500 eşzamanlı istek

  Senaryo	P99 ms	P99.99 ms	QPS
  Hızlandırmadan önce	3	9,6	122.139,91
  Hızlandırmadan sonra	3	8,2	129.367,11

  P99 gecikme süresi değişmedi. P99.99 gecikme süresi %14,58 azaldı. QPS %5.917 arttı.

• 10.000 eşzamanlı istek

  Senaryo	P99 ms	P99.99 ms	QPS
  Hızlandırmadan önce	115	152,6	119.895,56
  Hızlandırmadan sonra	101	145,2	125.401,44

  P99 gecikme süresi %12,17 azaldı. P99.99 gecikme süresi %4,85 azaldı. QPS %4,59 arttı.

ecs.ebmg7a.64xlarge sonuçları

Bellek dağılımı: Hızlandırmadan önce %47 yerel, hızlandırmadan sonra %88 yerel.

• 500 eşzamanlı istek

  Senaryo	P99 ms	P99.99 ms	QPS
  Hızlandırmadan önce	2,4	4,4	135.180,99
  Hızlandırmadan sonra	2,2	4,4	136.296,37

  P99 gecikme süresi %8,33 azaldı. P99.99 gecikme süresi değişmedi. QPS %0,83 arttı.

• 10.000 eşzamanlı istek

  Senaryo	P99 ms	P99.99 ms	QPS
  Hızlandırmadan önce	58,2	80,4	95.757,10
  Hızlandırmadan sonra	56,6	76,8	97.015,50

  P99 gecikme süresi %2,7 azaldı. P99.99 gecikme süresi %4,4 azaldı. QPS %1,3 arttı.

Sonuç: Uygulama verilerinin uzak NUMA düğümlerine kaydığı yüksek bellek yükü altında, sanal çekirdeklerin bağlanması ve yakındaki bellek erişimi hızlandırmanın etkinleştirilmesi, hem orta hem de yüksek eşzamanlılık durumunda Redis için erişim gecikme süresini azaltır ve aktarım hızını artırır.