State Migration 중 오류가 발생했습니다. 이에 대해 어떻게 대처하면 좋을지 조언이 필요합니다

안녕하세요.
State Migration 중 2가지 정도의 오류가 발생했습니다. 어떻게 대처할 수 있을지에 대한 조언 부탁드립니다.

먼저 사용 중인 환경 공유드리겠습니다.

환경

사용 중인 ken version

ken attach klay.ipc
Welcome to the Klaytn JavaScript console!

instance: Klaytn/v1.6.2+38c63d495d/linux-amd64/go1.15.7
 datadir: /var/kend/data
 modules: admin:1.0 debug:1.0 governance:1.0 istanbul:1.0 klay:1.0 net:1.0 personal:1.0 rpc:1.0 txpool:1.0 web3:1.0

전반적인 사양: AWS m5.4xlarge
OS

cat /etc/os-release
NAME="Amazon Linux"
VERSION="2"
ID="amzn"
ID_LIKE="centos rhel fedora"
VERSION_ID="2"
PRETTY_NAME="Amazon Linux 2"
ANSI_COLOR="0;33"
CPE_NAME="cpe:2.3:o:amazon:amazon_linux:2"
HOME_URL="https://amazonlinux.com/"

Memory

awk '$3=="kB"{$2=$2/1024^2;$3="GB";} 1' /proc/meminfo | column -t
MemTotal:           62.1311      GB
MemFree:            44.9343      GB
MemAvailable:       56.3499      GB
Buffers:            0            GB
Cached:             9.02423      GB
SwapCached:         0            GB
Active:             8.94466      GB
Inactive:           5.07291      GB
Active(anon):       4.3622       GB
Inactive(anon):     0.000827789  GB
Active(file):       4.58246      GB
Inactive(file):     5.07208      GB
Unevictable:        0            GB
Mlocked:            0            GB
SwapTotal:          0            GB
SwapFree:           0            GB
Dirty:              0.00082016   GB
Writeback:          0            GB
AnonPages:          4.99397      GB
Mapped:             0.0562172    GB
Shmem:              0.00255966   GB
Slab:               2.55605      GB
SReclaimable:       2.44914      GB
SUnreclaim:         0.106907     GB
KernelStack:        0.00883484   GB
PageTables:         0.0479507    GB
NFS_Unstable:       0            GB
Bounce:             0            GB
WritebackTmp:       0            GB
CommitLimit:        31.0655      GB
Committed_AS:       7.13333      GB
VmallocTotal:       32768        GB
VmallocUsed:        0            GB
VmallocChunk:       0            GB
HardwareCorrupted:  0            GB
AnonHugePages:      1.03906      GB
ShmemHugePages:     0            GB
ShmemPmdMapped:     0            GB
HugePages_Total:    0
HugePages_Free:     0
HugePages_Rsvd:     0
HugePages_Surp:     0
Hugepagesize:       0.00195312   GB
DirectMap4k:        4.35544      GB
DirectMap2M:        58.8516      GB
DirectMap1G:        1            GB

CPU

scpu
Architecture:        x86_64
CPU op-mode(s):      32-bit, 64-bit
Byte Order:          Little Endian
CPU(s):              16
On-line CPU(s) list: 0-15
Thread(s) per core:  2
Core(s) per socket:  8
Socket(s):           1
NUMA node(s):        1
Vendor ID:           GenuineIntel
CPU family:          6
Model:               85
Model name:          Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz
Stepping:            7
CPU MHz:             3165.177
BogoMIPS:            4999.99
Hypervisor vendor:   KVM
Virtualization type: full
L1d cache:           32K
L1i cache:           32K
L2 cache:            1024K
L3 cache:            36608K
NUMA node0 CPU(s):   0-15
Flags:               fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology nonstop_tsc cpuid aperfmperf tsc_known_freq pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch invpcid_single pti fsgsbase tsc_adjust bmi1 avx2 smep bmi2 erms invpcid mpx avx512f avx512dq rdseed adx smap clflushopt clwb avx512cd avx512bw avx512vl xsaveopt xsavec xgetbv1 xsaves ida arat pku ospke

Disk
IOPS는 AWS를 사용하고 있어서 충분하고 이미 그 동안 EN을 잘 운영해왔습니다.

df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs         32G     0   32G   0% /dev
tmpfs            32G     0   32G   0% /dev/shm
tmpfs            32G  2.7M   32G   1% /run
tmpfs            32G     0   32G   0% /sys/fs/cgroup
/dev/nvme0n1p1  3.0T  1.9T  1.1T  63% /
tmpfs           6.3G     0  6.3G   0% /run/user/1000
tmpfs           6.3G     0  6.3G   0% /run/user/0

Progess 불일치

먼저 마이너한 오류 먼저 공유드립니다.

Committed 되는 블록과 read 된 블록이 둘 다 상당수 증가함에도 불구하고 progress는 0.34에서 계속 변함이 없습니다.
마이너한 오류이므로 짧게 넘어가겠습니다.
image

Out of memory

OOM으로 죽기 전 가장 마지막 State migration 관련 로그와 OOM으로 죽은 트레이서 로그 전부를 첨부드립니다.
내용이 4천줄이 넘어가서 제 구글 드라이브 링크로 대체합니다.

kend 를 다시 시작했을 때 자동으로 State Migration 다시 시작

