Tair (Redis® OSS-Compatible):Yüksek bellek kullanımını giderme

Yüksek bellek kullanımına ilişkin senaryolar

Yüksek bellek kullanımı genellikle aşağıdaki üç senaryodan birine girer:

• Bellek kullanımı uzun süre yüksek seviyede kalır. Genel kural olarak bellek kullanımı %95'i aştığında müdahale etmeniz gerekir.

• Bellek kullanımı tutarlı şekilde düşüktür ancak ani şekilde yüksek seviyelere çıkar hatta zaman zaman %100'e ulaşır.

• Örneğin genel bellek kullanımı düşüktür ancak belirli bir veri düğümünün bellek kullanımı %100'e yakındır.

Bellek kullanımını azaltmak için senaryonuzla eşleşen çözümü uygulayın.

Sürekli yüksek bellek kullanımı için çözümler

1. Mevcut anahtarların iş gereksinimlerinizi karşılayıp karşılamadığını kontrol edin ve gereksiz anahtarları derhal temizleyin.

2. Büyük anahtarların dağılımını ve anahtarlar için TTL sona erme ilkelerini analiz etmek üzere önbellek analizi özelliğini kullanabilirsiniz. Daha fazla bilgi için bkz. Çevrimdışı anahtar analizi.

   1. Anahtarın makul bir TTL ilkesine sahip olup olmadığını analiz edin.

      Not

      Aşağıdaki örnekte hiçbir anahtar için sona erme süresi ayarlanmamıştır. İş ihtiyaçlarınızı değerlendirerek istemci tarafında uygun sona erme süreleri ayarlamanızı öneririz.

      Şekil 1. Anahtar sona erme süresi dağılımı örneği

   2. Büyük anahtarı değerlendirin ve uygulama tarafında bölün.

      Önbellek analizi sayfasında ayrıntıları görüntülemek için Large Key Analysis sekmesine tıklayın. Tablo anahtar adı, anahtar türü ve veri boyutu gibi bilgileri gösterir. Analiz sonuçlarını yerel makinenize indirmek için Export düğmesine tıklayabilirsiniz.

3. İş gereksinimlerinize göre maxmemory-policy parametresini yapılandırarak uygun bir tahliye ilkesi belirleyin. Özel talimatlar için bkz. Parametreleri ayarlama.

   Not

   Bir örnek için varsayılan tahliye ilkesi volatile-lru değeridir. Daha fazla bilgi için bkz. Tahliye ilkeleri.

4. hz parametresinin değerini ayarlayarak iş ihtiyaçlarınıza göre süresi dolmuş anahtarların etkin şekilde silinmesi için makul bir çalıştırma sıklığı belirleyin. Özel talimatlar için bkz. Zamanlanmış görevlerin çalıştırma sıklığını ayarlama.

   Not

   hz parametresini 100'den küçük bir değere ayarlamanızı öneririz. Daha büyük bir değer CPU kullanımını önemli ölçüde etkileyebilir. Örneğiniz Redis 5.0 veya sonraki sürümlerle uyumluysa otomatik ayarlamayı da etkinleştirebilirsiniz. Daha fazla bilgi için bkz. Arka plan görevleri için dinamik frekans kontrolünü etkinleştirme.

5. Önceki optimizasyonlardan sonra bile bellek kullanımı hala yüksekse daha fazla veriyi işlemek ve performansı artırmak için daha fazla belleğe sahip bir teknik özelliğe yükseltmeyi düşünün. Daha fazla bilgi için bkz. Örnek yapılandırmasını değiştirme.

   Not

   Örneğinizi yükseltmeden önce hedef teknik özelliklerin iş yükü gereksinimlerinizi karşılayıp karşılamadığını test etmek için kullandıkça öde bir örnek satın alabilirsiniz. Test tamamlandıktan sonra örneği serbest bırakabilirsiniz. Bir örneği nasıl serbest bırakacağınız hakkında bilgi için bkz. Kullandıkça öde örneklerini serbest bırakma.

Ani bellek artışları için çözümler

Nedenler

Bellek kullanımındaki ani artış şu nedenlerden kaynaklanabilir:

Ani bellek artışının dört nedeni vardır. Hangisinin geçerli olduğunu belirlemek için her satırdaki temel göstergeleri kullanın.

Bir veri düğümünde yüksek bellek için çözümler

Belirtiler

Küme mimarisine sahip örneklerde belirli bir veri düğümündeki yüksek bellek kullanımı aşağıdaki belirtilerle gösterilir:

• CloudMonitor'dan bir bellek kullanımı uyarısı alırsınız. Uyarı mesajı belirli bir veri düğümünün bellek kullanımının eşiği aştığını gösterir.

• Örnek tanılama raporu bellek kullanımı çarpıklığı gösterir.

• Performans izleme sayfasında genel örnek bellek kullanımının düşük olduğunu ancak belirli bir veri düğümünün bellek kullanımının yüksek olduğunu fark edersiniz.

Neden

