Thrashing(쓰레싱)

- 메모리 영역에 접근하게 될 때, 메모리에 페이지 부재(=페이지 폴트(Page fault)율이 높은 것을 의미하며, 심각한 성능 저하를 초래합니다.

- 활발하게 사용되는 페이지 집합을 지원해 줄 만큼 프레임이 충분히 할당 받지 못한 프로세스는 페이지 폴트(Page fault)가 발생하게 됩니다.

이 때, 페이지 교체가 필요하지만 이미 활발히 사용되는 페이지들만으로 이루어져 있으므로 어떤 페이지가 교체되던 바로 다시 페이지 교체가 필요하게 될 것입니다.

결과적으로 바로바로 반복해서 페이지 폴트가 발생하며, 교체된 페이지는 또 다시 얼마 지나지 않아 읽어올 필요가 생기게 됩니다. 이렇게 과도한 페이징 작업을 Thrasing(쓰레싱) 이라 합니다.

(쓰레싱의 원인)

1) 다중 프로그래밍 정도가 높아짐에 따라 CPU이용률이 높아지게 되고, CPU이용률이 최대값에 도달했을 때, 다중 프로그래밍의 정도가 그 이상으로 커지게 되면 쓰레싱이 일어나게 되고 CPU이용률은 급격히 떨어집니다.

2) 운영체제는 CPU이용률을 감시하며, CPU이용률이 너무 낮아지면 새로운 프로세스를 시스템에 추가하여 다중 프로그래밍의 정도를 높이게 됩니다. 이 때 전역 페이지 교체 알고리즘을 사용하여 어떤 프로세스의 페이지인지에 대한 고려없이 교체를 수행하게 됩니다.

그런데, 교체된 페이지들이 해당 프로세스에서 필요로 하는 것이었다면 그 프로세스 역시 페이지 폴트를 발생시키고 또 다른 프로세스에서 프레임을 가져옵니다.

이러한 프로세스들이 페이지 스왑 인, 스왑 아웃을 위해 페이징 장치를 사용해야 하는데, 이 장치에 대한 Queueing 이 진행되며 Ready-Queue는 비게 됩니다.

프로세스들이 페이징 장치를 기다리는 동안 CPU이용률은 떨어지게 되고, CPU 스케줄러는 이용률이 떨어지는 것을 보고 높이기 위하여 새로운 프로세스를 추가하여 다중 프로그래밍의 정도를 더 높입니다.

새로 시작하는 프로세스는 실행중인 프로세스들로부터 프레임을 가져오고자 하며, 더 많은 페이지 폴트와 더 긴 페이징 대기시간을 야기하게 됩니다.

결과적으로  CPU이용률은 더 떨어지게 되며, CPU스케줄러는 다중 프로그래밍의 정도를 더 높이려 하게 되어 쓰레싱이 일어나게 됩니다. 따라서 시스템 처리율은 상당히 낮아지고 페이지 폴트는 늘게되어 실질적인 메모리에 접근하는 시간은 증가하고 프로세스들은 페이징 하는데에 시간을 소비하게 되어 아무런 일도 할 수 없는 상태가 됩니다.

[다중 프로그래밍의 정도]

쓰레싱은 지역교환 알고리즘이나 우선순위 교환 알고리즘을 사용해 제한할 수 있습니다.

-> 지역교환 알고리즘 하에서는 한 프로세스가 쓰레싱을 유발하더라도 다른 프로세스로부터 프레임을 뺏어 올 수 없으므로 다른 프로세스는 쓰레싱에서 자유로울 수 있습니다.

(쓰레싱 현상 방지)

: 각 프로세스가 필요로 하는 최소한의 프레임 갯수를 보장해주어야 합니다.

참고 ) http://faithpac27.tistory.com/entry/쓰레싱-Thrashing-이란

fork()와 exec()는 모두 한 프로세스가 다른 프로세스를 실행시키기 위해 사용하게 됩니다.

exec에는 execl, execv등 여러가지 함수군을 가지고 있습니다. exec의 함수군에 대해서는 아래쪽에서 차이를 간단히 정리하고자 합니다.

우선 fork()와 exec()의 차이점은 fork() 시스템 호출은 새로운 프로세스를 위한 메모리를 할당합니다. 그리고 fork()를 호출한 프로세스를 새로운 공간으로 전부 복사하게 되고, 원래 프로세스는 원래 프로세스대로 작업을 실행하고 fork()를 이용해서 생성된 프로세스도 그 나름대로 fork() 시스템 콜이 수행된 라인의 다음 라인부터 실행이 됩니다. (새로 생성된 프로세스는 원래의 프로세스와 똑같은 코드를 가지고 있습니다.)

