Azure Yönetilen Redis gecikme süresi ve zaman aşımlarıyla ilgili sorunları giderme

  • Şunlara uygulanır: ✅ Azure Managed Redis

Zamanında yanıt almayan bir istemci işlemi, yüksek gecikme süresi veya zaman aşımı özel durumuyla sonuçlanabilir. Bir işlem çeşitli aşamalarda zaman aşımına uğrayabilir. Zaman aşımının nereden kaynaklandığı, sebebini ve nasıl bir önlem alınabileceğini belirlemeye yardımcı olur.

Bu bölümde, Azure Managed Redis'e bağlanırken oluşan gecikme süresi ve zaman aşımı sorunlarının giderilmesi ele alınmaktadır.

Uyarı

Bu kılavuzdaki sorun giderme adımlarından bazıları Redis komutlarını çalıştırma ve çeşitli performans ölçümlerini izleme yönergelerini içerir. Daha fazla bilgi ve yönergeler için bkz. Ek bilgiler bölümündeki makaleler.

İstemci tarafında sorun giderme

Burada istemci tarafında sorun giderme açıklanmaktadır.

Ani trafik artışı ve iş parçacığı havuzu yapılandırması

Ani trafik artışı hatalı ThreadPool ayarlarıyla bir araya geldiğinde, Redis sunucusu tarafından zaten gönderilmiş ama istemci tarafında henüz tüketilmemiş olan verilerin işlenmesinde gecikmelere yol açabilir. İstemci sunucularınızın ani trafik artışlarına ayak uydurup uyduramadığını doğrulamak için "Hatalar" ölçümünü (Tür: UnresponsiveClients) kontrol edin.

StackExchange.Redis'ten gelen iletileri daha fazla araştırmak için kullanabilirsiniz TimeoutException :

    System.TimeoutException: Timeout performing EVAL, inst: 8, mgr: Inactive, queue: 0, qu: 0, qs: 0, qc: 0, wr: 0, wq: 0, in: 64221, ar: 0,
    IOCP: (Busy=6,Free=999,Min=2,Max=1000), WORKER: (Busy=7,Free=8184,Min=2,Max=8191)

Yukarıdaki özel durumda, ilginç olan birkaç sorun vardır:

  • IOCP bölümünde ve WORKER bölümünde Busy değerinden daha büyük bir Min değerine sahip olduğunuzu görebilirsiniz. Bu fark, ThreadPool ayarlarınızın yapılması gerektiği anlamına gelir.
  • Ayrıca in: 64221 değerini de görebilirsiniz. Bu değer, istemcinin çekirdek yuva katmanında 64.221 bayt alındığını ancak uygulama tarafından okunmadığını gösterir. Bu fark genellikle uygulamanızın (örneğin, StackExchange.Redis) ağdan gelen verileri sunucunun size gönderdiği kadar hızlı okumadığını gösterir.

ThreadPool Ayarlarınızı, iş parçacığı havuzunuzun ani yüklenme senaryolarında hızlı bir şekilde ölçeklenmesini sağlamak için yapılandırabilirsiniz.

Büyük anahtar değeri

Birden çok anahtar ve daha küçük değerler kullanma hakkında bilgi için bkz. Daha fazla anahtar ve daha küçük değerleri kullanın.

Önbelleğinizde büyük anahtarları denetlemek için redis-cli --bigkeys komutunu kullanabilirsiniz. Daha fazla bilgi için bkz. redis-cli, Redis komut satırı arabirimi--Redis.

  • Daha yüksek bant genişliği özellikleri elde etmek için VM'nizin boyutunu artırın
    • İstemci veya sunucu VM'nizde daha fazla bant genişliği, daha büyük yanıtlar için veri aktarım sürelerini azaltabilir.
    • Her iki makinedeki mevcut ağ kullanımınızı geçerli VM boyutunuzun sınırlarıyla karşılaştırın. Yalnızca sunucuda veya yalnızca istemcide daha fazla bant genişliği yeterli olmayabilir.
  • Uygulamanızın kullandığı bağlantı nesnelerinin sayısını artırın.
    • Farklı bağlantı nesneleri üzerinden istekte bulunmak için döngüsel yaklaşımı kullanın.

İstemci konaklarında yüksek CPU kullanımı

Yüksek istemci CPU kullanımı sistemin kendisine atanan çalışmayı yapmaya yetişemediğini gösterir. Önbellek hızla yanıt göndermiş olsa bile istemci bu yanıtı zamanında işleyemeyebilir. Önerimiz, istemci CPU'sunun %80'in altında tutulmasıdır. İstemci konaklarınızın Redis sunucusundan gelen yanıtları zamanında işleyebilir durumda olup olmadığını belirlemek için "Hatalar" (Tür: UnresponsiveClients) ölçümünü denetleyin.

Azure portalında veya makinedeki performans sayaçları aracılığıyla sağlanan ölçümleri kullanarak istemcinin sistem genelindeki CPU kullanımını izleyin. İşlem CPU'sunu izlememeye dikkat edin çünkü tek bir işlem düşük CPU kullanımına sahip olabilir ancak sistem genelindeki CPU yüksek olabilir. CPU kullanımında zaman aşımlarına karşılık gelen ani artışları izleyin. Yüksek CPU, [in: XXX] bölümünde açıklandığı gibi TimeoutException hata iletilerinde de yüksek değerlere neden olabilir.

