Redis için Azure Cache gecikme süresi ve zaman aşımı sorunlarını giderme

  • Makale

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 geldiği, nedenini ve çözümünü belirlemeye yardımcı olur.

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

Dekont

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 Ek bilgiler bölümündeki makalelere bakın.

İstemci tarafı sorun giderme

burada istemci tarafı sorun giderme adımları yer alır.

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

Kötü ThreadPool ayarlarla birleştirilen trafik artışları, Redis sunucusu tarafından önceden gönderilen ancak istemci tarafında henüz tüketilmeyen verilerin işlenmesinde gecikmelere neden olabilir. İstemci konaklarınızın ani trafik artışına ayak uydurabileceğini doğrulamak için "Hatalar" ölçümünü (Tür: UnresponsiveClients) denetleyin.

ÖrneğiniThreadPoolLogger kullanarak istatistiklerinizin ThreadPool zaman içinde nasıl değiştiğini izleyin. 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 bölümünde değerinden WORKER daha büyük Min bir Busy değere sahip olduğunu görebilirsiniz. Bu fark, ayarlarınızın ThreadPool ayarlanması gerektiği anlamına gelir.
  • öğesini de görebilirsiniz in: 64221. 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 verileri sunucu size gönderdiği kadar hızlı okumadığını gösterir.

Ayarlar yapılandırarak ThreadPool iş parçacığı havuzunuzun hızlı bir şekilde genişlemesini sağlayabilirsiniz.

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ğerler göz önünde bulundurun.

Önbelleğinizde büyük anahtarları denetlemek için komutunu kullanabilirsiniz redis-cli --bigkeys . 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 geçerli 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 hepsini bir kez deneme yaklaşımı kullanma

İstemci konaklarında yüksek CPU

Yüksek istemci CPU kullanımı, sistemin kendisine atanan çalışmaya ayak uyduramazsınız. Önbellek yanıtı hızlı bir şekilde gönderse de, istemci 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 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. Tek bir işlem düşük CPU kullanımına sahip olabileceğinden ancak sistem genelinde CPU yüksek olabileceğinden işlem CPU'sunu izlememeye dikkat edin. CPU kullanımında zaman aşımlarına karşılık gelen ani artışları izleyin. Yüksek CPU, [Trafik artışı] bölümünde açıklandığı gibi hata iletilerinde TimeoutException de yüksek in: XXX değerlere neden olabilir.

Dekont

StackExchange.Redis 1.1.603 ve üzeri, hata iletilerinde TimeoutException ölçümü içerirlocal-cpu. StackExchange.Redis NuGet paketinin en son sürümünü kullandığınızdan emin olun. Hatalar, zaman aşımlarına karşı daha sağlam hale getirmek için kodda 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 konaklarında ağ bant genişliği sınırlaması

İstemci makinelerinin mimarisine bağlı olarak, kullanılabilir ağ bant genişliği miktarıyla 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.

Bir örnek BandwidthLoggerkullanarak Bant genişliği kullanımınızın zaman içinde nasıl değiştiğini izleyin. Bu kod, kısıtlı izinlere sahip bazı ortamlarda (Azure web siteleri gibi) başarıyla çalışmayabilir.

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 tarafından barındırılan istemci uygulamaları için TCP ayarları

RedisSessionStateProvider yeniden deneme zaman aşımı

kullanıyorsanız RedisSessionStateProvider, yeniden deneme zaman aşımını doğru ayarladığınızdan emin olun. Değer değerinden retryTimeoutInMillisecondsoperationTimeoutInMilliseconds yüksek olmalıdır. Aksi takdirde, yeniden deneme gerçekleşmez. Aşağıdaki örnekte retryTimeoutInMilliseconds 3000 olarak ayarlanmıştır. Daha fazla bilgi için bkz. Redis için Azure Cache için oturum durumu sağlayıcısı ASP.NET ve 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.redis.cache.windows.net"
    port="6380"
    accessKey="..."
    ssl="true"
    databaseId="0"
    applicationName="AFRedisCacheSessionState"
    connectionTimeoutInMilliseconds = "5000"
    operationTimeoutInMilliseconds = "1000"
    retryTimeoutInMilliseconds="3000"