반면, exec()는 fork()처럼 새로운 프로세스를 위한 메모리를 할당하지 않고, exec()를 호출한 프로세스가 아닌 exec()에 의해 호출된 프로세스만 메모리에 남게됩니다.

간단히 정리하면, fork()의 결과는 프로세스가 하나 더 생기는 것입니다.( = 프로세스 id- PID 가 완전히 다른 또 하나의 프로세스가 생기는 것)

반면 exec()실행의 결과로 생성되는 새로운 프로세스는 없고, exec()를 호출한 프로세스의 PID가 그대로 새로운 프로세스에 적용이 되며, exec()를 호출한 프로세스는 새로운 프로세스에 의해 덮어 쓰여지게 됩니다.

이제, exec()관련 함수들에 대해 조금 간단히 다뤄볼까 합니다. exec는 execl, execv, execlp, execvp 등이 있습니다.

이들에 대하여 본 4가지만 간단히 구분하는 방법을 정리해보았습니다.

exec를 먼저 l계열(execl, execlp)과 v계열(execv, execvp)로 나누어 설명하겠습니다.

l계열 : 인자를 열거하는 방식이 나열형

v계열 : 인자를 열거하는 방식이 배열형

다음으로 p가 붙은 계열(execlp, execvp), 안붙은 계열(execl, execv)로 나누어 정리하면,

p가 안붙은 계열 : 경로를 지정해주면 ,현재/절대경로를 기준으로 찾게 됩니다.(경로로 실행파일을 지정)

p가 붙은 계열(path) : path에 잡혀있으면 실행됩니다.(실행파일의 이름만 지정)

exec계열은 첫번째 인자의 코드가 들어오고 나머지 기존에 exec아래에서 실행해야할 코드는 전부 잃어버리게 된다는 점을 가지고 있다고 보시면 됩니다.

IPC(Inter Process Communication) - 프로세스 간 통신에 대하여 종류와 특징들에 대하여 살펴보겠습니다.

[리눅스 커널 구조]

- 위 그림처럼 Process는 완전히 독립된 실행객체입니다. 서로 독립되어 있다는 것은 다른 프로세스의 영향을 받지 않는다는 장점이 있습니다. 그러나 독립되어 있는 만큼 별도의 설비가 없이는 서로간에 통신이 어렵다는 문제가 있게 됩니다. 이를 위해서 커널 영역에서 IPC라는 내부 프로세스간 통신 - Inter Process Communication을 제공하게 되고, 프로세스는 커널이 제공하는 IPC설비를 이용해서 프로세스간 통신을 할 수 있게 됩니다.

IPC의 2가지 표준(System V IPC와 POSIX IPC)

- System V IPC는 오래된 버전이고 POSIX IPC는 비교적 최근에 개발된 표준입니다. System V IPC는 오랜 역사를 가진 만큼 이기종간 코드 호환성을 확실히 보장해 주지만, API가 오래되었으며, 함수명도 명확하지 않습니다. POSIX IPC는 직관적으로 API가 구성되어 있어서 상대적으로 조금 더 사용하기 쉽다고 보여집니다.

IPC 설비들

- 현실에서도 필요에 따라 다양한 통신 설비들이 존재하는 것처럼 IPC에도 다양한 설비들이 존재합니다. 각각의 필요에 따라서 적당한 통신 설비들이 준비되어야 하는 것과 마찬가지로 내부 프로세스간 통신에도 그 상황에 맞는 IPC 설비를 선택할 필요가 있게 됩니다.

상황에 맞는 IPC의 선택은, 특히 fork()를 이용해서 만들어진 멀티 프로세스의 프로그램에 있어서 중요합니다. 잘못된 IPC 설비의 선택은 코딩과정을 어렵게 만들거나 프로그램의 작동을 효율적이지 못하게 만들 수 있기 때문입니다.

1) PIPE (익명 PIPE, Anonymous PIPE)

- 위 그림은 PIPE의 작동원리를 보여줍니다. 파이프는 두 개의 프로세스를 연결하게 되고, 하나의 프로세스는 데이터를 쓰기만, 다른 하나는 데이터를 읽기만 할 수 있습니다. 한쪽 방향으로만 통신이 가능한 파이프의 특징 때문에 Half-Duplex(반이중) 통신이라고 부르기도 합니다.

