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] CLIENT LIST 커맨드 / CLIENT SETNAME 커맨드  (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 김용환 '김용환'

댓글을 달아 주세요