CLIENT LIST 커맨드는 클라이언트에 대한 관련 정보와 통계 뿐 아니라 서버에 연결된 모든 클라이언트 목록을 리턴한다(예를 들면, IP 주소, 이름, idle time 등등).


터미널 2개 접속한 후, CLIENT LIST를 실행했다.


127.0.0.1:6379> CLIENT LIST

id=3 addr=127.0.0.1:65265 fd=6 name= age=322 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=client

id=4 addr=127.0.0.1:65407 fd=7 name= age=2 idle=2 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=NULL




1번 터미널에서 클라이언트 이름을 LOVE-1로 변경했다.

127.0.0.1:6379> CLIENT SETNAME LOVE-1

OK


2번 터미널에서 클라이언트 이름을 LOVE-2로 변경했다.

127.0.0.1:6379> CLIENT SETNAME LOVE-1

OK




CLIENT LIST 커맨드 후 변경된 name을 확인할 수 있다. 이전에는 name= 만 있었는데, 이제는 이름을 가질 수 있다.

127.0.0.1:6379> CLIENT LIST

id=3 addr=127.0.0.1:65265 fd=6 name=LOVE-1 age=469 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=client

id=4 addr=127.0.0.1:65407 fd=7 name=LOVE-2 age=149 idle=2 flags=N db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-free=0 obl=0 oll=0 omem=0 events=r cmd=client




'Redis' 카테고리의 다른 글

[Redis] CLIENT KILL 커맨드  (0) 2016.01.14
[Redis] FLUSHALL 커맨드  (0) 2016.01.14
[Redis] DBSIZE 커맨드  (0) 2016.01.14
[redis] info 커맨드  (0) 2016.01.14
[redis] Lua의 무한 루프 실행시 대처 방법  (0) 2016.01.11
Posted by '김용환'
,

[Redis] DBSIZE 커맨드

Redis 2016. 1. 14. 08:28



DBSIZE 커맨드는 레디스 서버에 존재하는 키 개수를 리턴한다.


127.0.0.1:6379> keys *

1) "myhash"

127.0.0.1:6379> DBSIZE

(integer) 1



Posted by '김용환'
,

[redis] info 커맨드

Redis 2016. 1. 14. 08:26

INFO 커맨드는 레디스의 버전, 운영 체제, 연결된 클라이언트, 메모리 사용량, 저장소, 복제본, 키스페이스(keyspace)에 대한 정보를 포함한 모든 레디스 서버 통계를 리턴한다.


127.0.0.1:6379> info

# Server

redis_version:3.0.2

redis_git_sha1:00000000

redis_git_dirty:0

redis_build_id:d8ace20bbd69868e

redis_mode:standalone

os:Darwin 15.0.0 x86_64

arch_bits:64

multiplexing_api:kqueue

gcc_version:4.2.1

process_id:16628

run_id:9c1a3e66ab22e039dc827b46f70936fb722c0452

tcp_port:6379

uptime_in_seconds:459

uptime_in_days:0

hz:10

lru_clock:9886885

config_file:


# Clients

connected_clients:1

client_longest_output_list:0

client_biggest_input_buf:0

blocked_clients:0


# Memory

used_memory:576832

used_memory_human:563.31K

used_memory_rss:1826816

used_memory_peak:576832

used_memory_peak_human:563.31K

used_memory_lua:36864

mem_fragmentation_ratio:3.17

mem_allocator:libc


# Persistence

loading:0

rdb_changes_since_last_save:1

rdb_bgsave_in_progress:0

rdb_last_save_time:1452727002

rdb_last_bgsave_status:ok

rdb_last_bgsave_time_sec:-1

rdb_current_bgsave_time_sec:-1

aof_enabled:0

aof_rewrite_in_progress:0

aof_rewrite_scheduled:0

aof_last_rewrite_time_sec:-1

aof_current_rewrite_time_sec:-1

aof_last_bgrewrite_status:ok

aof_last_write_status:ok


# Stats

total_connections_received:2

total_commands_processed:14

instantaneous_ops_per_sec:0

total_net_input_bytes:490

total_net_output_bytes:4385

instantaneous_input_kbps:0.00

instantaneous_output_kbps:0.00

rejected_connections:0

sync_full:0

sync_partial_ok:0

sync_partial_err:0

expired_keys:0

