강의 5 - 대규모 데이터 처리의 어려운점

 

강의 5 - 대규모 데이터 처리의 어려운점

대규모 데이터의 어려운 점 - '메모리 내에서 계산 할 수 없다'

• 메모리 내에서 계산할 수 없게 되면 디스크에 있는 데이터를 검색할 필요가 있다.
• 하지만 디스크는 느리므로 I/O에 시간이 걸린다.
• 어떻게 대처할 것인가가 연구 대상

메모리와 디스크의 속도차

- 메모리는 디스크에 비해 10^5~10^6배 이상 빠르다.

 

디스크는 왜 늦을까?

메모리는 전기적인 부품이므로 물리적 구조는 탐색속도와 그다지 관계없다.

마이크로초(10^-6초)단위의 포인터 이동으로 탐색이 수행된다.

 

한편 디스크는 헤드의 이동, 원반(디스크)의 회전 이라는 물리적인 동작을 수반한다.

각각 수 밀리초(10^-3초)가 걸리는 동작이다. 

 

다음으로 탐색에 사용되는 것이 CPU 의 캐시에 올리기 쉬운 알고리즘이나 데이터 구조라면 메모리 내용이 CPU캐시에 올라가므로 더욱 빨라져 나노초(10^-9초) 단위로 처리할 수 있다.

 

OS 레벨에서의 연구

OS는 디스크의 단점 (물리적 동작에 따른 시간 소요)을 커버하는 작용을 합니다. 디스크의 회전을 최소화 하기위해 OS는 연속된 데이터를 같은 위치에 쌓습니다. 그리고 나서 데이터를 읽을 때 1 바이트씩 읽는 것이 아니라 4KB 정도(페이지?)를 한꺼번에 읽도록 되어 있습니다.

 

전송속도, 버스의 속도차

지금까지는 탐색속도 측면에서 메모리가 디스크에 비해 10만~100만배이상 빠르다는 얘기였는데 사실은 이것뿐만이 아닙니다. 메모리 혹은 디스크에서 CPU로 전속하는 속도는 대략 수십배정도 차이가 납니다.

 

 

 

Linux 단일 호스트의 부하

원래 한 대에서 처리할 수 있는 부하를 서버 10대로 분산하는 것은 본말이 전도된 것이다.

단일 서버의 성능을 충분히 끌어 낼수 있는 것을 시작으로 복수 서버에서의 부하분산이 의미를 갖는다.

 

추측하지 말라, 계측하라

계측함으로써 시스템의 병목을 규명하고, 이를 집중적으로 제거함으로써 성능을 끌어낼 수 있다.

• Load Average 확인
• CPU, I/O 중 병목 원인 조사

 

. Load Avarage

에 관해서는 다음 블로그 포스팅을 참고하자

https://m.blog.naver.com/writer0713/221940150264

[Linux] load average에 대한 이해

 

. 'CPU'부하가 높은 경우

• 사용자 프로그램의 처리가 병목인지, 시스템 프로그램이 원인인지 확인 (top, sar)
• ps -> 원인이 되는 프로세스 찾기
• strace, oprofile -> 병목지점을 상세히 조사

 

. 'I/O'부하가 높은 경우

• ps->역시 특정 프로세스가 극잔덕으로 메모리를 소비하고 있지 않은지 확인
• 프로그램 개선/ 메모리 증설, 불가시 데이터 분산/ 캐시서버 도입 검토