[CS] 프로세스

최민길(Gale)·2023년 8월 7일
1

CS 탐구

목록 보기
9/13

안녕하세요 오늘은 프로세스에 대해서 알아보는 시간을 갖도록 하겠습니다.

프로세스란 디스크의 프로그램을 메모리에 적재하고 실행한 상태를 의미합니다. 하나의 프로그램은 여러 개의 프로세스로 중복 생성될 수 있기 때문에 프로세스는 프로그램의 인스턴스라고 볼 수 있습니다. 생성, 실행, 대기, 중지, 좀비, 종료 등의 라이프 사이클을 가지며 고유의 아이디(PID)를 가집니다.

PID란 시스템에서 실행 중인 프로세스를 구분하기 위해 시스템에서 유일한 아이디를 부여받는 것을 의미합니다. PPID의 경우 생성된 프로세스의 부모 프로세스 아이디를 의미하며 UID의 경우 생성된 프로세스가 속한 사용자 또는 그룹의 아이디로, 부모 프로세스로부터 상속받는 아이디입니다.

시스템 상의 모든 프로세스의 부모 프로세스를 최상위 프로세스라고 합니다. 부모 프로세스가 존재하지 않기 때문에 PID는 항상 1이며, 부트 로더에 의해 리눅스의 초기화를 위해 가장 먼저 실행되는 프로세스로 커널이 직접 시작합니다. Cent OS 6의 최상위 프로세스는 init 프로세스이며, Cent OS 7의 최상위 프로세스는 systemd입니다.

현재 실행 중인 프로세스가 특정 실행 파일을 실행했을 때 실행한 프로세스는 부모 프로세스, 실행된 프로세스는 자식 프로세스가 됩니다. 여기서 강제 종료 등으로 부모 프로세스를 잃어 버린 자식 프로세스를 고아 프로세스라고 하며, 고아 프로세스의 부모 프로세스는 최상위 프로세스가 되어 PID가 1로 변경됩니다. 자식 프로세스가 종료될 때 부모 프로세스가 wait() 시스템 콜 등으로 자식 프로세서의 종료 코드를 회수하지 못한 경우 좀비 프로세스가 됩니다. 좀비 프로세스는 프로세스가 사용하던 리소스는 모두 반환되었지만 프로세스 테이블 상에서 자식 프로세스가 지워지지 않은 상태로 존재합니다.

프로세스는 크게 exec 방식과 fork 방식으로 나뉩니다.

exec 방식은 시스템 콜로 현재 프로세스의 이미지를 새로운 프로세스의 이미지로 교체하는 작업입니다. fork 방식은 프로세스가 호출되어 새로운 자식 프로세스가 생성되는 방식으로, 호출한 프로세스를 복제하여 자식 프로세스가 생성된 후 exec() 호출을 통해 자식 프로세스의 프로그램으로 교체됩니다. 이 때 부모 프로세스의 메모리 락, 세마포어, 비동기 I/O 등은 상속되지 않습니다.

프로세스틑 크게 포어그라운드 프로세스와 백그라운드 프로세스로 나뉩니다.

포어그라운드 프로세스는 사용자가 명령이나 프로그램을 실행하면 프로세스가 실행되는 사이에 셸이 block되는 프로세스입니다. 즉 프로세스 실행이 완료될 때까지 셸은 다른 작업을 받아들이지 않습니다. 사용자의 입력을 받을 수 있고 그 실행 결과를 터미널이나 GUI를 통해 확인할 수 있습니다.

백그라운드 프로세스는 명령어의 수행 결과를 받을 때까지 오랜 시간이 걸릴 경우 백그라운드에서 실행되는 프로세스를 의미합니다. 이는 명령어 뒤에 &를 붙여 실행시킬 수 있습니다.

프로세스틑 PCB라고 불리는 프로세스를 실행하고 스케줄링하고 상태가 변경될 때마다 그 정보를 저장하기 위해 커널에서 프로세스에 대한 정보를 관리하는 자료구조가 존재합니다. 여기에 프로세스의 스택 포인터, 프로세스 상태, 프로세스 PID 등의 프로세스의 메타데이터를 저장합니다.

프로세스 테이블은 시스템에서 실행하고 있는 모든 프로세스를 관리합니다. 현재 실행 중인 프로세스의 PID와 프로세스의 정보를 담고 있는 PCB를 담고 있으며 프로세스가 종료하면 프로세스 테이블에서도 삭제됩니다. (삭제되지 않으면 좀비 프로세스가 됩니다.)

데몬은 시스템 부팅 시 자동으로 시작되며 백그라운드로 실행되는 프로세스입니다. 사용자가 직접 제어하지 않고 특정 이벤트나 상태와 같은 주기적이고 지속적인 서비스의 요청을 처리하기 위해 데몬의 관련 핸들러가 실행됩니다.

데몬은 크게 standalone 방식과 xinetd 방식으로 실행됩니다.

standalone 방식은 사용자의 요청 없이 시스템 시작 시 자동으로 시작하여 백그라운드에서 대기하는 방식입니다. 클라이언트에서 요청 발생 시 즉각적으로 서비스를 제공하며 데몬이 항상 실행되고 있기 때문에 사용자의 서비스 요청에 즉각적으로 응답합니다. 이로 인해 사용하지 않을 때도 시스템의 메모리를 점유하여 비효율적입니다. 따라서 standalone 방식은 서비스의 요청이 빈번하게 있는 경우 적합합니다.

xinetd 방식은 시스템 시작 시 xinetd를 standalone 방식으로 실행하고 사용자의 서비스 요청이 있을 때만 관련 데몬을 시작하여 서비스를 제공하는 방식입니다. 사용자의 접속이 종료되면 해당 데몬도 자동으로 종료되며, 데몬이 필요할 때 로드되기 때문에 리소스 효율이 좋다는 장점이 있습니다. 하지만 사용자의 서비스 요청에 대하여 xinetd가 중간 과정에 존재하기 때문에 standalone 방식 대비 상대적으로 느리다는 단점이 있습니다. 따라서 xinetd 방식은 서비스의 요청이 빈번하지 않을 때 유리합니다. systemd의 경우 on-demand 방식으로 xinetd 방식 데몬을 제공합니다.

profile
저는 상황에 맞는 최적의 솔루션을 깊고 정확한 개념의 이해를 통한 다양한 방식으로 해결해오면서 지난 3년 동안 신규 서비스를 20만 회원 서비스로 성장시킨 Software Developer 최민길입니다.

0개의 댓글