Redis
 sql >> база данни >  >> NoSQL >> Redis

6 важни показатели за мониторинг на Redis, които трябва да наблюдавате

Redis е база данни в паметта, която осигурява невероятно бърза производителност. Това го прави убедителна алтернатива на базираните на диск бази данни, когато производителността е проблем. Може вече да използвате ScaleGrid хостинг за Redis™* за захранване на вашите приложения, чувствителни към производителността. Как гарантирате, че внедряването на Redis е здравословно и отговаря на вашите изисквания? Ще трябва да знаете кои показатели за наблюдение за Redis™ да гледате и инструмент за наблюдение на тези критични показатели на сървъра, за да гарантирате неговото здраве. Redis връща голям списък с показатели на базата данни, когато изпълните командата info в Redis shell. Можете да изберете интелигентен избор от подходящи показатели от тях. И те могат да ви помогнат да гарантирате здравето на вашата система и бързо да извършите анализ на първопричината на всеки проблем, свързан с производителността, който може да срещнете.

Тази публикация в блога изброява важните показатели на базата данни, които да наблюдавате. Ще разгледаме всеки показател от гледна точка на производителността на базата данни и ще обсъдим често срещаните проблеми и решения, свързани с тях.

1. Показател за производителност:Пропускателна способност

Пропускателна способност ви казва колко операции с базата данни изпълнява вашият сървър за определен период от време. Зависи от работното натоварване на вашето приложение и неговата бизнес логика. Като разгледате историята на пропускателната способност, можете да заключите модела на натоварване на сървъра, напр. пиково натоварване, честота на пиково натоварване, времеви рамки на пиково натоварване, средно натоварване и т.н.

Можете да събирате стойности на пропускателната способност за всички команди, изпълнявани на сървъра Redis, като изпълните „info commandstats “.

127.0.0.1:6379> info commandstats
# Commandstats
cmdstat_get:calls=797,usec=4041,usec_per_call=5.07
cmdstat_append:calls=797,usec=4480,usec_per_call=5.62
cmdstat_expire:calls=797,usec=5471,usec_per_call=6.86
cmdstat_auth:calls=147,usec=288,usec_per_call=1.96
cmdstat_info:calls=46,usec=902,usec_per_call=19.61
cmdstat_config:calls=2,usec=130,usec_per_call=65.00
cmdstat_eval:calls=796,usec=36950,usec_per_call=46.42
cmdstat_command:calls=796,usec=8578,usec_per_call=10.78

Redis групира различните си команди в връзка, сървър, клъстер, общи и т.н. Мониторингът на ScaleGrid за Redis™ обединява пропускателната способност на различни команди в една от гореспоменатите групи. Пропускателната способност е представена като графика с подредени области, където височината на всяка цветна област осигурява пропускателната способност на група от команди.

Намалената пропускателна способност обикновено може да означава, че сървърът получава по-малко заявки. Това може също да показва потенциален проблем, да речем, скъпа заявка. По същия начин, увеличената пропускателна способност означава интензивно натоварване на сървъра и по-голямо забавяне.

2. Използване на памет

Паметта е критичен ресурс за производителността на Redis. Използвана памет дефинира общия брой байтове, разпределени от Redis, използвайки неговия разпределител (стандартен libc, jemalloc или алтернативен разпределител като tcmalloc).

Можете да съберете всички данни за показателите за използване на паметта за екземпляр на Redis, като изпълните „информационна памет “.

127.0.0.1:6379> info memory
# Memory
used_memory:1007280
used_memory_human:983.67K
used_memory_rss:2002944
used_memory_rss_human:1.91M
used_memory_peak:1008128
used_memory_peak_human:984.50K

Понякога, когато Redis е конфигуриран без ограничение за максимален размер на паметта, използването на паметта в крайна сметка ще достигне системната памет и сървърът ще започне да изхвърля грешки „Out of Memory“. В други случаи Redis е конфигуриран с максимален лимит на паметта, но без изгонване политика. Това би накарало сървъра да не изхвърли никакви ключове, като по този начин ще предотврати всяко записване, докато паметта не бъде освободена. Решението на подобни проблеми би било конфигурирането на Redis с максимална памет и някаква политика за изгонване. В този случай сървърът започва да изхвърля ключове, използвайки правила за изгонване, когато използването на паметта достигне максималния.