>

Sunucu tarafı sorun giderme

Sunucu tarafı sorun giderme adımları aşağıdadır.

Hizmet 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ğinde yanıt almayan bir işlem zaman aşımı özel durumuyla karşılanabilir. 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 şu diğer bölümlere bakın:

Zaman aşımları oluştuğu sırada Redis için Azure Cache yük devretmesi olup olmadığını denetlemek için Hatalar ölçümünü denetleyin. Azure portalının Kaynak menüsünde Ölçümler'i seçin. Ardından ölçümü ölçen ve ölçütüne Errors göre bölünmüş ErrorTypeyeni bir grafik oluşturun. Bu grafiği oluşturduktan sonra Yük Devretme için bir sayı görürsünüz.

Yük devretmeler hakkında daha fazla bilgi için bkz. Redis için Azure Cache için yük devretme ve düzeltme eki uygulama.

Yüksek sunucu yükü

Yüksek sunucu yükü, Redis sunucusunun isteklere ayak uyduramadığı ve zaman aşımlarına neden olduğu anlamına gelir. Sunucu yavaş yanıt veriyor ve isteklerin hızına yetişemiyor olabilir.

Sunucu yükü gibi ölçümleri izleyin. Kullanımda Server Load zaman aşımlarına karşılık gelen ani artışları izleyin. Olası etkiler hakkında erken bildirim almak için sunucu yükündeki ölçümler üzerinde uyarılar oluşturun.

Yüksek sunucu yükü 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 sunucu yüküne neyin neden olduğunu araştırın.
  • Birden çok Redis işlemine yük dağıtmak için ölçeği genişleterek daha fazla parçaya veya daha fazla CPU çekirdeğiyle daha büyük bir önbellek boyutuna ölçeklendirin. Daha fazla bilgi için bkz. Redis için Azure Cache planlama hakkında SSS.
  • C1 önbelleğindeki üretim iş yükünüz virüs taramasından kaynaklanan ek gecikme süresinden olumsuz etkileniyorsa, C2 gibi birden çok CPU çekirdeğine sahip daha yüksek katman teklifi için ödeme yaparak etkisini azaltabilirsiniz.

Sunucu yükündeki ani artışlar

C0 ve C1 önbelleklerinde, vm'lerde virüs taraması çalışırken isteklerde birkaç kez artışa neden olmayan sunucu yükünde kısa ani artışlar görebilirsiniz. Bu katmanlarda virüs taraması yapılırken istekler için daha yüksek gecikme süresi görürsünüz. C0 ve C1 katmanlarında önbellekler, virüs tarama ve Redis istekleri sunma işini bölerek çoklu görev için yalnızca tek bir çekirdeğe sahiptir.

Yüksek bellek kullanımı

Bu bölüm taşındı. Daha fazla bilgi için bkz . Yüksek bellek kullanımı.

Uzun süre çalışan komutlar

Bazı Redis komutlarının yürütülmesi diğerlerinden daha uzun sürer. Redis komutları belgelerinde her komutun zaman karmaşıklığı gösterilir. Redis komut işlemesi tek iş parçacıklı bir işlemedir. Çalıştırılması uzun süren tüm komutlar, ondan sonra gelen diğer tüm komutları 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ğunu bilmeden kullanılır. CPU ani artışlarını azaltmak için SCAN kullanarak ANAHTARLARDAN kaçınabilirsiniz.

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

Müşteriler, uzun süre çalışan ve pahalı komutları araştırmak üzere 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, komutunu kullanarak Redis sunucularında yürütülen pahalı komutları ölçebilir/günlüğe SLOWLOG 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 bilgisayarlara göre ayrıştırmaya ve insanlar tarafından okunmaya kolay bir biçimde döndürür. Bu durumda CPU bölümü CPU kullanımını araştırmak için yararlı olabilir. 100 sunucu yükü (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.

Çıkış ö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İ - çoğunlukla okunabilir bir biçimde istemci bağlantıları sunucusu hakkındaki bilgileri ve istatistikleri 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şarsa veriler istemciye hemen 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. Bu ölçümleri portalda 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