• 줄리 에반스는 Mess With DNS가 메모리 부족으로 인해 OOM에 의해 종료되는 경험을 공유함
• 이 문제는 메모리 사용 최적화 방법 탐구의 계기가 되었음
• 메모리 소모를 줄이기 위한 여러 시도가 있었으며, SQLite, 트라이, 데이터 구조 수정 등을 포함함

주요 시도 및 발견

현재 메모리 설정

• PowerDNS에 100MB, Mess With DNS에 200MB가 할당됨
• 낮은 가용 메모리로 인해 백업 스크립트 문제 발생

첫 번째 시도: SQLite

• SQLite를 사용하여 메모리 관리를 개선하려고 시도함
• IPv6 주소 저장에서 SQLite의 네이티브 지원 부족으로 어려움 겪음
• 이 솔루션은 이진 검색에 비해 속도가 느려, 초당 17,000회 조회에 그침

두 번째 시도: 트라이

• IP 주소 저장을 위해 트라이 사용 탐구
• 최종적으로 IPv4에 대해 800MB의 메모리를 소비하고 초당 100K 조회로 성능 저하됨

세 번째 시도: 배열 저장 최적화

• ASN 정보를 중복 제거하고 새로운 `netip.Addr` 타입 사용 제안
• 최종 메모리 사용량이 117MB에서 46MB로 줄어들어 70MB 절약됨

추가 통찰력

• 메모리 프로파일링 사용이 메모리 할당을 평가하는 유익한 방법으로 발견됨
• 일부는 속도 때문에 전통적인 이진 검색을 선호함
• 문제 해결 도전 과제로 VM 메모리를 512MB로 유지하자는 노트 작성

댓글

• MMDB 구현: 효율적인 IP 조회를 위한 MMDB(맥스마인드 DB) 파일 사용에 대한 논의
• 메모리 효율성 기법: IPv4에 대한 단일 32비트 값으로 IP 범위를 적합하게 배치하는 방법 제안
• 최적화를 위한 전처리: 데이터를 최적 메모리 레이아웃을 위해 전처리하는 언급과 메모리 매핑 기법 사용
• 알고리즘적 전략: 트라이 및 패트리샤 트리와 같은 더 효율적인 데이터 구조 사용 추천
• SQL 제한: 정적 데이터 저장을 위한 SQL의 이점이 의문시되며, 성능 향상을 위한 전용 데이터 구조 제안
• 실제 사례: 이러한 개념을 구현하는 브라우저 기반 IP 조회 도구와 같은 다양한 실제 응용 사례 공유
• 데이터 품질 우려: 부정확한 ASN 값과 상위 제공업체 필터링이 데이터 보고의 정확성에 미치는 영향 논의
• 통합 도전: 다양한 메모리 관리 전략과 SQLite와 같은 도구의 통합 경험 공유
• 커뮤니티 도구: 이러한 방법론을 효과적으로 지원하는 커뮤니티 주도의 도구에 대한 관심 표명
• 지속적인 학습: 메모리 최적화 전략을 배우는 데 유용한 자원으로 포스트 인정