Apache MPM(Multi-Processing Modules) - Prefork & Worker

Apache MPM: 아파치 서버가 클라이언트의 요청을 자식 프로세스들에게 분배하는 모듈이다.
동접자수가 많거나 확장성이 필요한 사이트는 worker 방식을 택하고, 안정성과 오래된 소프트웨어와 호환성이 필요한 사이트는 prefork 방식을 사용한다.
/docs/conf/extra/httpd-mpm.conf파일에서 각 모듈에 대한 설정을 바꿀 수 있다.


Prefork
실행 중인 프로세스를 메모리 영역까지 미리 복제해서 준비한다.
자식 프로세스가 각각 하나의 스레드를 가지며 자식 프로세스는 총 1024개를 가질 수 있다.
스레드 간 메모리 공유가 없어서 안정적이지만 메모리가 많이 필요하다.
응답 프로세스를 미리 띄워놓고 클라이언트 요청 시 자식 프로세스가 반응한다.
몇몇 idle process가 유지돼있으므로 요청이 들어오면 바로 처리하여 빠르지만 동시에 많은 접속이 들어오면 많은 자원을 쓰게 된다.
싱글 CPU 혹은 듀얼 CPU에서 성능이 좋다.
안전하지 않은 제 3자가 만든 모듈을 사용할 수 있고, 디버깅이 빈약한 플랫폼에서 쉽게 디버깅 할 수 있다.

StartServers : 아파치 시작시 생성되는 기본 프로세스 개수
MinSpareServers : 최소 프로세스의 개수
MaxSpareServers : 최대 프로세스의 개수
MaxClients : 아파치 시작시 최대로 실행할 자식프로세스의 개수
MaxRequestWorkers : 동시에 처리할 수 있는 최대 연결 수(기본적으로는 256까지 사용가능하며, 컴파일 전에 파일을 수정(./server/mpm/prefork/prefork.c)하면 1024까지 올릴 수 있다.)
MaxConnectionsPerChild : 서버 프로세스가 종료되기 전에 제공되는 최대 연결 수입니다. 0의 경우 제한이 없다라는 의미다.



Worker
Prefork보다 메모리 사용량이 적기 때문에 동시 접속자가 많고 통신량이 많은 서버에 적절하다.
프로세스당 최대 64개의 스레드 처리가 가능하고 각 요청당 하나의 쓰레드가 처리한다.
각 스레드는 하나의 연결을 담당한다.
스레드 간 메모리를 공유한다.
prefork와 비슷하게 idle thread가 존재하여 들어오는 요청을 빠르게 처리한다.
멀티 CPU 시스템에서 성능이 좋다.

StartServers : 아파치 시작시 생성되는 기본 프로세스 개수
ServerLimit : 최대 실행가능한 프로세스 개수
MaxClients : 최대동시접속자수
MinSpareThreads : 최소로 유지할 쓰레드 개수
MaxSpareThreads : 최대로 유지할 쓰레드 개수
ThreadsPerChild : 하나의 자식프로세스가 가질 수 있는 쓰레드 개수
MaxRequestsPerChild : 자식프로세스가 살아있는동안 요청을 받을 개수
MaxRequestWorkers : 동시에 처리할 수 있는 최대 연결 수(기본적으로는 256까지 사용가능하며, 컴파일 전에 파일을 수정(./server/mpm/prefork/prefork.c)하면 1024까지 올릴 수 있다.)
MaxConnectionsPerChild : 서버 프로세스가 종료되기 전에 제공되는 최대 연결 수입니다. 0의 경우 제한이 없다라는 의미이다.




Event MPM
기존의 아파치는 event driven 방식을 지원하지 않아서 한 개의 동접 클라이언트 당 한개의 프로세스 혹은 스레드가 맡는 구조였고 이 때문에 접속이 완전히 끝나지 않는 한 스레드 혹은 프로세스가 죽지 않았다.(keep alive)
이는 대량 접속에서 효율이 급격하게 떨어지기 때문에 아파치2.4부터는 event MPM을 사용할 수 있게 되었다.
event 방식은 요청을 처리하는 스레드를 따로 둬서 분산 처리하는 방식이다.



명령어
apachectl -V : 현재 아파치 정보 확인(현재 설정돼있는 mpm 모듈 포함)
ls -l /etc/apche2/mods-available/mpm* : 현재 사용 가능한 MPM 모듈 확인
ls -l /etc/apche2/mods-enabled/mpm* : 현재 사용중으로 설정된 모듈 확인
a2dismod mpm_prefork : prefork 모듈을 사용 안 함으로 설정
a2enmod mpm_worker: worker 모듈을 사용함으로 설정


------------------------------------------
https://chobokkiri.tistory.com/65



댓글

댓글 쓰기

이 블로그의 인기 게시물

논문 정리 - MapReduce: Simplified Data Processing on Large Clusters