RSS на паметта (Размер на резидентен набор) е броят байтове, които операционната система е разпределила на Redis. Ако съотношението на „memory_rss“ към „memory_used“ е по-голямо от ~1,5, това означава фрагментация на паметта. Фрагментираната памет може да бъде възстановена чрез рестартиране на сървъра.

3. Съотношение на попадане в кеша

Коефициентът на попадане в кеша представлява ефективността на използването на кеша. Математически се дефинира като (Общо попадения на клавиши)/ (Общо попадения на клавиши + Общо пропуснати клавиши).

информационна статистика ” предоставя посещения_от ключово пространство &пропускане на ключово пространство метрични данни за допълнително изчисляване на съотношението на попадане в кеша за работещ екземпляр на Redis.

127.0.0.1:6379> info stats
# Stats
.............
sync_partial_err:0
expired_keys:10
evicted_keys:12
keyspace_hits:4
keyspace_misses:15
pubsub_channels:0
pubsub_patterns:0
.............

Ако коефициентът на попадане в кеша е по-нисък от ~0,8, значи значителна част от исканите ключове са изгонени, изтекли или изобщо не съществуват. От решаващо значение е да наблюдавате този показател, докато използвате Redis като кеш. По-ниското съотношение на попадане в кеша води до по-голяма латентност, тъй като повечето от заявките извличат данни от диска. Това показва, че трябва да увеличите размера на кеша на Redis, за да подобрите производителността на приложението си.

4. Активни връзки

Броят на връзките е ограничен ресурс, който се налага или от операционната система, или от конфигурацията на Redis. Наблюдението на активните връзки ви помага да гарантирате, че имате достатъчно връзки, за да обслужвате всичките си заявки в пиков момент.

5. Изгонени/изтекли ключове

Redis поддържа различни правила за изгонване които се използват от сървъра, когато използването на паметта достигне максималното ограничение. Постоянната положителна стойност на този показател е индикация, че трябва да увеличите паметта.

127.0.0.1:6379> info stats
# Stats
..............
sync_partial_err:0
expired_keys:0
evicted_keys:0
keyspace_hits:0
keyspace_misses:0
pubsub_channels:0
pubsub_patterns:0
..............

Redis поддържа TTL (време за живот) свойство за всеки ключ. Сървърът изтрива ключа, ако свързаният TTL е изтекъл. Ако приложението не дефинира това свойство, това води до натрупване на изтекли данни в паметта. Положителната стойност на показател показва, че вашите изтекли данни се почистват правилно.

6. Показатели за репликация

‘connected_slaves’ метриката информира достъпността на подчинения сървър до главен. Недостъпността на подчинения може да доведе до по-висока латентност при четене в зависимост от натоварването при четене на сървъра.

127.0.0.1:6379> info replication
# Replication
role:master/slave
connected_slaves:0/master_slave_io_seconds_ago:0
master_repl_offset:0
..............

master_slave_io_seconds_ago ’ метриката показва колко време изтича по време на комуникацията между подчинен и главен. По-висока стойност за този показател може да е показателна за проблеми на главния/подчинен или някои мрежови проблеми. Освен това кара подчинения да обслужва остарели данни.

Заключение

Споменахме някои от важните показатели, които ще осигурят добра видимост за здравето и производителността на вашия сървър на база данни. Може да има други, които са подходящи за вашите конкретни сървъри на бази данни и случаи на употреба. Препоръчваме ви да прегледате и разберете всички показатели, отчетени от командата „info“.

Ако имате нужда от помощ за управлението на вашия AWS хостинг за внедряване на Redis™, не се колебайте да се свържете с нас чрез имейл на [email protected] или в Twitter @scalegridio.


  1. Redis
  2.   
  3. MongoDB
  4.   
  5. Memcached
  6.   
  7. HBase
  8.   
  9. CouchDB
  1. Как да работим с двойки потребител и сокет с node.js + redis

  2. Използване на Redis за кеширане на SQL резултат

  3. Как да изчистя redis db от python redis?

  4. Action Cable 5 изисква ли Redis?

  5. Опит за стартиране на планировчик на redis и resque в рамките на рейк задача