이 부분도 좀 놀랐던 포인트였습니다. 자동으로 다시 시작이 되더라구요… 혹시 의도하셨던 동작이었는지 궁금하고 아닐 수도 있어서 버그제보 차원에서 공유드립니다.
다시 콘솔들어가서 admin으로 직접 꺼줬습니다.

해결 방안에 대한 조언 부탁드립니다.

우선 저로서는 크게 2가지 정도의 골칫거리가 있습니다.

  1. State Migration을 다시 사용할 수 있는가?
  • OOM이 나서 죽어버린 상황에서 다시 돌리기가 겁이 납니다… 권장 사양을 충분히 만족한다고 생각했음에도 OOM이 나는 건 예상하지 못했습니다.
  1. 마이그레이션 도중 생긴 파일들에 대해서는 어떻게 할 것인가?
  • 마이그레이션이 거의 다 되어가다가 중단된 시점에서 지금까지 마이그레이션 하느라 생긴 파일을 어떻게 삭제할지에 대한 가이드는 제가 찾아보지 못했습니다. 괜히 다른 체인 데이터 건드렸다가 서비스 안 돌아갈까봐 걱정돼서 건드리지 못하고 있습니다… 이 부분에 대한 조언도 부탁드립니다. 디스크 공간이 곧 있으면 또 모자랍니다.

마지막으로 제가 제대로 이 기능을 사용하기 위해서 어떻게 대처하면 좋을지… 조언을 부탁드립니다.
제가 생각하는 나름의 해결 방안은

  1. 우선 마이그레이션 시 생긴 쓸데 없는 파일들 삭제 (용량 확보)
  2. EN 버전 업그레이드 v1.6.2 (현재 버전) → v1.7.0
  3. 다시 State Migration 수행
    인데… OOM이 나지 않으면서 마이그레이션을 수행할 수 있는 방법이 있을지 여쭤봅니다.

안녕하세요. 문의 주셔서 감사합니다.

OOM이 발생하신것 보니 사용메모리가 64GB보다 넘었던것 같습니다. GX 내부적으로 9월말에 했을때에는 50GB정도 사용하고 괜찮았으나 그사이에 최신 state 더 커진것 같습니다. 그래서 메모리가 더 큰 인스턴스로 바꾸시고 다시 실행해주시면 다시 실행되니 그렇게 시도해보실 수 있겠습니다.

마이그레이션이 정상적으로 끝나지 않고 다시 재시작시에는 다시 마이그레이션을 하도록 하는 기능이 적용되어 있습니다. 해당 기능이 켜지더라도 다시 예전으로 돌아가고 싶으시면 종료시키시면 됩니다.

버전은 업데이트를 하시는게 좋겠습니다.

진행율은 해당 시점에서 판단한 전체 state의 크기로 계산하는 것이라 진행을 함에 따라 점점더 정확한 수치를 표시해줄 것입니다.

GX가 제공하는 chaindata를 받으시는 것도 하나의 방법입니다.

메모리가 많이 필요하지 않은 state migration 기능은 향후에 개발되어 적용될 예정입니다만 현재는 최신 state의 갯수에 비례한 메모리가 필요합니다. 65GB보다도 더 충분한 메모리가 현재는 필요해보입니다.

감사합니다.

1개의 좋아요

@Ethan

안녕하세요. 답변 감사드립니다.
현재로서는 메모리를 늘리는 방법은 조금 어려울 거 같습니다.

저로선 StateMigration을 사용하는 방법론은 어렵겠네요…

몇 가지 더 여쭙고 싶은 게 있습니다.

  • 마이그레이션 시 생성된 파일 삭제방법
    마이그레이션은 실패했지만 마이그레이션 도중 생긴 약 300GB 상당의 파일은 그대로 남아 있는 상태입니다. 저한테는 이제 필요 없는 파일들인데요, 혹시 마이그레이션과 관련된 파일이나 폴더명을 말씀해주실 수 있으실까요? 어떻게 하면 잔해물(?)을 깔끔히 날릴 수 있을지 조언 부탁드립니다.

  • Klaytn cypress ChainData 에 올라오는 데이터는 이미 State Migration이 적용된 체인 데이터가 올라오는 게 맞는지요? 저는 StateMigration을 사용하지 못하니 해당 데이터를 통짜로 받아서 기존의 체인데이터와 교체하는 식의 간접 마이그레이션 방법을 진행해볼까합니다.

아래 명령을 통해 삭제해주시면 깔끔하게 지워집니다.

admin.stopStateMigration()

Klaytn cypress ChainData 에 올라오는 데이터는 저희가 주기적으로 migration 시킨 데이터 입니다. 기존 사용하시던 데이터를 이걸로 바꾸시는 것이 말씀하신 간접적인 마이그레이션의 방법입니다.

1개의 좋아요

@Ethan
빠른 답변 감사드립니다. 마지막으로 한 가지만 더 여쭙고 싶습니다.

현재 Klaytn cypress ChainData 의 최신 chaindata.tar.gz 의 사이즈는 약 486.2 GB 로 확인됩니다.
혹시 해당 파일의 압축을 풀었을 때의 사이즈를 알 수 있을까요?

직접 다운 받아서 확인하지 못하는 점은 양해 부탁드립니다.

압축을 풀었을 때의 사이즈를 가늠해서 디스크를 증가 시키고 간접 마이그레이션을 진행하기 위해 여쭙습니다.

압축 풀었을때는 780GB 정도 입니다.

2개의 좋아요