Uyarı

StackExchange.Redis 1.1.603 ve üzeri, local-cpu hata iletilerinde TimeoutException ölçümünü içerir. StackExchange.Redis NuGet paketinin en son sürümünü kullandığınızdan emin olun. Zaman aşımlarına karşı daha sağlam hale getirmek için kodda hatalar düzenli olarak düzeltilir. En son sürüme sahip olmak önemlidir.

İstemcinin yüksek CPU kullanımını azaltmak için:

  • CPU ani artışlarına neyin neden olduğunu araştırın.
  • İstemcinizi daha fazla CPU kapasitesiyle daha büyük bir VM boyutuna yükseltin.

İstemci makinelerinde ağ bant genişliği sınırlaması

İstemci makinelerinin mimarisine bağlı olarak kullanılabilir ağ bant genişliğiyle ilgili sınırlamalar olabilir. İstemci ağ kapasitesini aşırı yükleyerek kullanılabilir bant genişliğini aşarsa, veriler sunucunun gönderdiği hızda istemci tarafında işlenemeyebilir. Bu durum, zaman aşımlarına neden olabilir.

Azaltmak için ağ bant genişliği tüketimini azaltın veya istemci VM boyutunu daha fazla ağ kapasitesine sahip bir VM'ye artırın. Daha fazla bilgi için bkz. Büyük istek veya yanıt boyutu.

Linux tabanlı istemci uygulamaları için TCP ayarları

Linux'taki iyimser TCP ayarları nedeniyle Linux'ta barındırılan istemci uygulamaları bağlantı sorunlarıyla karşılaşabilir. Daha fazla bilgi için bkz. Linux'ta barındırılan istemci uygulamaları için TCP ayarları

RedisSessionStateProvider yeniden deneme zaman aşımı

RedisSessionStateProvider kullanıyorsanız yeniden deneme zaman aşımını doğru ayarladığınızdan emin olun. retryTimeoutInMilliseconds değerinin operationTimeoutInMilliseconds değerinden daha yüksek olması gerekir. Aksi takdirde, yeniden deneme gerçekleşmez. Aşağıdaki örnekte retryTimeoutInMilliseconds değeri 3000 olarak ayarlanmıştır. Daha fazla bilgi için Oturum Durumu Sağlayıcısı ve Çıkış Önbelleği Sağlayıcısı yapılandırma parametrelerini kullanma.

<add 
    name="AFRedisCacheSessionStateProvider"
    type="Microsoft.Web.Redis.RedisSessionStateProvider"
    host="enbwcache.eastus.redis.azure.net"
    port="10000"
    accessKey="..."
    ssl="true"
    databaseId="0"
    applicationName="AFRedisCacheSessionState"
    connectionTimeoutInMilliseconds = "5000"
    operationTimeoutInMilliseconds = "1000"
    retryTimeoutInMilliseconds="3000"
>

Sunucu tarafında sorun giderme

Sunucu bakımı

Planlı veya plansız bakım istemci bağlantılarında kesintilere neden olabilir. Özel durumların sayısı ve türü isteğin kod yolundaki konumuna ve önbelleğin bağlantılarını ne zaman kapattığına bağlıdır. Örneğin, bir istek gönderen ancak yük devretme gerçekleştiği anda yanıt almayan bir işlem zaman aşımı hatası yaşayabilir. Kapatılan bağlantı nesnesinde yeni istekler, yeniden bağlantı başarıyla gerçekleşene kadar bağlantı özel durumları alır.

Daha fazla bilgi için bkz. Bağlantı dayanıklılığı.

Yüksek CPU

Yüksek CPU, Redis sunucusunun isteklere yetişemediği anlamına gelir; bu da zaman aşımlarına yol açar. Sunucu yavaş yanıt veriyor ve isteklerin hızına yetişemiyor olabilir.

CPU gibi ölçümleri izleyin. CPU kullanımında zaman aşımlarına karşılık gelen ani yükselişlere dikkat edin. Olası etkileri hakkında önceden bilgi sahibi olmak için CPU'daki ölçümlerle ilgili uyarılar oluşturun.

Yüksek CPU sorunlarını gidermek için yapabileceğiniz birkaç değişiklik vardır:

  • Yüksek bellek baskısı nedeniyle, bu makalede belirtilen uzun süre çalışan komutlar gibi yüksek CPU'ya neyin neden olduğunu araştırın.
  • Yükü birden çok Redis işlemine dağıtmak için ek kapsamlar oluşturarak ölçeği genişletin veya ölçeği artırarak daha fazla CPU çekirdeğine sahip daha büyük bir önbelleğe geçin. Daha fazla bilgi için, bkz. Azure Managed Redis mimarisi.
  • Önbellekteki üretim iş yükünüz, bazı dahili savunucu tarama çalıştırmalarından kaynaklanan ek gecikme süresinden olumsuz etkileniyorsa, önbelleği hesaplama için optimize edilmiş katmana geçirerek veya daha fazla CPU çekirdeğine sahip daha üst düzey bir hizmete ölçeklendirerek bu etkinin azalmasını sağlayabilirsiniz.

