Klaytn 노드 운영 질문 (Connection Refused and Memory)

안녕하세요. KLAY EN 노드를 운영중에 몇가지 어려움이 있어 문의드립니다.

첫번째로, Connection Refused.

노드에 몇 가지 rpc call 을 주기적으로 요청하고 있는데, 약 하루 정도 지나면 노드로부터 Connection Refused 라는 응답을 받고 있습니다.

노드를 재시작 하면 해결이 됩니다.

두번째로, 메모리 사용량

위 이슈와 연관이 있을 것으로 추측하는데요, 위와 같이 약 하루가 지나면 메모리 사용량이 60GB (전체의 95%) 에 육박하게 됩니다. 이 역시 노드를 재시작하면 메모리가 해제가 됩니다.

메모리 관련해서 이상한 점은 노드를 시작하고 rpc call 을 요청하지 않을때는 약 22GB 정도의 메모리 사용량이 유지되는데, 주기적으로 rpc call 을 수행하면

메모리가 튀는 것이 아니라 시간이 지남에 따라 누적이 되어 사용량이 Linear 하게 증가됩니다. 그리고 rpc call 을 멈추면 메모리 사용량이 멈춘 시점의 사용량을 거의 유지하고 있어 메모리 해제가 되지 않는 것으로 보입니다.

첫 번째 이슈(Connection Refused)는 메모리 사용량이 전체의 90% 이상을 사용하기 전에는 발생하지 않아서 메모리 사용량과 관련이 있을 것이라고 추측하고 있습니다.

이슈 분석을 위해 노드를 운영하는 장비 스펙, 노드 configuration, 사용하고 있는 rpc call 을 전달 드립니다.

EN 장비 주요 스펙

  • CPU (20 core)
  • Memory 64GB
  • SSD 8TB

Node Configuration

# Configuration file for the kend

# cypress, baobab is only available if you don't specify NETWORK_ID.
NETWORK="cypress"
# if you specify NETWORK_ID, a private network is created.
NETWORK_ID=

PORT=32323

SERVER_TYPE="http"
SYNCMODE="full"
VERBOSITY=3
MAXCONNECTIONS=10

# txpool options setting
TXPOOL_EXEC_SLOTS_ALL=4096
TXPOOL_NONEXEC_SLOTS_ALL=4096
TXPOOL_EXEC_SLOTS_ACCOUNT=4096
TXPOOL_NONEXEC_SLOTS_ACCOUNT=4096
TXPOOL_LIFE_TIME="30m"

# rpc options setting
RPC_ENABLE=1 # if this is set, the following options will be used
RPC_API="klay,eth,net,web3,debug" # available apis: admin,debug,klay,eth,miner,net,personal,rpc,txpool,web3
RPC_PORT=8551
RPC_ADDR="0.0.0.0"
RPC_CORSDOMAIN="*"
RPC_VHOSTS="*"
# below options are related with http server
RPC_CONCURRENCYLIMIT=3000
RPC_READ_TIMEOUT=30
RPC_WRITE_TIMEOUT=30
RPC_IDLE_TIMEOUT=120
RPC_EXECUTION_TIMEOUT=30

# ws options setting
WS_ENABLE=1 # if this is set, the following options will be used
WS_API="klay,eth,net,web3" # available apis: admin,debug,klay,eth,miner,net,personal,rpc,txpool,web3
WS_ADDR="0.0.0.0"
WS_PORT=8552
WS_ORIGINS="*"

# service chain options setting
SC_MAIN_BRIDGE=0 # if this is set, the following options will be used.
SC_MAIN_BRIDGE_PORT=50505
SC_MAIN_BRIDGE_INDEXING=0  # this option will be deprecated.

# Setting 1 is to enable options, otherwise disabled.
AUTO_RESTART=0
METRICS=1
PROMETHEUS=1
DB_NO_PARALLEL_WRITE=0
MULTICHANNEL=1
SUBPORT=$((PORT + 1)) # used for multi channel option

# discover options
NO_DISCOVER=0 # setting 1 to disable discovery
BOOTNODES=""

# log rotation related options
LOG_ROTATE=0 # setting 1 to enable the log rotation related options
LOG_MAXSIZE=100 # the unit is MB
LOG_MAXBACKUPS=10
LOG_MAXAGE=30 # maximum number of days to retain a log file
LOG_COMPRESS=1 # setting 1 to compress the backup logs in gz format

# Raw options e.g) "--txpool.nolocals"
ADDITIONAL=""

# auto restart options
AUTO_RESTART_NODE=0
AUTO_RESTART_INTERVAL=0.1

# manually configured
DATA_DIR=/var/kend/data
LOG_DIR=/var/kend/logs

사용하는 주요 rpc call

  • debug_traceBlockByNumberRange
  • klay_getTransactionByHash
  • klay_getTransactionReceipt
  • klay_getLogs

