redisストレージ大量hashメモリ占有最適化

8877 ワード
redis
仕事の中で何気なくオンラインredisメモリの占有量が高すぎることを発見して、毎日30 Wのhset操作が足りないでしょう、200 Mredisメモリ近くを占有して、そこでテストコードを編纂して、簡単にテストして、やはり最適化することができる地方があることを発見します

1、SPRING-DATA-REDIS:SERIALIZER例


Spring-data-redisは、jedisを使用する開発者にとって非常に便利なserializerポリシーを提供しています.sdrは4種類の内蔵serializerを提供しています.
  • J d k SerializationRedisSerializer:JDKのシーケンス化手段(serializableインタフェース、ObjectInputStrean、ObjectOutputStream)を用いて、データをバイトストリームで
    • 記憶する
  • StringRedisSerializer:文字列符号化、データstring格納
  • JacksonJsonRedisSerializer:jsonフォーマットストレージ
  • OxmSerializer:xml形式ストレージ
    • ここで、JdkSerializationRedisSerializerおよびStringRedisSerializerは最も基本的なシーケンス化ポリシーであり、「JacksonJsonRedisSerializer」および「OxmSerializer」はstirngストレージに基づいているため、それらは比較的「高度」なシーケンス化(最終的にはstring解析およびjavaオブジェクトの構築)である.
    RedisTemplateでは4種類のserializerを宣言する必要があります.デフォルトは「J d k SerializationRedisSerializer」です.
    1)keySerializer:通常のK-V操作に対してkeyがとるシーケンス化ポリシー2)valueSerializer:valueがとるシーケンス化ポリシー3)hashKeySerializer:hashデータ構造においてhash-keyのシーケンス化ポリシー4)hashValueSerializer:hash-valueのシーケンス化ポリシー
    int,string,objectのシーケンス化テストにより,デフォルトのJ d k SerializationRedisSerializerシーケンス化後のバイトストリーム占有空間が最大であり,GenericJackson 2 JsonRedisSerializerに次いでStringRedisSerializerが最小であることが分かったが,StringRedisSerializerはstringのシーケンス化のみ可能である
    JdkSerializationRedisSerializer
int     >>>>>>>>>>  81
string     >>>>>>>>>>  10
object  >>>>>>>>>>  113

GenericJackson2JsonRedisSerializer
int     >>>>>>>>>>  3
string     >>>>>>>>>>  5
object  >>>>>>>>>>  27

StringRedisSerializer
string     >>>>>>>>>>  3

    参照先:https://www.cnblogs.com/yueguanguanyun/p/8283127.html

    2、HASHはどんなデータを保存してメモリを節約します


    テストにより、数字は文字列を格納するよりもメモリの消費量を節約し、数字をできるだけ使うことができます.

    2.1.Jedisのhsetリロード方法


    JAvaはredisの最下位実装を操作し、hashをredisに保存するには2つの方法があります.

    2.1.1、JedisCommandsインタフェースの下の

  • Long hset(String key, String field, String value);

    • 2.1.2、BinaryJedisCommandsインタフェースの下の

  • Long hset(byte[] key, byte[] field, byte[] value);

    • 2.2、テスト


    それぞれ文字列と文字ストリームに対応し、spring data redisパッケージのRedisTemplateは、文字ストリームの実装のみを提供しているが、下位Jedisの実装を呼び出すことで、30 Wの同じデータを挿入し、テスト結果は以下の通りであることが分かった.
    HASH subKey     code = 123      ，    BinaryJedisCommands  
>>>>>>>>>>>>>>>>begin
# Memory
used_memory:713224
used_memory_human:696.51K
used_memory_rss:655416
used_memory_peak:72374824
used_memory_peak_human:69.02M
used_memory_lua:36864
mem_fragmentation_ratio:0.92
mem_allocator:jemalloc-3.6.0

>>>>>>>>>>>>>>>>after
# Memory
used_memory:162700776
used_memory_human:155.16M
used_memory_rss:162599336
used_memory_peak:162700776
used_memory_peak_human:155.16M
used_memory_lua:36864
mem_fragmentation_ratio:1.00
mem_allocator:jemalloc-3.6.0

    ： time = 25609 ms




HASH subKey      "123"，    BinaryJedisCommands     
>>>>>>>>>>>>>>>>begin
# Memory
used_memory:713224
used_memory_human:696.51K
used_memory_rss:655416
used_memory_peak:72374824
used_memory_peak_human:69.02M
used_memory_lua:36864
mem_fragmentation_ratio:0.92
mem_allocator:jemalloc-3.6.0

>>>>>>>>>>>>>>>>after
# Memory
used_memory:71500776
used_memory_human:68.19M
used_memory_rss:71265080
used_memory_peak:72374824
used_memory_peak_human:69.02M
used_memory_lua:36864
mem_fragmentation_ratio:1.00
mem_allocator:jemalloc-3.6.0

    ： time = 23076 ms





HASH subKey      "123"，    JedisCommands     
>>>>>>>>>>>>>>>>begin
# Memory
used_memory:713224
used_memory_human:696.51K
used_memory_rss:655416
used_memory_peak:72374824
used_memory_peak_human:69.02M
used_memory_lua:36864
mem_fragmentation_ratio:0.92
mem_allocator:jemalloc-3.6.0

>>>>>>>>>>>>>>>>after
# Memory
used_memory:52300776
used_memory_human:49.88M
used_memory_rss:52273928
used_memory_peak:72374824
used_memory_peak_human:69.02M
used_memory_lua:36864
mem_fragmentation_ratio:1.00
mem_allocator:jemalloc-3.6.0

    ： time = 24877 ms

    消費メモリは155.16 Mから49.88 Mに減少し、節約メモリは多い.

    結論


    データを保存する際にJedisCommandsインタフェースを実現するhsetメソッドをできるだけ呼び出し,シーケンス化操作を行わない.
    @phpエラーの修正
    白駿2798黒ジャッキ