21. Trashing and Working set

컴퓨터 시스템이 감당할 수 있는 양보다 더 많은 양의 워크로드를 돌릴 경우 성능 저하를 피할 수 없습니다. 이 성능 저하는 프로세스 개수에 비례해서 linear 하게 나빠지는 것이 아닌 어느 시점에서 급격한 성능 저하가 발생하게 되는데 이것을 쓰레싱(Thrashing)이라고 부릅니다. 

 

 

 

쓰레싱이 생기는 이유는 페이지 프레임의 개수는 적은데 프로세스들이 더 많은 페이지를 자주 사용하면서 발생합니다. 공간이 좁기 때문에 가까운 미래에 사용할 페이지를 쫓아내고 자리를 만든 다음 페이지 폴트가 발생해 페이지를 들고 오는 것이 반복되어 page fault rate가 증가하게 됩니다.

 

이러면 메모리가 아닌 swap area에 액세스해서 페이지를 가지고 오는데 이 속도가 너무 느리기 때문에 버츄얼 메모리의 이점을 살리지 못하게 됩니다. (메인 메모리 액세스 속도와 비교했을 때 디스크 액세스 속도가 10만 배 더 느리기 때문), 버츄얼 메모리를 잘못 운영하여 쓰레싱이 발생하면 메모리 액세스 속도가 10만 배 느려지는 것입니다.

 

어떤 시스템이 성능 저하가 나타났는지 아닌지를 확인하는 방법으로는 page fault rate를 보면 됩니다. 버추얼 메모리 매니지먼트 시스템에서 페이지들에 대한 액세스 efficiency는 위 사진의 공식과 같이 간단히 표현될 수 있기 때문입니다.

 

 

 

쓰레싱이 발생하는 이유는 시스템의 능력에 비해서 과도한 워크로드가 돌고 있는 것이기 때문에 어떤 policy를 사용하던지 해결하기 어려운 문제여서입니다. 우리가 주어진 시간 안에 여러 장소에서 일을 하면 실제적으로 일을 하는 시간보다 그 장소로 이동하는 시간이 더 많이 걸릴 것입니다. (이렇게 쓰레싱은 overhead operation만 하고 effective operation을 수행하지 못하는 것)

 

일하는 시간을 늘리고 싶다면 몇 가지 일을 포기하고 나머지 일에 집중하면 됩니다. 여기서도 마찬가지로 쓰레싱이 발생했다면 많은 프로세스로 인한 워크로드 사이즈 증가로 발생하는 것이기 때문에 워크로드를 줄여야 합니다.

 

 

 

쓰레싱을 인지하게 되면 여러 대처를 할 수 있습니다. 가장 대표적인 해결책은 load를 shed 하거나 스로틀링(Throttling)을 통해서 프로세스들 중 급하지 않은 것들의 수행을 딜레이 시키는 것입니다.

 

 

 

개인 컴퓨터에서는 쓰레싱을 쉽게 발견하고 사용하는 앱을 줄이는 등의 방법으로 처리할 수 있습니다. 하지만 다수의 사용자가 사용하는 머신의 경우 쓰레싱이 발생하면 OS나 시스템 어드민이 해결해야 합니다.

 

 

 

time sharing OS의 연구는 1960년도 중반부터 시작되었기 때문에 사람들은 쓰레싱쓰레싱 문제를 빨리 접할 수 있었습니다. 그래서 1968년도에 워킹 셋(working set)이라는 쓰레싱을 해결하기 위한 개념이 등장했습니다. 워킹 셋(working set)은 어떤 프로세스가 빈번하게 액세스 하는 페이지들의 집합으로 워킹 셋을 만들기 위한 파라미터로 시간을 사용합니다. 이 시간은 현재 시간으로부터 과거의 타임 인터벌의 시작점을 말합니다.

 

이 파라미터는 t로 t라는 시간동안 그 프로세스가 액세스 한 모든 페이지들의 집합이 워킹 셋으로 정의됩니다. 여기에는 한 가지 문제가 있는데 t시간 동안 액세스되는 페이지가 많다면 워킹 셋 사이즈도 같이 커지는, 워킹 셋 사이즈의 제한이 없는 문제가 발생합니다.

 

그래서 워킹 셋 윈도우 사이즈 t를 적절히 조절해야 합니다. 너무 크다면 워킹 셋이 커지게 되고 너무 작다면 워킹 셋에 페이지들이 충분히 들어갈 수 없는 문제가 발생합니다. 이런 문제들로 인해 1968년도에 제시된 워킹 셋은 단순히 개념적인 틀만 잡혔다고 할 수 있습니다.

 

 

 

