
목차1. 문제 배경: Redis는 왜 갑자기 죽었을까?2. 배경 지식: Redis의 BGSAVE와 Copy-on-Write3. 실험 목적: Copy-on-Write가 실제로 OOM을 유발하는가?4. 실험 환경: Docker 기반 Redis 컨테이너 구성5. 실험 과정: Copy-on-Write 상황 유발 및 메모리 관측6. 실험 결과: Copy-on-Write로 인한 메모리 폭증은 실제로 발생했다7. 실험을 통해 알게 된 것8. 결론9. Github 링크1. 문제 배경: Redis는 왜 갑자기 죽었을까?Redis가 예고 없이 종료될 수 있습니다.Redis의 maxmemory는 6GB로 설정되어 있었고,컨테이너의 메모리 제한은 7GB였으며,메모리 사용량이 한계에 가까운 시점에서 BGSAVE가 실행되었고,그..

들어가기에 앞서 좌측 그림은 데이터를 메모리에 선형적(Row-Major)으로 저장, 탐색하는 방식,우측 그림은 Z-order 기반으로 정사각형 블록 단위로 저장, 탐색하는 방식입니다.이 두 가지 방식의 차이가 공간 데이터 처리 성능에 어떤 영향을 미치는지 살펴보겠습니다. 현대의 지도 서비스, 자율주행 시뮬레이션, 지리 정보 시스템(GIS) 등은 방대한 공간 데이터를 실시간으로 탐색하고 처리해야 합니다.하지만 이러한 데이터를 단순히 행렬 순서(예: Row-Major)로 저장하면, 지리적으로 가까운 두 점이 메모리 상에서는 멀리 떨어져 저장될 수 있습니다. 이는 CPU 캐시 효율을 낮추고 데이터 접근 성능을 저하시키는 주된 원인이 됩니다. 이러한 문제를 해결하는 대표적인 방식이 Z-order Indexing..
- Total
- Today
- Yesterday
- implict titling
- gltf
- Cesium
- 3d tiles
- .b3dm
- sendfile()
- user space
- 삼각분할
- transferto()
- morton order
- ear clipping
- z-order
- b3dm
- redis bgsave
- * to gltf
- b3dm to glb
- Kafka
- z-order curve
- bgsave
- append only
- zero-copy
- cpu i/o
- kernel space
- event streaming
- the unix timesharing system
- event srource
- * to glb
- 역수 근사
- 3d tiles 1.0
- ear cut
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 |