PIPE와 같은 반이중 통신의 경우 하나의 통신선로는 읽기나 쓰기 중 하나만 가능하므로 만약 읽기와 쓰기, 즉 송/수신을 모두 하기 원한다면 두개의 파이프를 만들어야만 가능해집니다.

PIPE는 매우 간단하게 사용할 수 있다는 장점이 있습니다. 만약 한쪽 프로세스가 단지 읽기만 하고 다른 쪽 프로세스는 단지 쓰기만 하는, 단순한 데이터 흐름을 가진다면 고민 없이 PIPE를 사용하면 됩니다. 단점은 반이중 통신이라는 점으로 만약 프로세스가 읽기와 쓰기 통신 모두를 해야 한다면 PIPE를 두개 만들어야 하는데, 구현이 꽤나 복잡해 질 수 있습니다. 만약 전이중 통신을 고려해야될 상황이라면 PIPE는 좋은 선택이 아니라고 보여집니다.

2) Named PIPE(FIFO)

- 익명 파이프(Pipe)는 통신을 할 프로세스가 명확하게 알 수 있는 경우 사용합니다. 예를 들어 자식과 부모 프로세스간 통신의 경우에 사용할 수 있으며, Named PIPE는 전혀 모르는 상태의 프로세스들 사이의 통신의 경우 사용합니다. 익명 파이프(PIPE)의 단점으로 같은 PPID(같은 부모 프로세스)를 가지는 프로세스들 사이에서만 통신이 가능하지만, Named PIPE는 그 부분을 해결한, PIPE의 확장이라고 할 수 있을 것입니다. Named PIPE는 부모 프로세스와 무관하게 전혀 다른 모든 프로세스들 사이에서 통신이 가능한데 그 이유는 프로세스 통신을 위해 이름이 있는 파일을 사용하기 때문입니다. Named PIPE의 생성은 mkfifo를 통해 이뤄지는데, mkfifo가 성공하면 명명된 파일이 생성됩니다.

단점으로는, Named PIPE도 PIPE의 또 다른 단점인 읽기/쓰기가 동시에 가능하지 않으며, read-only, write-only만 가능합니다. 하지만 통신선로가 파일로 존재하므로 하나를 읽기 전용으로 열고 다른 하나를 쓰기전용으로 영어서 이러한 read/write문제를 해결 할 수 있습니다. 호스트 영역의 서버 클라이언트 간에 전이중 통신을 위해서는 결국 PIPE와 같이 두개의 FIFO파일이 필요하게 됩니다.

3)Message Queue

- Queue(큐)는 선입선출의 자료구조를 가지는 통신설비로 커널에서 관리합니다. 입출력 방식으로 보자면 위의 Named PIPE와 동일하다고 볼 수 있을 것입니다. Named PIPE와 다른 점이라면 Name PIPE가 데이터의 흐름이라면 메시지 큐는 메모리 공간이라는 점입니다. 파이프가 아닌, 어디에서나 물건을 꺼낼 수 있는 컨테이너 벨트라고 보면 될 것입니다.

메시지 큐의 장점은 컨테이너 벨트가 가지는 장점을 그대로 가지게 됩니다. 컨테이너 벨트에 올라올 물건에 라벨을 붙이면 동시에 다양한 물건을 다룰 수 있는 것과 같이, 메시지 큐에 쓸 데이터에 번호를 붙임으로써 여러 개의 프로세스가 동시에 데이터를 쉽게 다룰 수 있습니다.

4)Shared Memory(공유 메모리)

- 데이터를 공유하는 방법에는 크게 두 가지가 있습니다. 하나는 통신을 이용해서 데이터를 주고 받는 것이고 다른 하나는 데이터를 아예 공유, 즉 함께 사용하는 것입니다. PIPE, Named PIPE, Message Queue가 통신을 이용한 설비라면, Shared Memory는 공유메모리가 데이터 자체를 공유하도록 지원하는 설비입니다.

프로세스는 자신만의 메모리 영역을 가지고 있습니다. 이 메모리 영역은 다른 프로세스가 접근해서 함부로 데이터를 읽거나 쓰지 못하도록 커널에 의해서 보호가 되는데, 만약 다른 다른 프로세스의 메모리 영역을 침범하려고 하면 커널은 침범 프로세스에 SIGSEGV(경고 시그널 - 할당된 메모리의 범위를 벗어나는곳에서 읽거나, 쓰기를 시도할 때 발생) 을 보내게 됩니다.

