Redis 성능 분석 및 모니터링 솔루션 소개

1. redis 느린 로그 분석

SLOWLOG 하위 명령 [인수]

다음은 redis.conf의 느린 쿼리 구성 매개변수입니다:

slowlog-log-slower-than 10000     #查询时间超过10ms的会被记录
slowlog-max-len 128     #最多记录128个慢查询

위의 매개변수는 redis에서 동적으로 쿼리하거나 설정할 수 있습니다. config get 및 config set 명령을 사용하세요.

느린 쿼리 읽기: 지정된 느린 쿼리를 가져올 수 있습니다.

127.0.0.1:6320> slowlog get 1
 1) 1) (integer) 394689     #slowlog的唯一编号
    2) (integer) 1480851711     #此次slowlog事件的发生时间
    3) (integer) 10639     #耗时
    4) 1) "HGET"     #slowlog事件所对应的redis 命令
       2) "hash:submit_sent_150004"
       3) "15000429648122734363745165312"

느린 로그 통계 재설정:

SLOWLOG RESET

redis 느린 명령 분석: #🎜 🎜#

1. Redis는 단일 스레드를 사용하여 클라이언트 요청을 처리합니다. 결과적으로 요청이 느리게 제공되면 다른 모든 클라이언트는 이 요청이 제공될 때까지 기다립니다. 느린 명령을 많이 실행해야 하는 경우 Redis 슬레이브에 느린 쿼리를 넣어 실행하는 것이 좋습니다.

2. 키 명령 정보: 느린 명령 실행으로 인해 발생하는 매우 일반적인 지연 원인은 프로덕션 환경에서 KEYS 명령을 사용하는 것입니다. Redis 문서에 명시된 대로 KEYS는 디버깅 목적으로만 사용해야 합니다.

redis2.8에는 대규모 컬렉션을 쿼리하기 위한 새로운 명령이 도입되었습니다. 자세한 내용은 SCAN, SSCAN, HSCAN 및 ZSCAN 명령을 확인하세요.

• SCAN은 현재 선택된 Redis 데이터베이스의 키 세트를 반복합니다.

• SSCAN은 집합 컬렉션 유형의 요소를 반복합니다.

• HSCAN은 해시 유형 필드 및 관련 값을 반복합니다.

• ZSCAN은 정렬된 세트 유형의 요소와 관련 점수를 반복합니다.

이러한 명령은 증분 반복을 허용하여 호출당 소수의 요소만 반환하므로 KEYS 또는 SMEMBERS와 같은 명령이 필요 없이 프로덕션에서 사용할 수 있습니다. 단점, 대규모 컬렉션의 키나 요소를 호출하면 서버가 오랫동안(몇 초라도) 차단될 수 있습니다.

2. SCAN, SSCAN, HSCAN 및 ZSCAN 명령을 사용하는 방법

SCAN은 커서 기반 반복자입니다. 즉, 명령을 호출할 때마다 서버는 사용자가 다음 호출에서 커서 매개변수로 사용해야 하는 업데이트된 커서를 반환합니다.

커서가 0으로 설정되면 반복이 시작되고 서버에서 반환된 커서가 0이면 종료됩니다. 다음은 SCAN 반복의 예입니다.

127.0.0.1:6319> scan 0
1) "65536"
2)  1) "list:submit_sent_2016-12-02-13:50_130806"
    2) "list:submit_sent_2016-12-01-15:01_130479"
    3) "list:submit_sent_2016-12-01-13:21_178888"
    4) "list:submit_sent_2016-12-02-10:46_186064"
    5) "list:submit_sent_2016-12-01-16:48_135546"
    6) "list:submit_sent_2016-12-02-14:27_185158"
    7) "list:submit_sent_2016-12-02-09:57_186532"
    8) "list:submit_sent_2016-12-01-13:24_183217"
    9) "list:submit_sent_2016-12-02-08:29_189316"
   10) "list:submit_sent_2016-12-01-13:46_177645"
127.0.0.1:6319> scan 65536
1) "884736"
2)  1) "list:submit_sent_2016-12-01-17:55_175010"
    2) "list:submit_sent_2016-12-02-18:28_138052"
    3) "list:submit_sent_2016-12-01-18:17_150243"
    4) "list:submit_sent_2016-12-01-11:22_137606"
    5) "list:submit_sent_2016-12-01-21:15_183748"
    6) "list:submit_sent_2016-12-02-11:47_155212"
    7) "list:submit_sent_2016-12-01-11:01_137065"
    8) "list:submit_sent_2016-12-02-08:03_181202"
    9) "list:submit_sent_2016-12-02-12:16_136096"
   10) "list:submit_sent_2016-12-01-18:12_159893"