위 rpc call 들을 주기적으로 사용했을때 메모리 사용량이 누적되어 증가하고 줄어들지 않는 점에 대하여 문의 드리고 싶고 위 문제를 해결하기 위해 가이드 주실 부분이나 의견 주시면 감사하겠습니다.

안녕하세요,
추가적으로 정보를 제공받으면 좋을것 같습니다.

  1. 메모리 사용량 변화를 모니터링 중이시라면 캡처해서 보여주시면 좋을것 같습니다. 구축되어 있지 않다면, 코드에서 metric을 제공하고 있으므로, prometheus+grafana 등과 연결하여 구축이 가능합니다.
  2. rpc call 주기가 얼마나 자주인지, 그리고 블록번호를 알려주시면 좋을것 같습니다.
  3. rpc call을 멈추면 메모리 사용량이 유지가 된다고 하였는데, 최대 기다린 기간이 어느정도일까요?

메모리 사용량이 누적되는 흔한 이유중 하나는 이벤트를 구독 할때입니다. 필터가 많아질수록 메모리를 많이 쓰게 됩니다. 그 다음으로는 처리가 오래걸리는 rpc 콜을 동시에 처리할때입니다. BlockByNumberRange는 조심히 쓰셔야하는데요, 트레이싱 부하가 굉장히 커서 하나의 콜 처리가 30초를 넘어갈 때도 있습니다. 그래서 rpc 콜이 겹치다 보면 메모리를 많이 쓰고 release가 천천히 이루어지게 됩니다.

참고로 tracing 위주로 쓰는 경우 128기가를 많이 채택하고 있는걸로 알고있습니다. 또한 sync를 멈춰 tracing 외 다른 곳의 메모리 소비를 줄이는 방안도 많이들 쓰십니다.

안녕하세요, 추가 질문이 있습니다.
우선 Pprof 를 통해 프로파일링 해본 결과,
fastcache.Cache 에서 메모리의 사용량이 계속 증가되는 것을 확인했습니다.

trace를 할 때 trieDB에 reference를 하여 조회하는 것으로 이해하고 있는데요,


위 로그를 보다시피, Dereferenced 를 하는 노드의 개수는 200 ~ 600개인 반면
livenodes는 수는 줄지 않고, 계속해서 증가하고 있습니다.

저희 서버 처리 속도에 따라, 10 ~ 30초에 한 번 씩 5~10개 정도 요청하고 있습니다.
만약 dereference가 새로 요청되는 trace의 reference 들의 속도를 못 따라 잡고 있다면 메모리를 증설해서 해결이 될 수 있는 문제인지, 혹은 trieDB config를 설정해서 해결 할 수 있는 문제인지 궁금합니다.

메모리의 사용량 추이는 위와 같이 리니어하게 상승하기 때문에 저희가 주기적으로 서버를 리부트하고 있습니다.

안녕하세요. 우선 답변 감사드립니다. 요청주신 추가 정보를 드리겠습니다.

  1. 메모리 사용량 변화를 모니터링 중이시라면 캡처해서 보여주시면 좋을것 같습니다. 구축되어 있지 않다면, 코드에서 metric을 제공하고 있으므로, prometheus+grafana 등과 연결하여 구축이 가능합니다.


초기에 두번(4/16, 4/17) 발생을 했구요, 노드 재시작으로 메모리를 초기화해주었습니다.
현재는 매일 메모리 사용량이 많이 오르기 전에 노드를 재시작하여 메모리를 초기화해주고 있습니다.

  1. rpc call 주기가 얼마나 자주인지, 그리고 블록번호를 알려주시면 좋을것 같습니다.

debug_traceBlockByNumberRange 의 호출 주기는 평균적으로 4~5 초에 한번씩 발생을 하고 한번 호출할때 평균 5개 정도의 블록 범위로 호출하고 있습니다.

블록 번호는 최신블록을 따라서 지속적으로 호출하고 있습니다.

  1. rpc call을 멈추면 메모리 사용량이 유지가 된다고 하였는데, 최대 기다린 기간이 어느정도일까요?

약 16~17시간 정도 기다렸습니다. 관련된 메모리 사용량 캡쳐 첨부드립니다.

참고로 tracing 위주로 쓰는 경우 128기가를 많이 채택하고 있는걸로 알고있습니다.

위에 보여드린 것 처럼 메모리 사용량이 점진적으로 계속 상승하기때문에 128기가를 쓰더라도 문제 해결이 가능할지 조금 의문이 드는데요, 괜찮을까요?

또한 sync를 멈춰 tracing 외 다른 곳의 메모리 소비를 줄이는 방안도 많이들 쓰십니다.

이게 어떤 의미인지 잘 이해를 못했습니다. 조금 더 설명해주실 수 있으실까요?