Genel örnek bellek kullanımı düşükken belirli bir veri düğümünün kullanımı yüksekse bu durum bellek kullanımı çarpıklığını gösterir.

Çözümler

Büyük anahtarları kontrol edin ve bölün

Büyük anahtarları bulma

Var olan büyük anahtarları bulmak için çevrimdışı anahtar analizi özelliğini kullanın.

Büyük anahtarları bulmanın diğer yöntemleri için bkz. Büyük anahtarlar ve sıcak anahtarlar.

Büyük anahtarları bölme

Örneğin on binlerce üyeye sahip bir HASH anahtarını her biri makul sayıda üyeye sahip olacak şekilde birden çok küçük HASH anahtarına bölün. Bir küme örneğinde büyük anahtarları bölmek veri parçaları arasındaki bellek kullanımını dengelemeye önemli ölçüde yardımcı olabilir.

Hash etiketi kullanımını kontrol edin

Veri yoğunlaşmasına neden olan bir hash etiketi kullanıyorsanız uygulama mantığınıza göre bunu birden çok hash etiketine bölmeyi düşünün. Bu verilerin farklı veri parçalarına daha eşit şekilde dağıtılmasına yardımcı olur.

Örnek teknik özelliklerini yükseltin

Örnek teknik özelliklerini yükseltmek her bir parçanın kullanabileceği belleği artırır ve bellek çarpıklığı için geçici bir çözüm olabilir. Ayrıntılı adımlar için bkz. Örnek yapılandırmasını değiştirme.

Ek 1: Redis bellek kullanımı

Bir Redis örneğinin belleği üç ana bileşenden oluşur:

Ek 2: Bellek kullanımını kontrol etme

 1) "peak.allocated" // The peak memory consumed by the Redis process since startup.
 2) (integer) 79492312
 3) "total.allocated" // The total number of bytes allocated by Redis, which is the current total memory usage.
 4) (integer) 79307776
 5) "startup.allocated" // The initial amount of memory consumed by Redis at startup.
 6) (integer) 45582592
 7) "replication.backlog" // The size of the replication backlog buffer.
 8) (integer) 33554432
 9) "clients.slaves" // The total size of read and write buffers for all replica nodes in master-replica replication.
10) (integer) 17266
11) "clients.normal" // The total size of read and write buffers for all regular clients (excluding replica nodes).
12) (integer) 119102
13) "aof.buffer" // The buffer used for AOF persistence and the buffer generated during AOF rewrite.
14) (integer) 0
15) "db.0"  // The number of business databases.
16) 1) "overhead.hashtable.main" // The total memory overhead for the hash tables of the current database, which is the metadata memory.
    2) (integer) 144
    3) "overhead.hashtable.expires" // The memory consumed to store key expiration times.
    4) (integer) 0
17) "overhead.total" // The sum of all overhead memory. Calculated as: startup.allocated + replication.backlog + clients.slaves + clients.normal + aof.buffer + db.X.
18) (integer) 79273616
19) "keys.count" // The total number of keys in the current Redis instance.
20) (integer) 2
21) "keys.bytes-per-key" // The average size of each key in the current Redis instance. Calculated as: (total.allocated - startup.allocated) / keys.count.
22) (integer) 16862592
23) "dataset.bytes" // The size of memory occupied by pure business data.
24) (integer) 34160
25) "dataset.percentage" // The percentage of memory occupied by pure business data. Calculated as: dataset.bytes * 100 / (total.allocated - startup.allocated).
26) "0.1012892946600914"
27) "peak.percentage" // The ratio of the current total memory to the historical peak memory. Calculated as: total.allocated * 100 / peak.allocated.
28) "99.767860412597656"
29) "fragmentation" // The memory fragmentation ratio.
30) "0.45836541056632996"

r-bpxxxxxxxxxxxxxxxxxxxx.redis.rds.aliyuncs.com:6379> MEMORY DOCTOR
"Sam, I detected a few issues in this Redis instance memory implants:\n\n * High
 allocator RSS overhead: This instance has an RSS memory overhead is greater tha
n 1.1 (this means that the Resident Set Size of the allocator is much larger tha
n the sum what the allocator actually holds). This problem is usually due to a l
arge peak memory (check if there is a peak memory entry above in the report), yo
u can try the MEMORY PURGE command to reclaim it.\n\nI'm here to keep you safe,
 Sam. I want to help you.\n"

    int empty = 0;     /* Instance is empty or almost empty. */
    int big_peak = 0;       /* Memory peak is much larger than used memory. */
    int high_frag = 0;      /* High fragmentation. */
    int high_alloc_frag = 0;/* High allocator fragmentation. */
    int high_proc_rss = 0;  /* High process RSS overhead. */
    int high_alloc_rss = 0; /* High RSS overhead from the allocator. */
    int big_slave_buf = 0;  /* Replica buffers are too big. */
    int big_client_buf = 0; /* Client buffers are too big. */
    int many_scripts = 0;   /* Script cache has too many scripts. */

MEMORY USAGE Key0089393003

(integer) 1000072