안녕하세요.
개인적으로 EN을 운영하고 있는데 스토리지로 인해 비용에 부담을 느끼고 있습니다. 이에 프루닝에 대해 알게되었는데 관련 문의 드립니다.
1. State Batch Pruning (State Migration)
이를 활용하면 스토리지를 75% 정도 줄일 수 있다는 아티클을 봤습니다.
카이아 측에서 주기적으로 제공하는 체인데이터 스냅샷은 이게 이미 적용된거라고 보면 될까요?
압축 해제 시 약 5.2TB가 나오는데 여기서 더 줄일 수 있는지 궁금합니다.
2. Live Pruning
라이브 프루닝을 적용해봤더니 기존에 돌리던 것 대비 약 1초 지연이 되는 것을 확인했습니다.
라이브 프루닝 적용 시 이 정도 지연이 일반적인지 궁금합니다.
또한 라이브 프루닝의 경우 압축 해제 시 4.7TB인데 1번 대비 500GB 차이나는게 맞을까요?
스토리지 비용이 점점 늘어나서 고민이 많습니다 ㅠㅠ
감사합니다.
안녕하세요, 먼저 state migration 는 Live pruning과는 다른 방식입니다. 자세한 내용은 여기서 확인하실 수 있습니다.
Live pruning시 지연은 지금까지 리포트된 것이 없어서 일반적이진 않은 것 같습니다. 아무래도 실시간으로 retention이 지난 노드를 삭제하고 트래킹해야하기 때문에 기존보단 메모리 사용량이 늘긴하겠지만 1초 지연이 발생할 정도는 아닐 것 같은데요, 현재 카이아의 네트워크 트래픽이 크게 증가한 상황이라 그럴 수도 있을 것 같습니다.
네, 현재 Live pruning은 state migration 스냅샷 데이터와 비교했을 때 500GB정도 차이가 나는 것으로 확인됩니다.
저희도 최근 늘어난 트래픽으로 인해 필요한 disk size가 빠르게 증가하는 것을 확인하였고, 이를 위한 해결책을 준비중에 있습니다. 특히 full node의 경우 곧 storage compression이 도입되어 state migration 기준 ~57%의 disk size를 줄일 수 있는 기능이 도입될 예정이며, archive node의 경우는 state trie의 사이즈를 줄일 수 있는 여러 방법론들을 검토 중에 있습니다.
감사합니다.
질문 2개가 독립적인 질문이긴 했습니다!
답변 감사합니다.
추가로 프라이빗하게 사용하는 EN의 경우 추천해주실만한 인스턴스 스펙이 있을까요?
r6i.2xlarge 사용 중인데 라이브 프루닝에서 1초 가량 딜레이가 발생해서 추천이 있으신지 궁금합니다!
스펙 자체는 문제가 없는 것 같습니다.
혹시 1초 딜레이라는 것이, 구체적으로 어느 지점에서 발생하는 것일까요? 블록 프로세싱이 밀리는 것일까요 아니면 다른 이슈인 것일까요? Insert block 로그에 블록 삽입 중 소요되는 시간이 함께 찍히는데 이 부분 확인해보시면 좋을 것 같습니다.