다수의 프로세스가 동시에 작동하는 Linux 운영체제의 특성상 프로세스의 메모리 영역은 반드시 보호되어져야 합니다. 그렇지만 메모리 영역에 있는 데이터를 다른 프로세스도 사용할 수 있도록 해야할 경우도 필요할 것입니다. PIPE 등을 이용해서 데이터 통신을 이용하여 데이터를 전달하는 방법도 있겠지만, Thread에서 처럼 메모리 영역을 공유한다면 더 편하게 데이터를 함께 사용할 수 있을 것입니다. 

Shared Memory(공유 메모리)는 프로세스간 메모리 영역을 공유해서 사용할 수 있도록 허용합니다. 프로세스가 공유 메모리 할당을 커널에 요청하면 커널은 해당 프로세스에 메모리 공간을 할당해줍니다. 이후 어떤 프로세스건 해당 메모리영역에 접근할 수 있습니다.

공유메모리는 중개자가 없이 곧바로 메모리에 접근할 수 있기 때문에 다른 모든 IPC들 중에서 가장 빠르게 작동할 수 있습니다.

5) Memory Map

- Memory Map도 Shared Memory(공유메모리)공간과 마찬가지로 메모리를 공유한다는 측면에 있어서는 서로 비슷한 측면이 있습니다. 차이점은 Memory Map의 경우 열린파일을 메모리에 맵핑시켜서, 공유한다는 점일 것입니다. 파일은 시스템의 전역적인(모두 공유할 수 있는) 자원이므로 서로 다른 프로세스들끼리 데이터를 공유하는데 문제가 없을 것임을 예상할 수 있습니다.

6) Socket

- Socket은 프로세스와 시스템의 기초적인 부분이며, 프로세스 들 사이의 통신을 가능하게 합니다. sys/socket.h>라는 헤더를 이용하여 사용할 수 있으며, 같은 도메인에서의 경우에서 연결 될 수 있습니다. 소켓을 사용하기 위해서는 생성해주고, 이름을 지정해주어야 합니다. 또한 domain과 type, Protocol을 지정해 주어야 합니다. 서버 단에서는 bind, listen, accept를 해주어 소켓 연결을 위한 준비를 해주어야 하고 , 클라이언트 단에서는 connect를 통해 서버에 요청하며, 연결이 수립 된 이후에는 Socket을 send함으로써 데이터를 주고 받게 됩니다. 연결이 끝난 후에는 반드시 Socket 을 close()해주어야 하며, Socket과 관련해서는 이후 네트워크 부분에서 자세히 다루도록 하겠습니다.

7) Semaphore

- Semaphore는 Named PIPE, PIPE, Message Queue와 같은 다른 IPC설비들이 대부분 프로세스간 메시지 전송을 목적으로 하는데 반해, Semaphore는 프로세스 간 데이터를 동기화 하고 보호하는데 그 목적을 두게 됩니다. 프로세스간 메시지 전송을 하거나, 혹은 Shared Memory를 통해서 특정 데이타를 공유하게 될 경우 발생하는 문제가 공유된 자원에 여러개의 프로세스가 동시에 접근하면 안되며, 단지 한번에 하나의 프로세스만 접근 가능하도록 만들어줘야 할 것이며, 이 때 사용되는 것이 Semaphore입니다. 자세한 부분은 이전에 포스팅했던 Semaphore와 Mutex 부분에서 다루고 있으므로 생략하도록 하겠습니다.

RAID에 대한 소개부터 시작하여 아래에서 RAID의 종류와 특징, 구성방식에 대하여 포스팅하겠습니다.

-       RAID는 왜? 사용되나

: 서버의 사용자가 서버 운영에 있어 가장 당혹스러울 때는 하드디스크의 장애로 인한 data 손실일 것입니다. 하드디스크는 사실 상 소모품으로 분류되며 I/O 가 많은 서버에는 고장이 잦은 것이 당연하다고 볼 수 있습니다. 하지만 서버에 저장되는 데이터의 경우 손실 또는 유출 되었을 때 치명적인 것이 대부분일 것으로 대표적으로 은행과 같은 금융, 군사적 목적의 데이터가 있을 것입니다. 이로 인해 백업이 절대적으로 필요한 경우가 있고 또한, 여분의 디스크가 있어 용량을 증설하려고 할 때 데이터 손실 없이 증설이 필요한 경우가 있습니다. 그래서 많은 서버 관리자는 RAID 구성을 통해 하드디스크의 가용성을 높이거나 서버 데이터의 안정성을 확보해야 합니다.