evicted_keys:0

keyspace_hits:1

keyspace_misses:0

pubsub_channels:0

pubsub_patterns:0

latest_fork_usec:0

migrate_cached_sockets:0


# Replication

role:master

connected_slaves:0

master_repl_offset:0

repl_backlog_active:0

repl_backlog_size:1048576

repl_backlog_first_byte_offset:0

repl_backlog_histlen:0


# CPU

used_cpu_sys:0.33

used_cpu_user:0.15

used_cpu_sys_children:0.00

used_cpu_user_children:0.00


# Cluster

cluster_enabled:0


# Keyspace

db0:keys=1,expires=0,avg_ttl=0


항목 별로 보려면 INFO 커맨드 내의 주석을 참고해서 따로 볼 수 있다.


127.0.0.1:6379> INFO cpu

# CPU

used_cpu_sys:0.40

used_cpu_user:0.18

used_cpu_sys_children:0.00

used_cpu_user_children:0.00

127.0.0.1:6379> INFO cluster

# Cluster

cluster_enabled:0

127.0.0.1:6379> INFO replication

# Replication

role:master

connected_slaves:0

master_repl_offset:0

repl_backlog_active:0

repl_backlog_size:1048576

repl_backlog_first_byte_offset:0

repl_backlog_histlen:0


Posted by '김용환'
,


redis에 http://redis.io/commands/EVAL에 있는 것처럼 lua-time-limit 루아 스크립트의 타임아웃이 존재한다.


그러나, lua 스크립트를 잘 못 개발해서 무한루프로 들어간다면, 문제가 발생할 수 있다.



무한 루프 실행하고 cpu를 계속 사용한다.


eval 'while true do  end' 0



새로운 레디스 클라이언트를 실행하면 실행을 할 수 없다. (싱글 쓰레드 이슈)


127.0.0.1:6379> info

BUSY Redis is busy running a script. You can only call SCRIPT KILL or SHUTDOWN NOSAVE.

127.0.0.1:6379> set a 1

(error) BUSY Redis is busy running a script. You can only call SCRIPT KILL or SHUTDOWN NOSAVE.

127.0.0.1:6379>




script kill해서 동작시킬 수 있다.


127.0.0.1:6379> SCRIPT KILL

OK

127.0.0.1:6379> info

# Server

redis_version:3.0.2



실행하던 무한루프 세션은 다음과 같이 출력된다. 


127.0.0.1:6379> eval 'while true do  end' 0

(error) ERR Error running script (call to f_227454c4c36ed5fb02fb2a11cab0da179d0dd7ab): @user_script:1: Script killed by user with SCRIPT KILL...

(261.97s)




만약 script kill 대신 shutdown을 실행하면, redis는 저장없이 종료되니, 함부로 사용하지 말아야 한다.

127.0.0.1:6379> SHUTDOWN NOSAVE

not connected>



# 무한루프 세션

127.0.0.1:6379> eval 'while true do  end' 0

Could not connect to Redis at 127.0.0.1:6379: Connection refused

(15.70s)


# 서버 로그 

34701:M 11 Jan 01:50:22.344 # User requested shutdown...

34701:M 11 Jan 01:50:22.344 # Redis is now ready to exit, bye bye...



* 주의

SCRIPT KILL은  write를 작업하는 루아 스크립트를 종료할 수 없다. write를 작업하는 루아 스크립트를 종료하려면 SHUTDOWN NOSAVE 커맨드를 실행하거나 루아 스크립트가 종료될 때까지 기다린다.



* SCRIPT KILL 리턴 값


- OK

- NOTBUSY - 실행 중인 스크립트가 존재하지 않는다.

- UNKILLABLE - 쓰기 커맨드가 진행중이라서 KILL할 수 없음을 알린다.



* SHUTDOWN

레디스 종료 명령어로서, 두가지 옵션을 제공한다.

SAVE - persistent 가 활성화되지 않아도 dump.rdb에 데이터를 저장케 한다.

NOSAVE- persistent가 활성화되어도 바로 레디스 종료시키게 한다.

Posted by '김용환'
,



redis 사용시 pfadd 사용하다 다음 에러를 만났다.


PFADD visits:2015-12-31 "x"

(error) WRONGTYPE Key is not a valid HyperLogLog string value.