Abstract 맵리듀스는 큰 데이터 셋을 다루는 프로그래밍 모델이다 . 사용자는 map 함수를 통해서 키 / 밸류 쌍을 이용하여 intermediate key/value pair 를 만들고 reduce 함수를 통해서 그 intermediate pair 들을 같은 key 별로 합쳐준다 . 많은 일들이 이런 모델을 통해 표현될 수 있다 . 이 모델은 분산 시스템이나 병렬 시스템에 대한 경험이 부족하더라도 분산 시스템의 자원을 쉽게 사용할 수 있게 해준다 . 1. introduction 데이터가 많아지면서 reasonable time 안에 작업을 끝내기 위해 수백 혹은 수천대의 기계에 분산되어야 했다 . 이 때 어떻게 연산을 병렬화하고 , 데이터를 분산하고 , 실패 작업을 어떻게 처리할지가 이슈가 되었다 . 이런 복잡한 문제들을 해결하기 위해 병렬화의 세세한 부분들은 숨기고 fault tolerance 하며 데이터를 분산시켜주고 로드 밸런싱을 해주는 라이브러리를 통해서 연산을 맵과 리듀스로 간단히 표현하도록 했다 . 2. Programming Model 사용자가 직접 만드는 맵 함수는 입력으로 key/value pairs 를 받아서 intermediate key/value pairs 를 만든다 . 그러면 intermediate key/value pairs 에 대해서 맵리듀스 라이브러리가 같은 key 별로 value 들을 묶어서 리듀스 함수로 보내준다 . 마찬가지로 사용자가 직접 만드는 리듀스 함수는 이 데이터를 받아서 key 별로 묶인 value 들을 합쳐서 표현한다 . 리듀스 함수에 전달되는 intermediate 데이터는 iterator 의 형태로 전달되기 때문에 메모리에 다 안 들어갈 정도로 큰 데이터도 처리할 수 있다 . 예를 들어서 , 어떤 문서에 있는 각 단어들이 몇 번 나왔는지 세는 프로그램을 생각해보자 . 그렇다면 맵 함수는 입력으로 < 문서 이름 , 문서 내용 > 의...
자세한 내용 보기

논문 정리 - The Google File System

The Google File System 1. Introduction 새로운 관점 component failure 은 예외가 아니라 일반적인 상황이다 . 그래서 constant monitoring, error detection, fault tolerance, automatic recovery 가 필요하다 . 파일의 크기가 커졌다 . I/O 작업이나 block 크기 등이 고려되어야 한다 . 원래 있는 데이터에 덮어쓰는 작업보다는 새로운 데이터를 추가한다 . 따라서 appending 이 성능 최적화에 중요해졌다 . 2. Design Overview 2.1 assumptions 시스템은 잘 고장나는 저렴한 장비들로 구성되어 있다 . 시스템은 큰 파일이 있다 . 작은 파일들도 있지만 optimizing 할 때는 고려하지 않는다 . 로드는 주로 큰 스트리밍 읽기와 작은 랜덤 읽기로 구성되어 있다 . 로드는 또한 파일에 데이터를 추가하는 많은 sequential write 가 있다 . 같은 파일에 여러 사용자가 동시에 데이터를 추가하는 경우도 잘 고려해야 한다 . 빠른 반응 속도 보다는 high sustained bandwidth 가 더 중요하다 . 대부분의 타겟 애플리케이션은 데이터 뭉텅이를 빠른 시간 내에 처리하는 것을 중요하게 여긴다 . 2.2 Interface 파일은 hierarchically , 디렉토리에 정렬돼있고 path name 으로 구분된다 . 또한 GFS 는 snapshot 과 record append 기능이 있다 . snapshot 은 파일이나 디렉토리 트리를 복사한다 . record append 는 다수 클라이언트가 데이터를 하나의 파일에 동시에 추가할 수 있도록 해준다 . 각 append 의 atomicity 를 보장하면서 . 2.3 Architecture 하나의 마스터와 여러개의 chunkserver 로 구성되어 있다 . 그리고 다수의...
자세한 내용 보기

kazoo: Using zookeeper api with python

``` pip3 install kazoo ``` https://kazoo.readthedocs.io/en/latest/basic_usage.html https://kazoo.readthedocs.io/en/latest/api/client.html ### 접속 ``` from kazoo.client import KazooClient zk = KazooClient(hosts='127.0.0.1:2181') zk.start() ``` 호스트에 접속할 때 default port는 2181이다. ### 상태 Listener zookeeper의 상태가 변하는 것을 알 수 있다. ``` from kazoo.client import KazooState def my_listener(state):     if state == KazooState.LOST:         # Register somewhere that the session was lost     elif state == KazooState.SUSPENDED:         # Handle being disconnected from Zookeeper     else:         # Handle being connected/reconnected to Zookeeper zk.add_listener(my_listener) ``` LOST CONNECTED SUSPENDED 의 state를 가질 수 있다. 가능한 상태 변화 - LOST -> CONNECTED - CONNECTED -> SUSPENDED - CONNECTED -> LOST - SUSPENDED -> LOST - SUSPENDED -> CONNECTED ### CRUD - `zk.create("/my/favorite/node", b"a value")` `create(path...
자세한 내용 보기