허브 살리기 프로젝트24 SSD Sequantial Read/Write HDD와 SSD를 비교하는 글들을 보면 HDD는 구조상 헤드가 데이터를 읽거나 쓰는 위치로 이동하는 탐색시간 (Seek Time) 때문에 임의의 위치에 있는 데이터를 접근하려면 (Random Access) 시간이 오래 걸리며 SSD는 기계의 움직임이 없어서 더 빠르다고 한다. 여기서 처음 들었던 의문은 SSD는 기계의 움직임이 없으므로 Random Access나 Sequantial Access나 비슷한 시간이 걸리지 않을까? 라는 점이다. 하지만 SSD 제품들의 성능 지표를 보면 순차 접근과 랜덤 접근으로 나뉘어있다. 읽기나 쓰기나 차이가 비슷하기 때문에 순차 읽기만 보면 우선 단위가 달라서 순차 읽기와 랜덤 읽기를 맞춰주기 위해 IOPS를 MB/S 단위로 변환해준다. IOPS로 나타내는 I/O 단위는 .. 2024. 1. 30. Latency 계층 구조로 본 서비스의 Primary DB 선택 ByteByteGo에서 Latency 계층을 보던 중 흥미로운 점이 보인다. 레디스에서 물리 메모리에 저장 되어있는 데이터를 접근해서 사용할 메모리로 가져오는 것이 네트워크를 통해 데이터를 전송하는 것 보다 100배가 빠르다는 것이다. 1000 바이트의 데이터를 네트워크를 통해 데이터 전달은 100 마이크로초가 걸린다고 한다. 그럼 운영하는 서비스는 결국 레디스는 외부에서 사용하게 되니까 병목 지점은 네트워크에서 데이터 전달하는 것이 되며, 이 말은 네트워크 속도를 기준으로 데이터를 가져오는 latency를 측정하면 된다는 것이다. 보통의 서비스에 경우 MSA를 채택했을 때 중간의 한 API 서버가 응답해야 하는 latency는 P99 기준 우리 서비스는 200ms정도를 만족해야 한다. 이 말은 Redi.. 2024. 1. 28. 인덱스와 버퍼 풀 인덱스에 관해서 정리하다보면 문득 인덱스도 결국 디스크상에 존재하는 것이고 브랜치 노드를 탐색하는 과정에서 계속 Disk I/O가 있으며 탐색 과정은 루트 노드에서 탐색 과정을 진행 할 때 마다 Disk I/O로 접근해서 다음 노드의 주소를 가져와야 하기 때문에 인덱스 스캔도 생각보다 비효율적일지 않을까?라는 의문에서 생각을 정리하고 이해한 내용을 바탕으로 정리했다. 개발에서 사용하게 될 인덱스는 거의 B-Tree (Balanced Tree) 구조이므로 물론 B+Tree 인덱스도 사용된다고 하지만 편의상 B-Tree 인덱스로 확인하려고 하며 데이터베이스는 MySQL기준으로 확인하였다. B-Tree 인덱스의 구조 (RealMySQL 8.0 그림 8.4) 그림에서 나오는 개념을 간략히 정리하면. 페이지란 디.. 2024. 1. 25. False Sharing 설명 단어를 그대로 보면 '거짓 공유' 이다. 거짓을 공유한다는 것은 말이 웃기다. 컴퓨터에서 False는 논리 연산의 결과에 사용되며 조건이 맞지 않다는 의미로 사용된다. 그럼 어떤 조건에 맞는 것을 누구한테 공유하는 것일까를 생각해보면 해당 개념을 더 쉽게 이해할 수 있다. 우선 여기서 조건에 맞지 않음은 데이터가 조건에 맞지 않음을 의미하며, 공유의 대상은 주로 LLC (Last Level Cache)이다. 물론 L2, L3 까지 캐시를 사용하는 CPU이면 L2에서도 발생할 수 있다. 즉 마지막 대상 캐시만 발생하는 것은 아니다. 더 풀어서 데이터가 조건에 맞지 않음은 캐시 일관성이 맞지 않음을 의미한다. CPU는 메모리에서 데이터를 가져올 때 캐시라인 단위로 데이터를 가져온다. 캐시라인은 캐시 메.. 2024. 1. 22. 이전 1 ··· 3 4 5 6 다음