-       RAID란?

: RAID는 Redundant Array of Inexpensive Disks의 약자입니다. 여러 개의 디스크를 배열하여 속도의 증대, 안정성의 증대, 효율성, 가용성의 증대를 하는데 쓰이는 기술입니다.

-       RAID의 장점

1) 운용 가용성, 데이터 안정성 증대

2) 디스크 용량 증설의 용이성

3) 디스크 I/O 성능 향상

-       그 전에 패리티(Parity)란 무엇인가?

1) 정수의 홀수 또는 짝수 특성

2) 정보 블록과 연결된 중복 정보, 패리티는 오류 후 데이터를 재구축하는데 사용되는 계산된 값입니다.

-       RAID의 종류와 구성 방식

RAID 0

: RAID 0에는 Concatenate 방식과 Stripe 방식 두 가지 방식이 있습니다.

1) Concatenate방식 

[concat 방식]

-> 두개 이상의 디스크에 데이터를 순차적으로 쓰는 방법

장점 : 디스크 기본 공간이 부족할 때 데이터는 보존하며 여분의 디스크를 볼륨에 포함하여 용량 증설이 가능하게 됩니다.

단점 : RAID 0의 특성상 디스크 중 하나의 디스크라도 장애가 발생하면 복구가 어렵고, 패리티(오류검출기능)를 지원하지 않습니다.

용량 : 모든 디스크의 용량을 합친 용량 ex) 300GB disk * 2ea = 600GB

2) Stripe 방식 

 흔히 RAID 0라고 하면 Stripe 방식을 말하는 것을 생각하면 됩니다.

-> 두개 이상의 디스크에 데이터를 랜덤하게 쓰는 방법

장점 : 데이터를 사용할 때 I/O를 디스크 수 만큼 분할하여 쓰기 때문에 I/O 속도가 향상 되고I/OController나 I/O board 등 I/O를 담당하는 장치가 별도로 장착된 경우 더 큰 I/O 속도 향상 효과를 볼 수 있습니다.

단점 : Stripe를 구성할 시 기존 데이터는 모두 삭제 되어야 합니다. 

그 외의 단점은 위의 Concat 방식과 같습니다.

용량 : 위의 Concat 방식과 같습니다.

RAID 1(Mirror)

: Mirror 볼륨 내의 패리티를 사용하지 않고 디스크에 같은 데이터를 중복 기록하여 데이터를 보존하게 

되며, 적어도 동일한 용량의 디스크 두 개가 필요합니다.

장점 : 볼륨 내 디스크 중 하나의 디스크만 정상이어도 데이터는 보존되어 운영이 가능하기 때문에 가용성이 높고, 복원이 비교적 매우 간단합니다.

단점 :  용량이 절반으로 줄고, 쓰기 속도가 조금 느려집니다. 

용량 : 모든 디스크의 절반의 용량 ex) 300GB *2ea = 300GB

RAID 2

: RAID2는 RAID 0처럼 striping 방식이지만 에러 체크와 수정을 할 수 있도록 Hamming code를 

사용하고 있는 것이 특징입니다. 하드 디스크에서 ECC(Error Correction Code)를 지원하지 않기 때문에 

ECC를 별도의 드라이브에 저장하는 방식으로 처리됩니다.

하지만 ECC를 위한 드라이브가 손상될 경우는 문제가 발생할 수 있으며 패리티 정보를 하나의 

하드 드라이브에 저장하는 RAID 4가 나오면서 거의 사용되지 않는 방식입니다.

RAID 3, RAID 4

: RAID 3, RAID 4는 RAID 0, RAID 1의 문제점을 보완하기 위한 방식으로 3, 4로 나뉘긴 하지만 

RAID 구성 방식은 거의 같습니다. RAID 3, 4는 기본적으로 RAID 0과 같은 striping 구성을 하고 있어 

성능을 보안하고 디스크 용량을 온전히 사용할 수 있게 해주는데 여기에 추가로 에러 체크 및 수정을 

위해서 패리티 정보를 별도의 디스크에 따로 저장하게 됩니다.

RAID 3은 데이터를 바이트 단위로 나누어 디스크에 동등하게 분산 기록하며 RAID 4는 데이터를 

블록 단위로 나눠 기록하므로 완벽하게 동일하진 않다는 차이가 있습니다. 