CPU'daki ani artışlar

B0, B1, B3 ve B5 önbelleklerinde, iç defender taraması VM'lerde çalışırken CPU'da günde birkaç kez istek artışından kaynaklanmayan kısa ani artışlar görebilirsiniz. Bu katmanlarda dahili savunma taramaları gerçekleşirken isteklerde daha yüksek gecikme görürsünüz. Bu katmanlardaki önbellekler, dahili savunucu taraması ve Redis isteklerine hizmet etme işini bölerek çoklu görev yapmak için yalnızca iki çekirdeğe sahiptir.

Yüksek bellek kullanımı

Daha fazla bilgi için bkz. Yüksek bellek kullanımı.

Uzun süren komutlar

Bazı Redis komutlarının yürütülmesi diğerlerinden daha uzun sürer. Redis komutları belgelerinde her komutun zaman açısından karmaşıklığı gösterilir. Redis komut işlemesi tek iş parçacıklı bir işlemedir. Uzun süre çalışan herhangi bir komut, onu izleyen diğer tüm komutların çalışmasını engelleyebilir.

Performans etkilerini anlamak için Redis sunucunuza vermekte olduğunuz komutları gözden geçirin. Örneğin KEYS komutu genellikle bunun bir O(N) işlemi olduğu bilinmeden kullanılır. CPU ani artışlarını azaltmak için SCAN komutunu kullanarak KEYS komutundan kaçınabilirsiniz.

SLOWLOG GET komutunu kullanarak sunucuda yürütülen maliyetli komutları ölçebilirsiniz.

Müşteriler, uzun süre çalışan ve maliyetli komutları araştırmak amacıyla bu Redis komutlarını çalıştırmak için bir konsol kullanabilir.

  • SLOWLOG, Redis yavaş sorgu günlüğünü okumak ve sıfırlamak için kullanılır. İstemci tarafında uzun süre çalışan komutları araştırmak için kullanılabilir. Redis Yavaş Günlüğü, belirtilen yürütme süresini aşan sorguları günlüğe kaydeden bir sistemdir. Yürütme süresi istemciyle konuşma, yanıt gönderme vb. G/Ç işlemlerini içermez ancak yalnızca komutu gerçekten yürütmek için gereken süreyi içerir. Müşteriler, SLOWLOG komutunu kullanarak Redis sunucularında çalıştırılan fazla kaynak tüketen komutları ölçebilir/günlüğe kaydedebilir.
  • MONITOR, Redis sunucusu tarafından işlenen her komutun akışını geri alan bir hata ayıklama komutudur. Bu, veritabanında neler olduğunu anlamanıza yardımcı olabilir. Bu komut zorludur ve performansı olumsuz etkileyebilir. Performansı düşürebilir.
  • BİlGİ: Komut, sunucu hakkındaki bilgileri ve istatistikleri bilgisayarlar tarafından ayrıştırılması ve insanlar tarafından okunması kolay bir biçimde döndürür Bu durumda CPU bölümü, CPU kullanımını incelemek için yararlı olabilir. 100 CPU değeri (en yüksek değer), Redis sunucusunun sürekli meşgul olduğunu ve istekleri işlerken hiçbir zaman boşta olmadığını gösterir.

Çıktı örneği:

# CPU
used_cpu_sys:530.70
used_cpu_user:445.09
used_cpu_avg_ms_per_sec:0
server_load:0.01
event_wait:1
event_no_wait:1
event_wait_count:10
event_no_wait_count:1
  • İSTEMCİ LİSTESİ: İstemci bağlantıları sunucusu hakkındaki bilgileri ve istatistikleri çoğunlukla okunabilir bir biçimde döndürür.

Ağ bant genişliği sınırlaması

Farklı önbellek boyutlarının farklı ağ bant genişliği kapasiteleri vardır. Sunucu kullanılabilir bant genişliğini aşıyorsa veriler istemciye o kadar hızlı gönderilmez. Sunucu verileri istemciye yeterince hızlı gönderemediğinden istemci istekleri zaman aşımına uğrayabilir.

Kullanılan sunucu tarafı bant genişliğinin miktarını görmek için "Önbellek Okuması" ve "Önbellek Yazması" ölçümleri kullanılabilir. Portalda bu ölçümleri görüntüleyebilirsiniz. Olası etkileri hakkında önceden bilgi sahibi olmak için bellek okuma veya bellek yazma gibi ölçümlerle ilgili uyarılar oluşturun.

Ağ bant genişliği kullanımının maksimum kapasiteye yakın olduğu durumları azaltmak için:

StackExchange.Redis zaman aşımı özel durumları

StackExchange.Redis kullanırken zaman aşımlarıyla ilgili daha ayrıntılı bilgi için bkz. StackExchange.Redis'te zaman aşımı özel durumlarını araştırma.

İlgili içerik

  • Last updated on