네트워크 관리자에게는 며칠, 길게는 몇 주가 걸릴 수 있는 환경 설정 요청들이 마구 쏟아진다. 다행히 네트워크 민첩성을 높여줄 수 있는 여러 가지 방안들이 나오고 있는데, 그 중에서 네트워크 가상화(Network Virtualization), NFV(Network Functions Virtualization, 네트워크 기능 가상화), 그리고 SDN(Software Defined Networking, 소프트웨어 정의 네트워킹(SDN)이 가장 두드러진다.

난해한 용어들은 보기만 해도 머리가 지끈거리겠지만 이 접근 방법들은 네트워크 이동성이라는 큰 문제에 있어 각기 서로 다른 부분집합을 해결하기 위한 것이다. 네트워크 가상화와 NFV, SDN이 어떻게 다르고, 각각이 어떻게 프로그래밍 가능한 네트워크를 향한 길을 안내하는지 살펴보도록 하자.

네트워크 가상화 (Network Virtualization)

엔터프라이즈 네트워킹 관리자에게는 감당하기 어려울 정도로 네트워크 변경 요청이 쏟아진다. 변화에 대한 IT의 응답성을 개선하기 위해서는 네트워크를 자동화할 방법이 필요하다. 보통 이 경우 우리는 하나의 문제, 'VM을 서로 다른 논리적 영역으로 어떻게 옮길 것인가'를 해결하려고 한다. 네트워크 가상화는 말 그대로 흐름 수준에서 논리적으로 네트워크를 분할함으로써 기존 네트워크에 논리적 구역을 만드는 것이다(하드 드라이브에 파티션을 나누는 것과 비슷함).

네트워크 가상화는 오버레이, 즉 터널이다. 네트워크에 있는 두 도메인을 물리적으로 연결하지 않고 기존 네트워크를 통과하는 터널을 만들어 두 도메인을 연결하는 것이다. 네트워크 가상화의 가치는 특히 가상머신을 위해 관리자가 각각의 새로운 도메인 연결을 물리적으로 배선할 필요가 없다는 데 있다. 관리자가 기존의 방식을 바꿀 필요가 없으므로 편리하다. 인프라스트럭처를 가상화하고 기존 인프라스트럭처 위에서 변경 작업을 수행하는 새로운 방법을 얻게 된다.

네트워크 가상화는 고성능 x86 플랫폼에서 실행되며, 궁극적인 목표는 기존 인프라스트럭처로부터 독립적으로 VM을 이동하고 네트워크를 재구성할 필요가 없도록 하는 것이다. 또한 가상화 기술을 사용하는 모든 IT 환경을 대상으로 한다. 이 분야의 대표적인 업체는 현재는 VM웨어에 인수된 니시라를 꼽을 수 있다.

 네트워크 기능 가상화 (Network Functions Virtualization, NFV)

네트워크 가상화가 네트워크를 통과하는 터널을 만들고 흐름별 서비스라는 개념을 사용한다면, 다음 단계는 터널에 서비스를 배치하는 것이다. NFV는 방화벽 또는 IDPS와 같은 4/7계층 기능 또는, 로드 밸런싱(애플리케이션 딜리버리 컨트롤러)까지 가상화하는 것이다.

관리자가 포인트 앤 클릭으로 VM을 설정할 수 있다면, 같은 방법으로 방화벽이나 IDS/IPS를 켜면 좋지 않을까? NFV의 역할이 바로 이것이다. NFV는 다양한 네트워크 요소에 대한 모범 사례를 기본 정책과 구성으로 사용한다. 인프라스트럭처를 통과하는 터널이 있다면 이 터널에 방화벽이나 IDS/IPS를 추가할 수 있다.

NFV는 고성능 x86 플랫폼에서 실행되며, 사용자가 네트워크의 특정 터널에서 기능을 활성화할 수 있도록 해준다. NFV의 목표는 VM 또는 흐름을 위한 서비스 프로파일을 만들고 x86의 성능을 활용해서 네트워크 위에서 추상화를 구축한 다음(터널) 이 논리적 환경에서 가상 서비스를 구성할 수 있도록 하는 것이다. 제대로 구축된 NFV는 수동 프로비저닝과 교육에 드는 시간을 크게 줄여준다.

NFV는 오버프로비저닝의 필요성도 줄여준다. 고객은 네트워크 전체를 감당할 수 있는 대형 방화벽 또는 IDS/IPS 시스템을 구매하는 대신 필요한 특정 터널에 대해서만 기능을 구매할 수 있다. 이는 초기 자본 지출도 줄여주지만 진정한 혜택은 운영 측면의 이점이다. NFV는 소수의 시스템이 다수의 가상 서버를 실행하고 포인트 앤 클릭 프로비저닝 시스템이라는 측면에서 VM웨어와 매우 유사하다.

고객은 NV와 NFV가 다르다는 점을 알고 있지만 동일한 업체를 통해 두 가지 모두 구입하는 편을 선호할 수 있다. VM웨어가 현재 VM웨어 NSX에서 NV와 NFV 보안 기능을 제공하는 이유도 여기에 있다.

 소프트웨어 정의 네트워킹 (Software Defined Networking, SDN)

SDN은 미리 준비된 프로세스를 사용해서 네트워크를 프로비저닝한다. 예를 들어 어플라이언스를 사용해서 네트워크 탭을 구성하는 것이 아니라 탭을 구축하고자 할 때 네트워크를 프로그래밍할 수 있어야 한다.SDN은 제어 플레인(네트워크에 무엇이 어디로 이동할지 알려주는 역할)을 데이터 플레인(특정 목적지로 패킷을 보냄)으로부터 분리하는 방법으로 네트워크를 프로그래밍 할 수 있도록 한다. SDN의 기반은 오픈플로우(OpenFlow)와 같은 산업 표준 제어 프로토콜을 사용하고 SDN 컨트롤러를 통해 프로그래밍할 수 있는 스위치다.

네트워크 가상화와 NFV는 물리 네트워크에 가상 터널과 기능을 추가하지만 SDN은 물리 네트워크를 변경하며, 따라서 사실상 네트워크를 프로비저닝하고 관리하기 위한 새로운 외부적 수단이다. 1G 포트에서 10G 포트로 하나의 거대한 흐름을 옮기는 경우, 많은 수의 작은 흐름을 하나의 1G 포트로 집결시키는 경우 등이 사용 사례에 포함된다. SDN은 x86 서버가 아닌 네트워크 스위치에 구현된다.

세 가지 유형의 기술 모두 이동성과 민첩성을 위해 고안된 기술이다. 우리에게는 네트워크를 프로그램할 방법이 필요하고, 이를 위해서 네트워크 가상화, NFV, SDN과 같은 다양한 접근 방법이 있는 것이다.

네트워크 가상화와 NFV는 서버에 위치하며 전송된 "손질된" 트래픽과 상호작용하므로 기존 네트워크에서 가동할 수도 있다. 반면 SDN에는 데이터 플레인과 제어 플레인이 분리된 새로운 네트워크 구조가 필요하다.

'공부' 카테고리의 다른 글

정규 표현식  (0) 2016.07.07
IDS와 IPS  (0) 2016.07.07
네트워크 가상화  (0) 2016.07.07
인터프리터와 컴파일러  (0) 2016.07.06
JIT(Just-In-Time)  (0) 2016.07.06
MVC패턴  (0) 2016.06.26

인터프리터란?

컴파일러와는 다른 방식으로 코드를 기계어로 번역해 주는 프로그램. 스크립트 언어의 사실상 전부가 인터프리터 방식이고 각종 DSL(도메인 특화 언어)의 해석 엔진도 인터프리터로 구현된다. 코드를 한 줄씩 번역하는 방식으로 기계어 번역을 진행하기 때문에 실행 속도는 컴파일 언어보다는 느리다. 그러나 요즘의 인터프리터는 번역 결과를 캐싱하거나 JIT를 사용하는 등의 방법으로 실행 속도를 컴파일 언어에 상당히 근접한 수준으로 따라잡긴 했다. (그래도 컴파일 언어보단 느림)

여기까지 읽었다면 그 느린 것을 왜 쓰느냐는 의문에 도달하겠지만, 인터프리터 언어는 프로그램 수정이 간단하다는 장점이 있다. 컴파일러는 소스 코드를 번역해서 실행 파일을 만들기 때문에 프로그램에 수정 사항이 발생하면 소스코드를 수정해서 다시 컴파일을 해야 한다. 프로그램이 작고 간단하면 문제가 없지만 프로그램 덩치가 커지면 컴파일이 시간 단위가 되는 일이 많아진다. 하지만 인터프리터는 소스코드를 수정해서 실행시키면 끝. 이 장점 때문에 인터프리터 언어는 수정이 빈번히 발생하는 용도의 프로그래밍에서 많이 사용된다. 이 장점을 최대한 살려서 인터프리터를 적극적으로 채용한 것이 스크립트 언어다.

코드 상에 문법 오류가 있으면 컴파일을 거부하는 컴파일 언어와 달리, 구문 오류가 있는 곳까지는 일단 진행하고 보기 때문에 디버그에 유리하다는 장점이 있다. 물론 문법 오류가 잘 실행되지 않는 부분에 있으면 오류가 잘 잡히지 않아서 버그 있는 채로 출시할 수 있는 가능성이 컴파일 언어보다 다소 높은 편이다. 컴파일 언어는 문법 오류가 컴파일 단계에서 모두 잡히기 때문이다. 그러나 인터프리터 언어는 오류를 즉석에서 수정한 뒤 바로 실행하는 것이 가능하다는 크나큰 장점이 있기 때문에 그다지 큰 단점은 되지 못한다. 그리고 어차피 크리티컬한 오류는 문법 오류가 아닌 프로그램 자체의 버그로 발생하므로 문법 오류로 두 방식의 우열을 가리는 건 거의 무의미하다.

기계어로 된 목적 프로그램을 따로 생성해야 하는 컴파일러와는 달리, 소스 코드 그 자체로 실행하는 방식이다. 따라서 이론적으로는 소스 코드를 자기 자신이 수정하면서 실행하는 것도 가능하다.  컴파일 과정이 없기 때문에 수정이 간단하고 빠르다는 장점도 있다. 그러나 단점은, 소스 코드 공개를 막을 방법이 없다는 것. 때문에 몇몇 프로그래밍 언어에서는 인터프리터와 컴파일러를 둘 다 제공하기도 한다.


즉, 프로그래밍 언어의 소스 코드를 바로 실행하는 컴퓨터 프로그램 또는 환경을 말한다

컴파일러란?

어떤 프로그래밍 언어로 쓰여진 소스 파일을 다른 언어로 바꾸어주는 번역 프로그램. 대부분 고수준 언어를 기계어로 번역하는 프로그램을 일컫지만 엄밀히는 어떤 언어 A를 B로 바꾸면 그게 컴파일러다. Scheme을 C언어로 번역한다든지, 심지어 기계어를 C언어로 번역하더라도 컴파일러라고 칭할 수 있다. 

초기엔 어떤 프로그램을 작성하기 위해서는 컴퓨터 위에서 바로 돌아가는 기계어를 통하여 프로그래밍을 했다. 그러나 이런 과정은 생산성, 기기 간 호환성, 디버깅 등 모든 면에서 효율적이지 않기 때문에 컴퓨터 공학의 발전과 더불어 많은 부분이 추상화된 고수준 언어를 작성하고 이를 번역기를 통해 기계어로 번역하기 시작했는데, 이 번역기가 바로 컴파일러이다. 현재 많은 프로그램은 컴파일러를 통하여 전체를 기계어로 번역하여 실행하므로 프로그램 개발에 필수적인 툴 중에 하나다. 


반면에 소스를 한꺼번에 번역하지 않고 명령 하나하나를 실행할 때마다 해석하여 계산하는 방법도 있는데 이 해석기를 인터프리터라 해서 따로 분류한다.( 컴파일러가 번역기라면 인터프리터는 통역기인셈)

재밌는 것은 컴파일러도 결국 하나의 언어로 짜여진 프로그램이라는 점. 따라서 원리상 C언어 프로그램이 C언어를 번역하는 일이 가능하다. 이 경우, C 컴파일러를 사용하기 위하여 이 컴파일러를 컴파일하는데 C 컴파일러가 필요하다(..) 심지어 최근 버전의 gcc 컴파일러의 경우 C++을 사용하기 때문에 C 컴파일러를 컴파일하는데 C++ 컴파일러가 필요하다. 이런 현상을 부트스트래핑(bootstrapping)이라고 한다. 언어를 최초 설계할 때만 사용 가능한 다른 언어로 짜여진 컴파일러의 도움을 받은 이후로는 언어를 번역하는 컴파일러가 자기 자신의 언어로 짜여질 수 있다. 얼핏보면 모순적이지만 맨 처음에만 다른 언어의 도움을 받는다면 충분히 가능하다. 일반적으로 고수준 언어로 갈수록 생산성이 높아지므로 이런 접근은 컴파일러를 작성하는데 들이는 비용을 효과적으로 줄일 수 있다. 일례로, GHC라는 Haskell 컴파일러는 최초에 Lazy ML이라는 다른 언어로 작성되었다가, 자기 자신의 언어인 Haskell로 재작성 되었다.


원칙적으로 컴파일러는 프로그램을 기계어로 바꾸기만 할 뿐 이를 바로 실행이 가능하게 하지는 않는다. 여러 소스 파일에서 나온 결과물을 합치고 라이브러리도 포함시키는 등 별도의 작업을 거쳐야 실행이 가능해지는데 이를 수행하는 프로그램이 링커이다. 하지만 보통은 그냥 뭉뚱그려 컴파일러라 부르는 경우가 많다. 또한 요즘은 그냥 프로그램 하나만 돌리면 컴파일과 링킹을 한 번에 끝낼 수 있게 되어 있다. 물론 내부적으로는 컴파일러와 링커가 따로 있어서 이를 이용하는 경우가 많지만.

단점은 수정이 용이하지 않다는 점이다. 수정 사항이 발생하면 다시 컴파일을 해야 되는데, 작은 프로그램일 경우에는 문제가 되지 않지만 컴파일이 몇 시간씩 걸리는 덩치 큰 프로그램에서는 문제가 된다. 특히 수정 사항이 빈번하게 발생할 경우에는 큰 문제가 된다. 이 때문에 수정 사항이 빈번하게 발생할 것 같은 부분은 인터프리터를 쓰는스크립트 언어로 따로 빼 두는 기법을 많이 사용한다. (인터프리터는 속도는 느리지만 수정이 간단하다는 장점이 있다.)

어셈블리어를 번역하는 프로그램은 컴파일러라 하지 않고 따로 어셈블러라 한다.

요즘 컴파일러들은 기계가 프로그램을 빠르게 돌릴 수 있도록 적절한 최적화 작업을 하고 프로그래머가 실수할만한 부분을 경고하는 등 갈수록 똑똑해지는 추세이다.

OS와 함께 프로그래머의 스킬트리에서 최상위에 군림하는 스킬. 운영체제와 컴파일러를 스스로 만들 수준이 되면 일단 프로그래머 스킬트리는 전부 다 최소 한 개씩은 찍은 것이다. 거기서 더 나가면 최적화 가 있는데 이건 컴파일러의 보조 스킬. 대학교 컴퓨터공학 커리큘럼의 가장 마지막(4학년)에 있는 과목이기도 하다. 이걸 제작하려면 하드웨어와 소프트웨어 전부를 이해하고 있어야 하고 자료구조와 알고리즘에 대한 심도 깊은 이해와 함께 전산수학에도 능해야 한다. 그래서 컴파일러 1렙을 찍으면 취직 퀘스트는 통과를 못 하는 게 이상할 정도가 된다.

C 등의 고급 언어에서 CPU의 인스트럭션 하나로 해결할 수 있는 복잡한 기능(?)을 사용할 경우 특정 함수를 호출하면 컴파일러가 함수를 호출하는 명령을 넣어 주는 것이 아니라 그냥 그 자리에 어셈블리를 사용한 것과 동일하게 기계어 코드를 때려박는 경우가 있는데 이것을 intrinsic, 혹은 built-in function이라고 한다(인라인 함수와는 다르다). Compare-And-Exchange의 예를 들어(현대적인 CPU는 대부분 지원한다) a값이 m인 경우 n으로 바꾸는 코드의 경우 x86 CPU는 cmpxchg 인스트럭션 하나로 해결이 가능하다. 이러한 경우 컴파일러가 지원하는 인트린식을 사용하면 된다.


즉 컴파일러는 특정 프로그래밍 언어로 쓰여진 문서를 다른 프로그래밍 언어로 옮기는 프로그램을 말한다. 기존의 문서를 소스 코드 또는 원시 코드라 부르고, 출력되는 문서를 목적 코드라고 부른다. 목적 코드는 주로 다른 프로그램이나 하드웨어가 처리하기 용이한 형태로 출력되지만! 그 외에도 사람이 읽을 수 있는 문서 파일이나 그림 파일 등으로 옮기는 경우도 있다. 

고수준 언어 → 저수준 언어(어셈블리어, 기계어)

인터프리터와 컴파일러 차이


컴파일러인터프리터
번역단위전체한 줄씩
실행속도빠름느림
목적프로그램(소스코드 외 타 프로그램)생성생성 X
메모리할당목적 프로그램생성시 사용할당 X


'공부' 카테고리의 다른 글

IDS와 IPS  (0) 2016.07.07
네트워크 가상화  (0) 2016.07.07
인터프리터와 컴파일러  (0) 2016.07.06
JIT(Just-In-Time)  (0) 2016.07.06
MVC패턴  (0) 2016.06.26
싱글톤패턴(singleton pattern)  (0) 2016.06.26

JIT란?

C나 C++에서 하는 것처럼 프로그램을 실행하기 전에 처음 한 번 컴파일하는 대신, 프로그램을 실행하는 시점에서 필요한 부분을 즉석에서 컴파일하는 방식을 말한다.

JIT 사용

보통 인터프리터 방식의 언어 구현들이 성능 향상을 목적으로 도입하는 경우가 많은데, 같은 코드를 매번 해석하는 대신 실행하기 전에 그 부분만 컴파일을 해 두고 다음부터는 컴파일된 코드를 쓰기 때문에 인터프리터의 느린 실행 성능을 개선할 수 있다. JIT 이전부터 실행 성능 문제 때문에 바이트코드 컴파일을 도입했던 Java와 같은 언어들도 바이트코드를 해석하는 대신 컴파일된 기계어 코드를 직접 실행하는 쪽이 어쨌든 빠르기 때문에 역시 JIT를 도입하고 있다.

JIT 단점

단점이라면 초기 구동 후 얼마 간은 소스코드(혹은 바이트코드)를 컴파일하는 데에 시간과 메모리를 소모하기 때문에 정적 컴파일된 프로그램에 비해 초기 실행 속도와 메모리 사용량에서 손해를 본다는 것으로, 특히 실행 시간이 매우 짧은 경우에는 애써 컴파일된 코드를 제대로 사용하기도 전에 프로그램이 끝나는 배보다 배꼽이 더 큰 상황이 벌어지기도 한다.

'공부' 카테고리의 다른 글

네트워크 가상화  (0) 2016.07.07
인터프리터와 컴파일러  (0) 2016.07.06
JIT(Just-In-Time)  (0) 2016.07.06
MVC패턴  (0) 2016.06.26
싱글톤패턴(singleton pattern)  (0) 2016.06.26
공인 IP, 사설 IP, 고정 IP, 유동 IP  (0) 2016.06.23

MVC패턴이란?

MVC이란 Model View Controller의 약자로 에플리케이션을 세가지의 역할로 구분한 개발 방법론이다. 아래의 그림처럼 사용자가 Controller를 조작하면 Controller는 Model을 통해서 데이터를 가져오고 그 정보를 바탕으로 시각적인 표현을 담당하는 View를 제어해서 사용자에게 전달하게 된다.

Model, View, Controller

Controller

사용자가 접근 한 URL에 따라서 사용자의 요청사항을 파악한 후에 그 요청에 맞는 데이터를 Model에 의뢰하고, 데이터를 View에 반영해서 사용자에게 알려준다. 

Model

일반적으로 CI의 모델은 데이터베이스 테이블에 대응된다. 이를테면 Topic이라는 테이블은 topic_model이라는 Model을 만든다. 그런데 이 관계가 강제적이지 않기 때문에 규칙을 일관성 있게 정의하는 것이 필요하다.

View

View는 클라이언트 측 기술인 html/css/javascript들을 모아둔 컨테이너이다. 

웹에서 MVC패턴 예제


  1. 사용자가 웹사이트에 접속한다. (Uses)

  2. Controller는 사용자가 요청한 웹페이지를 서비스 하기 위해서 모델을 호출한다. (Manipulates)

  3. 모델은 데이터베이스나 파일과 같은 데이터 소스를 제어한 후에 그 결과를 리턴한다.

  4. Controller는 Model이 리턴한 결과를 View에 반영한다. (Updates)

  5. 데이터가 반영된 VIew는 사용자에게 보여진다. (Sees)



'공부' 카테고리의 다른 글

인터프리터와 컴파일러  (0) 2016.07.06
JIT(Just-In-Time)  (0) 2016.07.06
MVC패턴  (0) 2016.06.26
싱글톤패턴(singleton pattern)  (0) 2016.06.26
공인 IP, 사설 IP, 고정 IP, 유동 IP  (0) 2016.06.23
쓰레드(thread)와 프로세스(process)  (0) 2016.06.23

싱글톤패턴이란?

먼저 Singleton 패턴의 용도는 하나의 프로그램 내에서 하나의 인스턴스만을 생성해야만 하는 상황에서 쓰인다. 예를 들어 환경설정을 관리하는 클래스나 Connection Pool, Thread Pool과 같이 풀(Pool) 형태로 관리되는 클래스의 경우 프로그램 내에서 단 하나의 인스턴스로 관리되는 것이 일반적이며, 이 때 Singleton 패턴을 적용하는 것이 일반적인 경우라고 볼 수 있다. 

public class Singleton
{
     private static Singleton singleton = new Singleton();
     protected Singleton()
     {
          System.out.println("Maked Singleton");
     }
     public static Singleton getInstance()
     {
          return singleton;
     }
}

싱글톤의 기본형이다. singleton 멤버변수는 static 이어야한다는 것과 Singleton 클래스의 생성자는 private / protected 이어야한다는 것을 꼭 유념해야한다. private 일 경우는 결코 new 를 이용하여 인스턴스의 중복 생성을 방지하는 셈이기도 하나 상속이 되지 않는다는 단점이 있어 protected로 대게 선언한다.

Singleton의 인스턴스를 생성하기 위해 getInstance() 메소드를 이용한다. 맨 처음 getInstance() 을 호출하면 singleton 변수를 리턴하기 위해 전역변수로 선언되어 있는 singleton의 인스턴스를 static하게 생성한다. 그 후 getInstance()를 호출하면 static으로 생성되어 있는 singleton의 값을 받아와 리턴한다.

만약 getInstance()가 static이 아닐경우 해당 함수를 호출할때마다 가변적인 메모리 위치에 생성이 되므로 static으로 선언한다.

'공부' 카테고리의 다른 글

JIT(Just-In-Time)  (0) 2016.07.06
MVC패턴  (0) 2016.06.26
싱글톤패턴(singleton pattern)  (0) 2016.06.26
공인 IP, 사설 IP, 고정 IP, 유동 IP  (0) 2016.06.23
쓰레드(thread)와 프로세스(process)  (0) 2016.06.23
비동기(Async)통신과 동기(Sync)통신  (0) 2016.06.23

Page Replace Algorithm이란?

Virtual memory system에서 페이지 부재(page fault)가 발생했을때 주기억장치(메모리)의 모든 페이지 프레임이 사용중이라면 어느 페이지 프레임을 교체할 지 결정하는 알고리즘

FIFO(First In First Out)

페이지 교체 시, 메모리에 올라온지 가장 오래된 페이지를 내쫓는다.

장 점: 

  •  가장 간단한 페이지 교체 알고리즘

 단 점:

  • 가장 오래된 페이지가 초기화 모듈이라면 성능이 저하될 수 있음
  • Belady의 모순(Belady's anomaly)
    • 프로세스에게 프레임을 더 주었는데 오히려 페이지 부재율이 더 증가하는 현상

OPT(Optimal)

앞으로 가장 오랜 동안 사용되지 않을 페이지를 찾아 교체한다

 장 점: 

  •  모든 알고리즘보다 낮은 페이지 부재율
  •  Belady의 모순 발생하지 않음

단 점: 

  •  구현이 어려움. (프로세스가 앞으로 메모리를 어떻게 참조할 것인지 미리 알아내기 힘들기 때문)

LRU(Least Recently Used)

페이지 교체 시에 가장 오래 사용되지 않은 페이지를 교체 
최적 페이지 교체 알고리즘에 근사한 알고리즘으로 각 페이지마다 마지막 사용 시간을 유지 (미래시간 대신 과거 시간에 대해 적용한 최적 교체 알고리즘)

구현방식

 

  • 카운트 방식 : Counting에서 이 방식을 쓴다.
  • 스택 방식 : 그 많은 페이지를 관리하기 위해, doubly-linked-list를 차용한 스택을 쓰기엔 메모리, 연산량이 너무 아깝다

Least-recently-used Approximation

reference bit을 사용

  • reference bit: 하드웨어 지원없이 시스템은 LRU에 대한 도움을 제공하기 위해 reference bit의 형태를 지원.

이 방식은 페이지가 변하는 순서는 알 수 없지만 페이지가 교체 되는지 아닌지는 알 수 있는 방식

Counting-Based Page

참조 횟수를 가지고 교체될 페이지를 선정

Least Frequently Used

참조 횟수가 가장 적은 페이지를 교체

Most Frequently Used

참조 횟수가 가장 많은 페이지를 교체

 가장 작은 참조 횟수를 가진 페이지가 가장 최근에 참조됐기 때문에 가장 적게 참조됐고, 앞으로 사용될 것이라는 판단에 근거한 알고리즘이다.


대개 LFU, MFU 알고리즘을 잘 쓰지 않는다.

  • 현 시 비용이 많이 들고, 최적(OPT) 페이지 교체 정책에 제대로 근사하지 않기 때문


'공부 > OS' 카테고리의 다른 글

Page Replace Algorithm  (0) 2016.06.26
가상 메모리 (virtual memory)  (1) 2016.06.26
데드락(Deadlock)  (0) 2016.06.25
스핀 락(Spin lock), 크리티컬 섹션(Critical section), 세마포어(Semaphore), 뮤텍스(Mutex)  (1) 2016.06.25
OS  (0) 2016.06.25

+ Random Posts