RAID 3은 드라이브 동기화가 필수적이라 많이 사용되지 않고 RAID 4를 더 많이 쓴다고 보시면 됩니다.

RAID 5

: RAID 5는 RAID 3,4 에서 별도의 패리티 정보 디스크를 사용함으로써 발생하는 문제점을 보완하는 

방식으로 패리티 정보를 stripe로 구성된 디스크 내에서 처리하게 만들었습니다.

만약 1개의 하드가 고장 나더라도 남은 하드들을 통해 데이터를 복구할 수 있다는 장점이 있습니다.

RAID 6

: RAID 6은 RAID 5와 같은 개념이지만 다른 드라이브들 간에 분포되어 있는 2차 패리티 정보를 넣어 

2개의 하드에 문제가 생겨도 복구할 수 있게 설계되었으므로 RAID 5보다 더욱 데이터의 안전성을 

고려하는 시스템에서 사용됩니다.

앞에서 살펴 본 운영체제의 운용기법에서 다루었던 분산 처리 시스템과 관련하여 Topology에 따른 분류에 대한 부분입니다.

-       1) 망형: 완전 연결(Fully Connection)형

: 각 사이트들이 시스템 내의 다른 모든 사이트들과 직접 연결된 구조입니다.

사이트의 수가 n개이면 링크(연결) 수는 n(n-1)/2개가 됩니다.

모든 사이트를 연결해야 하므로 기본 비용은 많이 들지만 각 사이트가 직접 연결되므로 통신 비용은 적게 들게 되고,하나의 링크가 고장나더라도 다른 링크를 이용할 수 있으므로 신뢰성이 높습니다.

-     2) 망형: 부분 연결(Partially Connection)형

: 시스템 내의 일부 사이트들 간에만 직접 연결하는 것으로 직접 연결되지 않은 사이트는 연결된 다른 사이트를 통해 통신하는 구조입니다.

기본 비용은 완전 연결형보다 적게 들고 통신 비용은 완전 연결형보다 많이 들게 되며, 상대적으로 완전 연결형보다 신뢰성이 낮습니다.

-       3) 트리형 또는 계층형 

: 분산 처리 시스템의 가장 대표적인 형태로 각 사이트들이 트리 형태로 연결된 구조입니다.

기본 비용은 부분 연결형보다 적게 들고 통신 비용은 트리의 깊이에 비례하고, 부모(상위) 사이트의 자식(하위) 사이트들은 그 부모 사이트를 통해 통신이 이루어지게 됩니다.

부모 사이트가 고장나면 그 자식 사이트들은 통신이 불가능하다는 단점이 있습니다.

-       4) 스타(Star)형 또는 성형 

: 모든 사이트가 하나의 중앙 사이트에 직접 연결되어 있고 그 외 다른 사이트와는 연결되어 있지 않은 구조입니다.

기본 비용은 사이트의 수에 비례하고 통신 비용은 적게들며, 구조가 간단한고 보수 및 관리가 용이합니다.

중앙 사이트를 제외한 사이트의 고장이 다른 사이트에 영향을 미치지 않지만, 중앙 사이트가 고장날 시 모든 통신이 단절된다는 단점이 있습니다.

데이터 전송이 없는 사이트가 접속된 통신회선은 휴지상태(쉬는) 가 됩니다.

-       5) 링(Ring)형 또는 환형

: 시스템 내의 각 사이트가 인접하는 다른 두 사이트와만 직접 연결된 구조입니다.

정보는 단방향 또는 양방향으로 전달될 수 있으며, 기본 비용은 사이트 수에 비례하고 목적 사이트에 데이터를 전달하기 위해 링을 순환할 경우 통신 비용이 증가하게 됩니다.

특정 사이트가 고장나면 통신이 불가능해지는 사이트가 발생될 수 있습니다.

-       6) 다중 접근 버스 연결(Multi Access Bus Connectio) 형

: 시스템 내의 모든 사이트들이 공유 버스에 연결된 구조입니다.

기본 비용은 사이트 수에 비례하고 통신 비용은 일반적으로 저렴하며, 물리적 구조가 단순하고 사이트의 추가와 삭제가 용이합니다. 

사이트의 고장은 다른 사이트의 통신에 영향을 주지 않지만, 버스의 고장은 전체 시스템에 영향을 주게 됩니다.

예전에 개인적으로 정리했던 자료들을 포스팅하다 보니, 아무래도 조금은 두서없이 작성되는 것 같습니다..^^