커서 값 0으로 반복을 시작하고 반환된 커서가 다시 0이 될 때까지 SCAN을 호출합니다. 이를 전체 반복이라고 합니다.

scan의 카운트 옵션: 출력 수 지정

127.0.0.1:6319> scan 0 count 20
1) "884736"
2)  1) "list:submit_sent_2016-12-02-13:50_130806"
    2) "list:submit_sent_2016-12-01-15:01_130479"
    3) "list:submit_sent_2016-12-01-13:21_178888"
    4) "list:submit_sent_2016-12-02-10:46_186064"
    5) "list:submit_sent_2016-12-01-16:48_135546"
    6) "list:submit_sent_2016-12-02-14:27_185158"
    7) "list:submit_sent_2016-12-02-09:57_186532"
    8) "list:submit_sent_2016-12-01-13:24_183217"
    9) "list:submit_sent_2016-12-02-08:29_189316"
   10) "list:submit_sent_2016-12-01-13:46_177645"
   11) "list:submit_sent_2016-12-01-17:55_175010"
   12) "list:submit_sent_2016-12-02-18:28_138052"
   13) "list:submit_sent_2016-12-01-18:17_150243"
   14) "list:submit_sent_2016-12-01-11:22_137606"
   15) "list:submit_sent_2016-12-01-21:15_183748"
   16) "list:submit_sent_2016-12-02-11:47_155212"
   17) "list:submit_sent_2016-12-01-11:01_137065"
   18) "list:submit_sent_2016-12-02-08:03_181202"
   19) "list:submit_sent_2016-12-02-12:16_136096"
   20) "list:submit_sent_2016-12-01-18:12_159893"

scan의 일치 옵션: 패턴으로 일치하는 키 명령과 유사하며, 끝에 MATCH

127.0.0.1:6319> scan 0 match *submit_sent*
1) "65536"
2)  1) "list:submit_sent_2016-12-02-13:50_130806"
    2) "list:submit_sent_2016-12-01-15:01_130479"
    3) "list:submit_sent_2016-12-01-13:21_178888"
    4) "list:submit_sent_2016-12-02-10:46_186064"
    5) "list:submit_sent_2016-12-01-16:48_135546"
    6) "list:submit_sent_2016-12-02-14:27_185158"
    7) "list:submit_sent_2016-12-02-09:57_186532"
    8) "list:submit_sent_2016-12-01-13:24_183217"
    9) "list:submit_sent_2016-12-02-08:29_189316"
   10) "list:submit_sent_2016-12-01-13:46_177645"
127.0.0.1:6319> scan 0 count 15  match *submit_sent*     #查找匹配的数据并返回15个
1) "2031616"
2)  1) "list:submit_sent_2016-12-02-13:50_130806"
    2) "list:submit_sent_2016-12-01-15:01_130479"
    3) "list:submit_sent_2016-12-01-13:21_178888"
    4) "list:submit_sent_2016-12-02-10:46_186064"
    5) "list:submit_sent_2016-12-01-16:48_135546"
    6) "list:submit_sent_2016-12-02-14:27_185158"
    7) "list:submit_sent_2016-12-02-09:57_186532"
    8) "list:submit_sent_2016-12-01-13:24_183217"
    9) "list:submit_sent_2016-12-02-08:29_189316"
   10) "list:submit_sent_2016-12-01-13:46_177645"
   11) "list:submit_sent_2016-12-01-17:55_175010"
   12) "list:submit_sent_2016-12-02-18:28_138052"
   13) "list:submit_sent_2016-12-01-18:17_150243"
   14) "list:submit_sent_2016-12-01-11:22_137606"
   15) "list:submit_sent_2016-12-01-21:15_183748"

sscan 쿼리 세트 수집 방법:

redis 127.0.0.1:6379> sadd myset 1 2 3 foo foobar feelsgood
(integer) 6
redis 127.0.0.1:6379> sscan myset 0 match f*
1) "0"
2) 1) "foo"
   2) "feelsgood"
   3) "foobar"
redis 127.0.0.1:6379>

hscan 쿼리 해시 수집 방법:

redis 127.0.0.1:6379> hmset hash name Jack age 33
OK
redis 127.0.0.1:6379> hscan hash 0
1) "0"
2) 1) "name"
   2) "Jack"
   3) "age"
   4) "33"

Linux 커널이 투명성을 활성화하는 경우 거대한 페이지 기능을 사용하면 Redis는 디스크에 데이터를 유지하기 위해 포크 호출을 사용한 후 큰 지연 비용이 발생합니다.

이 방법을 사용하여 시스템 커널의 이 기능을 끌 수 있습니다:

echo never > /sys/kernel/mm/transparent_hugepage/enabled

참고: Redis를 적용하려면 Redis를 다시 시작해야 합니다.

3 스왑을 사용하여 redis가 시스템의 영향을 받는지 확인합니다.

