해당 내용은 '소프트웨어 장인'이라는 책의 Chapter11장의 '잘못된 면접 방식'이라는 주제에서 와닿는 내용 몇 개만 발췌한 내용이다. 많은 분들이 공감할 거라 생각한다. 물론 아닌 분들이 계실수도 있겠지만 그 회사의 그 업무에 맞는 면접질문을 하는게 가장 좋다고 생각한다. 읽어보면서 공감가는 부분과 공감가지 않는 것에는 어떤 것이 있는지 생각해보며 읽으면 좋을 듯하다. 해당 내용들은 내게 공감이 많이 되었던 내용들만 추려 포스팅한 것이다.
1. 똑똑한 척하는 면접관을 세운다.
면접관이 지원자보다 똑똑하거나 더 우월해봉고 싶어해서는 안 된다. 면접관의 사사로운 즐거움을 위해 지원자를 힘든 상황으로 몰아붙이고, 자신의 직함, 권한, 지식같은 것들로 지원자를 압도하고 싶어 해서는 안된다. 어느 정도 경험이 있고 실력있는 개발자라면 면접관의 성향을 즉시 알아채고 같이 일하기 싫다는 생각을 할 것이다. 지원자 앞에서 겸손하고 정직해야 한다. 지원자를 프로페셔널 개발자로서 대하고, 채용을 위한 평가나 취조가 아니라 당신이 존주우하는 누군가와의 유익한 기술 토론이 되도록 면접을 이끌어야 한다. 무엇보다도, 지원자의 이야기를 경청하고 그에게 마음을 여는 것이 중요하다.
2. 답을 모르는 질문을 한다.
면접관으로서 어떤 질문에 어떤 답변이 나와야 하는지 잘 모르겠다면 채용중인 직무와 관련해서는 그다지 중요한 질문이 아닐 가능성이 높다. 해당 직무에 대해서 잘 알고 있다면 무엇이 중요하고 무엇이 중요하지 않은지 이미 알고 있을 것이다. 엉뚱한 질문으로 지원자를 혼란스럽게 하거나 잘못 이끌지 말자. 팀 동료에게 흔히 하지 않는 질문이라면, 팀 동료가 짜증을 낼 질문이라면, 지원자에게도 삼가해야 한다.
3. 종이에 코드를 작성하게 한다.
지원자에게 종이나 화이트보드에 코드를 작성토록 하는 것은 참으로 바보 같은 면접 방법이다. 면접관 스스로도 할 수 없는 일이나 실제 업무 현장에서 부딪히지 않을 상황을 지원자에게 요구해서는 안된다. 실제 업무에서도 종이에 테스트 코드 작성, 코드 리펙토링을 하는가? 고등학교 교사가 학생들에게 알고리즘의 의사 코드를 작성하라고 하는 것과 프로페셔널 소프트웨어 개발자를 채용하는 것은 다르다. 자신의 도구와 기술을 마스터하고 테스트와 리펙토링을 통해 잘 작성된 코드를 만들 수 있는 개발자를 찾아야한다.
4. 알고리즘 문제를 낸다.
알고리즘 무누제를 코딩 면접 과제로 선택하는 면접관들이 많다. 시스템 개발에 필요한 상당수의 업무들이 알고리즘에 대한 깊은 이해를 필요로 하지 않는다. 그럼에도 불구하고 "지원자의 문제 해결 능력을 보아야 한다"라고들 이야기한다. 물론 틀린 이야기는 아니지만 알고리즘 문제 대신 회사의 실제 프로젝트와 가까운 연습문제를 통해서도 '문제 해결 능력'을 평가할 수 있다. 여러 시스템의 문제들 중 거의 대부분이 알고리즘이 어떻게 작성되었느냐와는 관계가 없었다. 테스트가 덜 되었거나 또는 좋은 테스트 방법이 준비되지 못했거나, 잘못된 설계, 떨어지는 응집성, 깊은 종속성, 새 기능 추가 시 부족했던 리팩토링, 지속적인 요구사항 변경, 도메인 모델이 꼼꼼하지 못했거나 등이 가장 흔한 문제였다. 이러한 것들이 '실전 문제'였다. 알고리즘은 절차적이고 함수적인 형태로 구현된다. 알고리즘을 만들 때 비지니스 도메인 모델이나 클래스를 만들지는 않는다.
시스템의 주요 문제가 알고리즘이 아니라면 코딩 면접 때 알고리즘 문제 대신 실제 문제와 가까운 과제를 제시해야 한다. 지원자가 비즈니스 도메인을 표현하고 솔루션을 설계할 역량이 있는지 집중해야 한다. 테스트 주도 개발이나 설계에 스킬이 뛰어난 개발자를 찾고 있다면 그 부분을 반영할 수 있는 코딩 문제를 제시해야 한다. 애플리케이션이 온통 알고리즘에 대한 것이라면 당연히 알고리즘 개발 역량을 평가해야 한다. 요지는 코딩 면접에 알고리즘 문제를 내야 하느냐의 여부가 아니라 프로젝트를 위해 실제 필요한 역량이 무엇인지, 무엇이 가장 가치 있는지를 면접용 코딩 문제에 잘 반영하고 있어야 한다는 것이다.
해당 내용은 '실무로 배우는 시스템 성능 최적화'의 내용중 일부를 발췌한 내용입니다. 웹 방화벽에 의한 성능 저하 사례로 방화벽으로 인해 이러한 문제가 발생할 수 있구나 정도로 인지하고 있다면 비슷한 이슈가 발생했을 때 보다 빠르게 대응을 할 수 있을 거라 생각되어 남겨 봅니다.
현상
전국에서 사용하는 시스템으로, 특정 지역의 윈도우7 사용자만 화면 응답시간이 급격히 느려져 1분 이상 소요되는 현상이 발생했다. 그러나 항상 느린 것은 아니고 동일한 화면도 느릴 때와 빠를 때가 있는데 대부분은 느렸다.
접근 방법
현상을 정확히 확인하기 위해 해당 기관을 방문해 직접 화면을 사용하면서 네트워크 패킷을 수집해서 분석했다. 화면이 느릴 때는 HTTP 요청에서 TCP 재전송이 발생하면서 지연되는데, 결국은 서버로부터 HTTP 요청에 대한 ACK를 받지 못하고 타임아웃인 1분에 걸려서 해당 TCP 세션을 강제로 끊고 새로운 TCP 세션을 맺어 HTTP 요청을 보내어 응답을 받음으로써 1분 이상 소요됐다.
그런데 이상한 것은 아파치 웹 서버의 Keepalive 타임아웃이 5 초인데 사용자단 브라우저 TCP 세션은 5초가 이상 지나도 계속 ESTABLISH 상태를 유지하고 있고, 느릴 때는 5초 이상 경과된 TCP 세션을 사용하고 있었다. 그러나 웹 서버에서는 Keepalive 5초가 경과해서 해당 TCP 세션을 끊기 위해 FIN을 보냈음에도 클라이언트로부터 FIN을 받지 못하고 있는 TIME_WAIT 상태였다.
따라서 클라이언트와 웹 서버 사이 어디에선가 웹 서버가 보낸 TCP 세션 종료 신호인 FIN 패킷을 삼키고 있는 것으로 판단했다. 이런 현상이 특정 기관 사용자에게서만 발생하고 있어 해당 기관 내부 네트워크 이상으로 판단했다. 그러나 웹 서비스의 대표 IP인 L4의 가상 IP 대신 실제 서버 IP를 사용해 테스트를 진행하면 웹 서버 2대 모두로부터 정상적으로 클라이언트가 FIN 패킷을 받았다. 이에 L4 가상 IP 사용과 실 서버 IP 사용 시 발생하는 차이가 웹 방화벽 경유로 기인했음을 확인하고 L4 가상 IP를 사용하더라도 웹 방화벽을 경유하지 않도록 네트워크 설정을 수정해 다시 테스트를 진행한 결과, 웹 서버가 보낸 FIN 패킷을 클라이언트가 정상적으로 받는 것이 확인됐으며, 화면 응답시간도 정상이었다.
원인
웹 서버는 Keepalive 5초가 경과한 TCP 세션을 끊고 있으나 FIN 패킷이 클라이언트에 전달되지 않아 클라이언트는 웹 서버가 close한 세션을 살아있다고 생각하고 해당 TCP 세션으로 HTTP 요청을 전송함으로써 이상을 감지하기까지 오래 걸려 화면 지연이 발생했다. 웹 방화벽에서 웹 서버가 보낸 FIN 패킷을 삼킨 것으로 테스트에서 확인했다.
블로그를 처음 시작하게 된 건 2014년이었다. 처음 시작은 네이버 블로그에서 부터시작했었다.
처음에 블로그를 시작하게 된 계기는 2014년 9월쯤 회사에서 블로그를 만들고 일주일에 하나씩 글을 쓰라는 반강제적인 요구에 의해서 였다. 그렇게 나는 처음 포스팅이라는걸 해보게 되었다. 내가 이렇게 포스팅 하는 글을 남들이 본다고 생각하니 어디서 부터 어떻게 써야할지도 되게 막막했었던 기억이 난다. 그래서인지 포스팅 하는 것 자체가 나에겐 스트레스로 다가왔고 자연스럽게 각자의 팀에 배정되고 나서 부터 터치를 받지 않게 되자 포스팅과는 당연시스럽게 거리가 멀어졌다.
그렇게 6개월 정도 흐르고 다시 포스팅을 시작하게 된 것은 내가 다른 블로그 글들로 부터 많은 도움을 받고 있고 나도 이렇게 글을 남기면 남들이 내 글을 보고 도움을 받을 수 있겠다는 생각에서였다. 그렇게 나는 회사에서 업무를 하다가 처리했던 기술 이슈들 삽질, 그리고 경험들을 블로그에 남겼다. 하지만 이전과 같이 블로그에 글을 쓸 때 마다 정말 내가 겪고 처리한 이슈이외에도 관련된 내용들을 수집해 정말 누가 봐도 괜찮은 포스팅을 하기위해 노력하다보니 글 하나를 쓰는데 많은 시간이 걸렸다. 그렇다보니 일주일에 포스팅을 하나씩 하자고 마음먹었던 것과는 달리 한 달에 하나 두 달에 하나씩 쓰고 있는 나의 모습을 발견하였다.
그렇게 포스팅을 하는데 회의감을 느꼈고 또 잠깐의 공백이 생겼던 것 같다. 포스팅을 하고 있지 않던 그 기간동안 느꼈던 것은 '그래 그냥 누군가 보는데 의식하지말고 정말 그냥 내 개인 웹 노트라고 생각하고 너무 부담갖지 말고 포스팅을 해보자'라는 생각이 들었다. 그즈음이 광고관련 팀으로 이동을 했을 때라 어느정도 광고에 대한 개념도 생겨있었고 adsense를 달아 수익화도 해보고 싶다는 생각이 들었다.
그래서 나는 naver블로그에서 tistory블로그로 갈아타게 된다. 기존의 naver블로그의 글들을 evernote를 통해 tistory로 옮기고 정말 내 개인 노트에 글을 작성하듯 단순 한 것부터 내가 문득문득 든 생각, 읽었던 좋았던 문구들을 가볍게 써나가기 시작했다. 그렇게 포스팅을 하는데 부담감이 사라지니 자연스레 글을 쓰는 횟수도 많아졌고 자연스레 방문자수도 증가했다. 물론 심도 있는 글들을 많이 쓰지 못해 이탈률이 높긴 했지만 그 전처럼 포스팅 하나하나를 쓰는데 너무 많은 시간과 노력을 들이며 부담감을 느끼고 싶지 않았다.
그렇게 티스토리 블로그를 운영한지 벌써 4년차가 되어가고 작년 2019년의 평균 하루 방문자수는 400~600정도 사이에 이르렀다. 그러다가 최근 처음으로 하루 방문수가 2020/02/18, 2020/02/19 이틀 동안 1,000이 넘었다.
해당 글은 이전에 내가 읽었던 개발자의 커리어와 관련된 글 중 인상깊었던 글을 모아 포스팅했던데 지나지 않았다. 포스팅을 하는데 오래걸리지도 않았을 뿐더러 많은 노력을 하진 않았지만 해당 글로 인해 이틀간이나 하루 방문수가 1,000을 넘게 되었던 것이다.
물론 하루 방문수가 중요한 것은 아니다. 내가 느꼈던 것은 '뭐라도 하지 않으면 아무것도 일어나지 않고 내가 들인 노력, 시간과는 별개로 컨텐츠가 사람들에게 많이 검색되고 읽힐 수 있다는 것이다.' 나는 작년부터 유튜브 컨텐츠도 만들고 있지만 블로그 글들의 통계를 보며 정말 유튜브도 너무 컨텐츠를 잘만드려고 노력하다가 한달에 한번도 안올리는 것 보다는 가볍게 자주 올리는 것이 내 목표인 구독자 천명에 더 빨리 다다를 수 있을 거라는 생각이 들었다.
그리고 항상 느끼지만 꾸준함에 대한 어려움을 느끼고 무엇인가를 꾸준히 하는 사람들에 대한 존경심을 가지게 된다. 꾸준함은 또 하나의 재능이라고 생각하고, 지금 내가 하고 있는 기술블로그, 유튜브, 운동, 개발 모두 남들과 비교했을 때 느리더라도 꾸준히 앞으로 한 발짝 한 발짝 나아가다 보면 좋은 결과가 있을 거라고 생각한다. 아래의 말로 포스팅의 마무리를 지어보려 한다. 모두 원하는 목표에 도달할 때 까지 화이팅이다!
참묘하다 살아서는 어머니가 그냥 어머니더니, 그 이상은 아니더니 돌아가시고 나니 그녀가 내 인생의 전부였다는 생각이 든다.
아이에서 어른이 된다는 건 자신이 배신당하고 상처받는 존재에서 배신을 하고 상처를 주는 존재인걸 알아 채는 것이다.
우리가 알고 있는 카오스는 혼돈, 혼란, 무질서를 의미하지만, 인문학적 의미의 카오스 이론은 그 혼돈, 혼란, 무질서 속에서도 일정한 규칙이 있는 걸 의미한다.
내 자존심을 지킨답시고, 나는 그녀를 버렸는데, 그럼 지켜진 내 자존심은 지금 대체 어디에 있는 걸까?
머니문(Moneymoon)의 함정에 빠지지 말라, 머니문이란 어떤 물건을 구매하고 흡족해 하는 심정이 유지되는 기간을 의미한다. 당신이 그것을 구입하기 위해 돈을 지불했다고 해서 반드시 그것이 어떤 가치를 갖는 것은 아니다. 우리가 돈을 지불한 대상 중에서 제값을 하지 않는 것도 많다. 우리는 구매를 하는 과정에서 많은 실수를 저지르지만 다만 그것을 인정하고 싶어 하지 않을 뿐이다.
활자를 읽는 것에 대한 거부감을 갖고 있다는 것은 진수성찬을 두고 구경만 하는 것과 같다.
사랑이라는 감정을 배우는 요령은 자기감정에 충실한 거에요. '나중에 사랑이 아니면 어쩌지?'이런 생각하지 마세요. 그런 생각하면 사랑 못해요. 하나만 따져요. 감정에 정직했느냐만, 내가 가진 감정이 사랑인지 아닌지는 모르죠. 하지만 사랑이라고 느꼈으면 정직하게 하고, 아니라는 게 확인 될 때 아니라고 이야기해주는 것, 이게 자신과 상대방에 대한 최소한의 예의입니다. 그것만 지키세요.
최근 운영하고 있는 하둡 클러스터의 노후 장비 교체건으로 데이터노드 한대를 제거 하는 작업이 진행되었다.
해당 로그는 클러스터에 붙어 hdfs을 쓰고 있던 외부 서버에서 발생한 로그이다.
org.apache.hadoop.ipc.RemoteException(org.apache.hadoop.hdfs.server.namenode.LeaseExpiredException): No lease on /user/example....log._COPYING_ (inode 428475201): File does not exist. Holder DFSClient_NONMAPREDUCE_-1052637306_1 does not have any open files.
로그가 발생한 이유는 해당 서버가 hdfs 해당 데이터노드 특정 파일에 write작업을 하고 있었는데 중간에 데이터노드가 내려가면서 write하고 있던 파일을 찾지 못해 발생한 것이다.
HDFS에서 Lease는 다음과 같이 정의된다.
In HDFS these locks are called Leases. Leases are granted to a client which request to open a file for a write operation (e.g. create / append / truncate a file.) Every lease belongs to a single HDFS Client but could be for several HDFS files. Often enough a lease has several thousand files open for write by a single HDFS client. As the client opens and closes files, the appropriate lease must be identified and updated. The exact datastructures have been changed quite frequently over the years to provide better lookups, better reverse lookups, speed and space efficiency etc. However all this accounting obviously is done on the NameNode. This is in stark contrast to GFS, where a lease is tracked by the Namenode (master server in their parlance) and Datanodes (chunk servers in their parlance) (Section 3.1 in the Google File System paper). For HDFS this means the Namenode has a higher overhead of now maintaining these leases (something GFS expressly wanted to avoid). However this also allows HDFS to allow renames of files being written (which in my experience is not too uncommon an operation.)
이 경우 외에도 스파크(Spark)나 hive의 병렬 작업시에도 작업이 꼬여 발생할 수 있다는 걸 검색을 하다가 알게되었다.
가상메모리에 대해 설명하기 앞서 자바 기반 솔루션의 경우 설정한 최대 힙 메모리 이상을 사용하지 않기 때문에 최대 힙 메모리가 운영체제의 메모리를 넘기지 않도록 설정됬다면 운영체제의 메모리 부족이 발생할 가능성은 낮다. 하지만 한정된 힙 메모리 내에서 동작하기 때문에 대량의 데이터 처리와 빈번한 GC로 인한 성능 저하가 유발될 가능성이 있다. OS 메모리 용량이 많아 힙 메모리를 과하게 크게 설정한 경우에는 메모리를 청소하는 GC 작업으로 순간 순간 멈추는 시간이 길어져 서비스 안정성이 떨어질 수도 있다.
오라클 버퍼 캐시처럼 데이터베이스는 디스크에서 데이터를 읽어옮으로써 발생하는 성능 저하를 개선하기 위해 메모리에 최근에 사용한 데이터 블록을 캐시해서 재사용하는 알고리즘이 있다. 통상 이 버퍼에 대한 캐시 적중률은 90%이상 나오는 것이 일반적인데, 캐시의 메모리 크기가 너무 작게 설정된 경우 캐시 적중률이 떨어져 디스크에서 데이터 블록을 읽어와야 하는 ㅂ니도가 늘어나 성능 저하를 유발할 수도 있다. 반대로 캐시를 크게 설정해 운영체제에서 스왑이 발생하게 되면 오히려 작게 설정한 것보다 성능이 더욱 악화되어 서비스가 거의 멈추는 상태가 유발될 수도 있다.
Virtual Memory(가상메모리)
서버는 설치할 수 있는 메인 메모리 (Main memory, Physical memory)에 한계가 있고, 예상치 못하게 메모리 사용량이 크게 증가할 수도 있지만 메모리는 비싼 자원으로 언제 발생할지 모르는 상황에 대비해 메모리를 충분히 확보하기 어렵다. 그래서 운영체제는 위와 같은 제약사항을 극복하기 위해 상대적으로 값싼 디스크를 보조 메모리로 사용하는 방식을 사용하고 있다. 디스크의 일정 공간을 할당해 보조 메모리 용도로 사용하는데 이를 페이징스페이스라고 한다.
메인 메모리(주 기억장치)와 디스크의 페이징스페이스(Pagingspace, 보조 기억장치)를 묶어 하나의 메모리처럼 동작하게 함으로써 메인 메모리 한계를 넘는 메모리 사용을 가능하게 하는 것이 가상 메모리다.
운영체제에서 관리하는 메모리 액세스 단위를 페이지(page)라고 하며 통상 4KB 단위다. 이 페이지 단위로 일부는 메인 메모리에 있을 수도 있고 또 일부는 페이징스페이스에 있을 수도 있는 것이다.
프로세스 내에서 사용 중인 가상 메모리 주소만 봐서는 해당 페이지가 메인 메모리에 있는지 페이징스페이스에 있는지 확인할 수 없다. 그렇다고 페이징스페이스가 메인 메모리와 동일한 것은 아니다. 메인 메모리의 입출력 속도가 디스크에 비해 비교가 안 될 정도로 우수하기 때문에 프로세스가 기동되면 기본적으로 메인 메모리를 사용하다가 부족해지면 페이징스페이스를 사용하게 된다. 이때도 CPU가 페이징스페이스에 있는 데이터를 메인 메모리처럼 바로 사용할 수 있는 것이 아니라 사용 빈도가 낮은 프로세스의 메인 메모리 사용 부분을 페이징스페이스 부분으로 옮겨 여유 메모리를 확보한 후 사용할 페이징스페이스 부분을 메인 메모리로 로드해서 사용하는데, 이를 스와핑이라고 한다. 그래서 CPU가 직접 접근할 수 있는 메인 메모리를 활성 가상 메모리(Active virtual memory)라 하고, 페이징스페이스를 비활성 가상 메모리(Inactive virtual memory)라고 한다.
가상 메모리 주소는 프로세스 내에서만 유효한 주소다. 각 프로세스는 가상 메모리 주소와 실제 주소 간의 매핑 테이블 (Virtual-to-physical translation table)을 가지고 있어 가상 메모리 주소로 실제 주소를 찾아갈 수 있게 돼 있다. 실제 주소는 메인 메모리와 페이징스페이스의 주소를 가리킨다.
페이징스페이스는 메인 메모리가 부족할 때 사용하는 디스크 공간으로, 스왑 스페이스(Swapspace)라고도 한다.
1GB 메모리가 탑재된 시스템에서 이미 900MB 메모리를 운영체제와 다른 프로세스가 사용하고 있는데, 300MB 메모리를 사용하는 프로세스를 새로 실행한다고 가정해 보자. 여유 메모리가 100MB밖에 없어 신규 프로세스를 기동할 수 없는 상황으로 보인다. 그러나 운영체제는 현재 사용 중인 900MB 메모리 중 200MB 정도를 디스크에 존재하는 페이징스페이스라는 곳으로 옮김으로써 메인 메모리에서 300MB를 확보해 신규 프로세스를 수행한다.
즉, 페이징스페이스는 운영체제가 메인 메모리 크기 이상의 메모리를 사용할 수 있게 해주는 역할을 한다. 그러나 시스템 성능 관점에서 보면 페이징스페이스는 디스크에 프로세스 메모리를 쓰고, 읽는 스와핑 작업으로 인해 메모리 접근만으로 처리될 때메 비해 큰 성능 저하가 발생한다. 따라서 스와핑이 발생하지 않도록 메모리 여유율을 유지하는 것이 성능에 중요하다.
2. 페이징(Paging)
가상 메모리 체계에서는 운영체제가 인식하는 일정한 크기(4KB, 64KB)의 데이터 기록 단위를 페이지라고 한다. 메인 메모리로부터 한 페이지의 데이터를 보조 기억장치(디스크)로 복사하거나 보조 기억장치로부터 메인 메모리로 로드하는 것을 페이징이라고 한다.
3. 스와핑(Swapping)
메모리에서 페이지 혹은 세그먼트 단위 데이터를 교환하는 것으로 컴퓨터가 메모리보다 큰 프로그램을 실행하거나 메모리보다 큰 데이터 파일을 다룰 수 있게 한다. 가상 메모리 체계에서는 페이징 기법을 이용해 스와핑을 수행한다. 스와핑은 프로세스가 사용하는 메모리 일부를 페이징스페이스로 옮기거나 페이징스페이스로부터 메모리로 로드하는 것을 가리킨다.
4. 페이지 부재(Page Fault)
페이징 방식의 가상메모리에서 CPU가 사용하려는 페이지가 메인 메모리에 없는 경우다. 사용하려는 가상 메모리 주소에 해당 페이지를 매핑 테이블에서 주소 변환할 때 해당 페이지가 메인 메모리에 없다고 표시돼 있으면 페이지 부재가 발생한다. 이 경우 해당 페이지를 디스크에 있는 파일 또는 페이징스페이스에서 가져와야 하고 메인 메모리가 부족한 경우에는 다른 페이지와 교체해야 한다.
5. 페이지 인(Page In)
가상 메모리에서 페이지 부재가 일어났을 때 디스크에 있는 프로그램이나 데이터를 메모리에 로드하는 것
6. 페이지 아웃(Page out)
가상 메모리에서 페이지 부재가 발생했을 때 메모리가 부족하면 페이지 스틸러(Page stealer)는 기존 메모리를 디스크로 기록하는 페이지 아웃이라는 작업을 수행한다. 기록 대상 메모리가 프로세스의 작업 세그먼트(Work segment)영역에 있는 메모리면 페이징스페이스로 기록하고, 파일에서 읽어 들인 내용(Permanent segment)인 경우 페이지의 내용이 변경됐으면 디스크의 해당 파일에 기록하고 그렇지 않으면 소멸시킨다.
7. 페이지 스캔률(Page Scan Rate)
운영체제는 일정량의 여유 페이지(Free page)를 확보해서 필요할 경우 즉시 제공하기 위해 페이지 스캔 (Page scan)이라는 검색을 통해 해제함으로써 여분으로 확보할 페이지를 찾는다. 여유 페이지 목록(Free page list) 임계치보다 여유 페이지 수가 줄어들면 메모리 관리자는 기존의 페이지 인된 것 중에서 LRU 알고리즘 검색을 통해 페이지 아웃이 가능한 것을 찾아 페이지 아웃시킨 후 여유 페이지로 변경한다. 여기서 페이지 아웃이 가능한 페이지를 탐색하는 빈도를 의미하는 페이지 스캔률이 나오는데 빈도가 높다는 것은 해제할 페이지가 넉넉하지 못하기 때문에 자주 메모리를 탐색해야 한다는 의미로 볼 수 있다.