액세스가 자주 일어나는 페이지를 메인 메모리에 올려두지 못한다면 페이지 폴트의 발생으로 수행이 느려지게 됩니다. 만약 한 프로세스가 많은 워킹 셋을 사용하여 메인 메모리를 포화시킨다면 다른 프로세스가 쓰레싱이 발생시키게 됩니다. 그래서 적당한 양의 워킹 셋을 설정하는 게 중요합니다. 

 

 

 

하지만 워킹 셋을 설정하는 방법에 대해서는 명시되어 있지 않습니다. 그렇기 때문에 워킹 셋, 윈도우 셋 사이즈를 결정하는 것은 굉장히 어려운 문제에 속합니다. 프로세스마다, 그리고 프로세스의 수행 중간중간에도 바뀌기 때문입니다. (어떤 코드에서는 많은 페이지를, 어떤 페이지에서는 적은 페이지를 액세스 하는 문제)

 

 

 

이 문제는 어려운 문제이긴 했으나 컴퓨터 엔지니어들이 해결했습니다. 이전에 예시로 들었던 VAS/VMS OS에서 설루션을 찾아볼 수 있습니다. 이 OS는 프로세스 당 resident set이 존재했었는데 이를 통해서 프로세스 당 할당받을 수 있는 페이지 프레임의 개수를 지정했습니다.

 

이 resident set 역시 자주 액세스되는 페이지들로 구성했어야 했습니다. resident set은 해당 프로세스가 발생시키는 page fault rate가 적당한 수치에 유지될 때 그때의 액세스 된 페이지들을 모아 만들어지게 됩니다. (page fault rate가 너무 적으면 다른 프로세스가 쓰레싱될 수 있고 너무 높아도 문제가 생기니, 적당한 수치를 유지하는 선에서 페이지들을 보관하는 것 같습니다.)

 

그래서 한 프로세스가 너무 page fault rate가 낮게 나오면 그 프로세스의 페이지들을 뺏어와 높은 page fault rate를 보이는 프로세스에게 주게 됩니다. 이 resident set을 워킹 셋으로 정의한다면 워킹 셋에 근접한 효과를 얻을 수 있습니다. 

 

 

 

어떤 프로세스가 idle이 되어 swap out이 되었다가 requset를 받아 다시 swap in 될 때 resident set을 전부 가지고 들어오게 됩니다. 만약 resident set을 전부 가지고 올 수 없다면 그 프로세스의 수행을 지연시키는 쓰로틀링(Throttling)을 통해 메인 메모리가 over commit 되는 것을 막아줍니다.

 

 

 

하지만 어떤 프로세스가 degree of multiprogramming을 낮춘다는 이유로 자주 swap out 된다면 문제가 발생하게 됩니다. swap in/out operation은 굉장히 많은 disk operation을 발생시키기 때문입니다. (프로세스 단위의 swapping도 쓰레싱을 만들 수 있음)

 

이런 문제들을 통제하기 위해 밸런스 셋(balance set)이 존재합니다. 밸런스 셋은 프로세스들이 가지고 있는 모든 페이지들의 집합으로 이 크기를 피지컬 메모리보다 작게 만들어 충분한 여유분의 메모리를 가지게 할당을 합니다. 

 

 

 

어떤 프로세스의 swap in/out을 결정하는 것도 일종의 스케줄링입니다. 프로세스가 swap out 당해있을 때 CPU를 받아서 수행하기 위해서는 swap in 스케줄링을 통해 들어온 다음 CPU를 할당받아야 합니다. swap in/out을 진행하는 스케줄링을 long term scheduling이라고 하며, CPU를 할당하는 스케줄링은 short term scheduling이라고 부릅니다. 

 

 

 

버츄얼 메모리 메니지먼트에서는 메모리가 무한한 것처럼 동작하지만 시스템이 밸런스 셋을 유지하기 위해 많은 프로세스들을 swap out 시키다 보면 스토리지에 있는 swap area가 꽉 차버리는 문제가 생깁니다. 이런 상태를 OOM(out of memory)이라고 이야기합니다. 

 

이 문제가 발생하면 OS가 swap out 되어 있는 프로세스들 중, 제거하더라도 사용자에게 피해가 적은 프로세스들을 전부 제거하게 됩니다.