查找redis进程id：
redis-cli -p 6319 info|grep process_id
process_id:32139
查看redis进程的内存使用信息：
cd /proc/32139
查看该进程使用swap分区的统计信息，以不使用或只有少量的4kB为佳：
cat smaps | grep 'Swap:'
同时打印出内存映射和swap使用信息：查看那些较大的内存消耗是否引发了大的swap使用
cat smaps | egrep '^(Swap:Size)'

4. 워치독 포지셔닝 지연: 실험 기능입니다. Redis 데이터가 백업되었는지 확인하세요.

Redis software watchdog
该功能只能动态启用，使用以下命令：
CONFIG SET watchdog-period 500
注：redis会开始频繁监控自身的延时问题，并把问题输出到日志文件中去。
 
关闭watchdog：
CONFIG SET watchdog-period 0
 
注：打开watchdog功能，会对redis服务性能产生影响。

5. Redis 대기 시간 모니터링 프레임워크 정보

Redis 대기 시간 모니터링 프레임워크

Redis 모니터링 프레임워크 활성화 방법:# 🎜🎜 #

CONFIG SET latency-monitor-threshold 100

기본적으로 임계값은 0으로 설정되어 Redis 모니터링이 비활성화됩니다. 실제로 이 모니터링 기능을 활성화하면 Redis에 비용이 거의 추가되지 않습니다. 하지만 잘 실행되는 Redis의 경우에는 이 모니터링 기능을 켤 필요가 없습니다.

LATENCY 명령 사용 방법

최신 지연된 이벤트 보기:

127.0.0.1:6319> latency latest
1) 1) "command"     #event name
   2) (integer) 1480865648     #发生时间
   3) (integer) 207     #耗时，毫秒
   4) (integer) 239     #从redis启动或上次latency reset以来，这种事件的最大延时记录

지연된 이벤트의 기록 정보 보기:

# 🎜🎜#LATENCY HISTORY event-name

특정 이벤트에 대해 명령은 최대 160개의 요소를 반환합니다. 애플리케이션은 모니터링, 디스플레이 그래픽 등을 수행하기 위해 원시 데이터를 얻고 싶어할 수 있습니다.

127.0.0.1:6319> latency history command
  1) 1) (integer) 1480865710
     2) (integer) 207
  2) 1) (integer) 1480865711
     2) (integer) 217
  3) 1) (integer) 1480865712
     2) (integer) 198
  4) 1) (integer) 1480865713
     2) (integer) 226
  5) 1) (integer) 1480865714
     2) (integer) 224

통계 0으로 재설정:

LATENCY RESET [event-name ... event-name]

텍스트 차트 형식으로 지연 표시 이벤트 :

LATENCY GRAPH event-name
127.0.0.1:6379> latency graph command
command - high 500 ms, low 101 ms (all time high 500 ms)
--------------------------------------------------------------------------------
   #_
  _||
 _|||
_||||
 
11186
542ss
sss

참고: 각 열은 지연된 이벤트를 나타냅니다. 하단에는 통계 이벤트에서 최소 지연된 이벤트가 2분 또는 38초와 같이 현재 시간 이전에 발생한 기간이 표시됩니다. short 밑줄 친 최대 지연 이벤트는 위의 #으로 표시됩니다. 이 수치는 지연된 이벤트의 변화 추세를 반영할 수 있습니다.

LATENCY DOCTOR, 지연된 이벤트 통계에 대한 지능형 분석 및 제안:

127.0.0.1:6379> latency doctor
Dave, I have observed latency spikes in this Redis instance.
You don't mind talking about it, do you Dave?
1. command: 5 latency spikes (average 300ms, mean deviation 120ms,
  period 73.40 sec). Worst all time event 500ms.
I have a few advices for you:
- Your current Slow Log configuration only logs events that are
  slower than your configured latency monitor threshold. Please
  use 'CONFIG SET slowlog-log-slower-than 1000'.
- Check your Slow Log to understand what are the commands you are
  running which are too slow to execute. Please check
  http://redis.io/commands/slowlog for more information.
- Deleting, expiring or evicting (becaus

127.0.0.1:6320> latency doctor
I have a few advices for you:
- I detected a non zero amount of anonymous huge pages used by your process. This creates very serious latency events in different conditions, especially 
when Redis is persisting on disk. To disable THP support use the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled', make sure to also 
add it into /etc/rc.local so that the command will be executed again after a reboot. Note that even if you have already disabled THP, you still need to
 restart the Redis process to get rid of the huge pages already created.

더 많은 Redis 지식을 보려면 PHP 중국어 웹사이트에 주목하세요.

redis 튜토리얼#🎜 🎜#칼럼.

위 내용은 Redis 성능 분석 및 모니터링 솔루션 소개의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!