/* Check if the object is a String with a valid HLL representation.

 * Return C_OK if this is true, otherwise reply to the client

 * with an error and return C_ERR. */

int isHLLObjectOrReply(client *c, robj *o) {

    struct hllhdr *hdr;


    /* Key exists, check type */

    if (checkType(c,o,OBJ_STRING))

        return C_ERR; /* Error already sent. */


    if (stringObjectLen(o) < sizeof(*hdr)) goto invalid;

    hdr = o->ptr;


    /* Magic should be "HYLL". */

    if (hdr->magic[0] != 'H' || hdr->magic[1] != 'Y' ||

        hdr->magic[2] != 'L' || hdr->magic[3] != 'L') goto invalid;


    if (hdr->encoding > HLL_MAX_ENCODING) goto invalid;


    /* Dense representation string length should match exactly. */

    if (hdr->encoding == HLL_DENSE &&

        stringObjectLen(o) != HLL_DENSE_SIZE) goto invalid;


    /* All tests passed. */

    return C_OK;


invalid:

    addReplySds(c,

        sdsnew("-WRONGTYPE Key is not a valid "

               "HyperLogLog string value.\r\n"));

    return C_ERR;

}



키 타입 길이가 맞지 않아서 에러가 발생했다.

WRONGTYPE Key is not a valid HyperLogLog string value 이 발생하는 로그는 다음 중 하나로 발생한다. 
- 키 크기 이상
- 매직 넘버(HYLL) 이상
- 인코딩 MAX 값(상수가 1로 정의됨)을 넘어섬
- DENSE 타입이면 크기도 같아야 하는데, 그러지 않음



즉, type커맨드로 확인해보니 다른 타입의 키로 등록했기 때문에 pfadd가 에러가 발생한 것이었다. 

 type visits:2015-12-31
string




Posted by '김용환'
,


2011년 인스타그램 블로그에 쓰여진 글이지만, 여전히 시사하는 바가 커서 내용을 공유한다.

http://instagram-engineering.tumblr.com/post/12202313862/storing-hundreds-of-millions-of-simple-key-value



인스타그램(Instagram)은 3 억건의 media ID로 user ID를 저장해야 하는 사례가 있었다. 

이를 위해 인스타그램은 테스트를 진행했다.  String과 Hash를 이용하여 레디스 프로토타입을 Pieter Noordhuis의 도움을 받아 벤치마크했었다.


String을 이용할 때는 미디어 ID 당 하나의 키와 약 21GB의 메모리를 사용했다. 

Hash를 이용할 때는 일부 설정(hash-zipmap-max-entrie)을 수정하여 약 5 GB를 사용했다. (https://github.com/antirez/redis/blob/unstable/src/zipmap.c)



*참고 

redis의 hash에 대한 메모리 최적화는 http://redis.io/topics/memory-optimization를 참조할 수 있다.

ziplist는 메모리 효율화를 위해 만들어졌다. ziplist에 저장되는 숫자는 문자가 아닌 integer로 저장되기 때문에 메모리 효율이 좋게 만들어졌다. 하지만 검색 속도가 느릴 수 있다. (안 좋게 말하면 hashtable보다 cpu를 훨씬 더 사용할 수 있다.)

대신 hash table은 메모리 효율화는 되지 않지만, 속도하나만큼은 안정적으로 쓸 수 있다. 




Posted by '김용환'
,



redis list를 (비동기) 이벤트 큐로 사용하는 시스템을 살펴보니. 대충 3개가 가장 많이 사용하고 있다.


1. celery

파이썬 기반의 분산 비동기 큐이다. 생각보다 많이 쓰고 있다.  (https://github.com/celery/celery star가 4천개가 넘다.)

http://www.celeryproject.org/


비동기 큐로 백엔드로 redis를 쓰고 있다. 이외 카우치DB, rabbitmq 등 많은 백엔드를 사용할 수 있다. 

https://github.com/celery/celery/tree/3.1/docs/getting-started/brokers



2. resque

ruby 기반의 비동기 큐이다. 워낙 유명하며 star가 7천개가 넘는다.

https://github.com/resque/resque 



3. logstash

flume의 자리를 빼앗은 log 수집 툴이다. JRuby 기반이다. 

내부 백엔드로 redis를 큐(내부적으로 broker)로 사용한다. 

https://github.com/elastic/logstash



Posted by '김용환'
,