운영체제의 운용기법에 대한 부분 입니다.

운영체제는 작업을 수행하는 방식에 따라 일괄처리 시스템, 다중 프로그래밍 시스템, 다중 처리 시스템, 시분할 시스템, 실시간 처리 시스템, 분산 처리 시스템 등으로 나뉘게 됩니다.

-       1) 일괄처리 시스템(Batch Processing System)

: 일괄처리 시스템은 초기의 컴퓨터에서 사용된 형태로 일정량 또는 일정 기간 동안 데이터를 모아서 한꺼번에 처리하는 방식입니다.

일괄 처리를 위해 적절한 작업 제어언어(JCL; Job Control Language)를 제공해야 합니다. JCL이란 작업의 처리 순서를 운영체제에게 알려주는 특별한 명령입니다.

(특징)

1) 컴퓨터 시스템을 효율적으로 사용할 수 있습니다.

2) 반환 시간이 늦지만 하나의 작업이 모든 자원을 독점하므로  CPU 유휴 시간이 줄어들게 됩니다. 

* CPU 유휴시간(idle time)이란 CPU의 처리 시간과 입/출력 장치에서의 처리 시간 차이로 CPU를 사용할 수 있는 상태임에도 CPU가 작업을 하지 않고 쉬고 있는 시간을 말합니다.

급여 계산, 지불 계산, 연말 결산 등에 사용됩니다.

-       2) 다중 프로그래밍 시스템

: 하나의 CPU와 주기억장치를 이용하여 여러 개의 프로그램을 동시에 처리하는 방식으로, CPU의 사용률과 처리량이 증가합니다.

-       시분할 시스템 또는 라운드 로빈 방식

: 여러 명의 사용자가 사용하는 시스템에서 컴퓨터가 사용자들의 프로그램을 번갈아가며 처리해 줌으로써 각 사용자에게 독립된 컴퓨터를 사용하는 느낌을 주는 것으로 라운드 로빈 방식이라고도 합니다.

(라운드 로빈방식-RR과 관련하여 앞선 스케줄링에 대한 포스팅을 참고하시면 됩니다.)

(특징) 

1. 하나의 CPU는 같은 시점에서 여러 개의 작업을 동시에 수행할 수 없기 때문에 CPU의 전체 사용시간을 작은 작업 시간량(Time Slice)로 나누어서 그 시간량 동안 번갈아가면서 CPU를 할당하여 그 작업을 처리하게 됩니다.

2. 시스템 전체 효율은 좋아지나 개인별 사용자 입장에서는 반응 속도가 느려질 수 있습니다.

-       3) 다중 처리 시스템 

: 여러 개의 CPU와 하나의 주기억장치를 이용하여 여러 개의 프로그램을 동시에 처리하는 방식입니다.

(특징)

1. 하나의 CPU가 고장나더라도 다른 CPU를 이용하여 업무를 처리할 수 있으므로 시스템의 안전성은 높습니다.

2. 여러 CPU는 하나의 메모리를 공유하며 단일 운영체제에 의해 관리됩니다.

3. 프로그램의 처리 속도는 빠르지만 기억장치, 입,출력장치 등의 자원 공유에 대한 문제점을 해결해야 합니다.

-       4) 실시간 처리 시스템

: 데이터 발생 즉시, 또는 데이터 처리 요구가 있는 즉시 처리하여 결과를 산출하는 방식입니다.

(특징)

1. 처리 시간이 단축되고 처리비용이 절감됩니다.

2. 우주선 운행, 교통 제어, 레이더 추적기, 핵물리학 실험 및 데이터 수집 등에 사용됩니다.

-       5) 다중 모드 처리

: 일괄 처리 시스템, 시분할 시스템, 다중 처리 시스템, 실시간 처리 시스템을 한 시스템에서 모두 제공하는 방식입니다.

-       6) 분산 처리 시스템

: 여러 개의 컴퓨터(프로세서)를 통신 회선으로 연결하여 하나의 작업을 처리하는 방식입니다.

이번에는 Little-endian과 Big-endian에 대한 설명과 차이점을 공부해보도록 하겠습니다.

먼저 Little endian은 메모리 시작 주소가 하위 바이트부터 기록된다는 것입니다. 

반대로 Big endian은 메모리 시작 주소가 상위 바이트부터 기록됩니다.

이게 무슨 말인지..? 아래 그림으로 참고해보도록 하겠습니다.

"메모리 시작 주소가     little(하위), Big(상위)  바이트부터 기록된다"

Little endian – 인텔 계열 프로세스에서 주로 사용되는 바이트 오더입니다.

Big endian – Unix 시스템인 RISC 프로세서 계열에서 사용되는 바이트 오더입니다.

[Big endian 과 Little endian, 메모리에 담기는 모습]

- Big endian은 그림을 참고하면 0x0A는 메모리 하위 주소에 위치하게 되고 차례로 0x0B, 0x0C, 0x0D가 오게 됩니다. 읽는 순서는 왼쪽 -> 오른쪽 순서로 읽으면 되기 때문에 사람이 보기에 가장 편한 방식이라고 할 수 있습니다.

-Little endian 은 Big endian과 반대로 0x0D가 메모리 하위 주소에 위치하게 되고, 상위 바이트로 올라가며 차례로 나머지 값들이 들어가게 됩니다. Little endian 또는 Big endian에 따라 받아들이는 쪽에서 처리를 잘못하면 엉뚱한 형태가 되므로, 항상 주의가 필요합니다.

위 그림으로 보면 

Big endian은 메모리 a번지부터 ABCD로, Little endian은 메모리 a번지부터 DCBA로 위치된다고 보시면 됩니다. 

(32bit 기준)

운영체제에서 CISC(Complex Instruction Set Computer), RISC(Reduced Instruction Set Computer)에 대한 설명입니다. 

Ex) X=(A+B)*(C+D) 을 각 머신(CISC, RISC)에 실행한다고 한다면

CISC(Complex Instruction Set Computer)

모든 고급언어 문장들에 대해 각각 기계 명령어가 대응되도록 하는 것

-       복잡하고 기능이 많은 명령어로 구성된 프로세서

-       복합 명령을 가짐으로써 하위 호환성을 충분히 확보

-       트랜지스터 집적에 있어서 효율성이 떨어짐(성능 향상에 난점)

-       전력소모가 큼. 속도가 느리고 가격이 비쌈

-       호환성이 절대적으로 필요한 PC 환경에 사용

-       386, 486, Pentium 등 PC용 CPU(인텔계열)

RISC(Reduced Instruction Set Computer)

CISC의 많은 명령어 중 주로 쓰이는 것만을 추려서 하드웨어로 구현하는 것

-       CPU의 명령어를 최소화하여 단순하게 제작된 프로세서

-       대단히 효율적이고 특화된 CPU 구조. 다양한 기술 이용 가능

-       하드웨어가 간단한 대신 소프트웨어는 복잡하고 크기가 커짐(컴파일러의 최적화가 요구됨)

-       하위 호환을 위해 에뮬레이션 방식을 채택. 호환성 부족

-       전력 소모가 적음. 속도가 빠르고 가격이 저렴

-       용도에 최적화가 요구되는 환경에 사용

-       IBM System/6000, 임베디드(MIPS, ARM계열 등), 매킨토시 등 특수목적 CPU

즉 이해하기 편하게 설명하면 CISC는 Complex, 즉 명령어가 복잡하므로 기능이 많다 라고 연상시킬 수 있고,

RISC는 Reduced, 즉 명령어가 줄은, 감소한의 뜻이므로 명령어가 최소화되었구나. 단순하게 구성된 명령어들이구나 라고 쉽게 연상시킬 수 있습니다.. 라고 생각합니다.

저는 초기에 이런 식으로 CISC와 RISC가 무엇인지, 어떤 차이인지부터 연상을 하려 했던것같습니다

이해하거나 암기하는 방식은 사람마다 다르니, 편하신대로 이해하시면 될 것 같습니다.

CISC와 RISC가 대표적이나, 최근에는 EPIC(Explicitly Parallel Instruction Computing)이 경쟁자로 떠오르고 있습니다.

CISC와 RISC의 가장 큰 위협적인 상대는 서로가 아니라 EPIC이라 일컬어지는 새로운 기술일 것이라고 감히 생각해봅니다. EPIC은 Explicitly Parallel Instruction Computing을 나타냅니다. Parallel 단어가 상징하는 것처럼 EPIC은 여러 명령어를 병렬로 실행할 수 있습니다. EPIC은 인텔에 의해 개발되었고, CISC와 RISC가 조합된 방법으로 제작되었습니다. 이론적으로 하나의 CPU가 유닉스 기반 뿐 아니라 윈도 기반의 프로세싱을 제공합니다.