|
| |
| Sun Java System Messaging Server 6 2005Q1 관리 설명서 | |
8장
MTA 개념이 장에서는 MTA의 개념에 대해 설명합니다. 이 장은 다음 내용으로 구성되어 있습니다.
MTA 기능Message Transfer Agent 또는 MTA는 Messaging Server의 구성 요소입니다(그림 8-1). 가장 기본적인 수준에서 MTA는 메일 라우터입니다. MTA는 다른 서버에서 메일을 수락하여 주소를 읽은 다음 최종 대상(일반적으로 사용자의 메일함)으로 가는 도중에 있는 다음 서버로 라우팅합니다.
수년 동안 많은 기능이 MTA에 추가되었으며 이에 따라서 MTA의 크기, 기능 및 복잡도가 증가했습니다. 이러한 MTA 기능은 중복되기는 하지만 일반적으로 다음과 같이 분류할 수 있습니다.
- 라우팅. 메일을 수락하여 필요에 따라(예: 별칭인 경우) 확장 또는 변환한 후에 다음 서버, 채널, 프로그램, 파일 등에 라우팅합니다. 라우팅 기능은 관리자가 메시지가 라우팅되는 방법에 대한 내부 및 외부 기법을 지정하는 수준까지 확장되었습니다. 예를 들어, SMTP 인증 사용, 다양한 SMTP 명령 및 프로토콜 사용, TCP/IP 또는 DNS 조회 지원, 작업 제출, 프로세스 제어 및 메시지 대기열 등을 지정할 수 있게 된 것입니다.
- 주소 다시 쓰기. 봉투 주소는 흔히 라우팅 프로세스의 일부로 다시 쓰여지지만 봉투 또는 헤더 주소를 더 적절하거나 원하는 형태로 다시 쓸 수 있습니다.
- 필터링. MTA는 주소, 도메인, 가능한 바이러스 및 스팸 내용, 크기, IP 주소, 헤더 내용 등에 기초하여 메일을 필터링할 수 있습니다. 필터링된 메일은 삭제, 거부 또는 수정되거나, 파일 또는 프로그램으로 보내지거나, 사용자 메일함으로 가는 도중의 다음 서버로 보내질 수 있습니다.
- 내용 수정. 메일 헤더와 내용을 수정할 수 있습니다. 예를 들어 메일을 특정 클라이언트나 특수한 문자 세트에서 읽을 수 있게 만들거나 스팸 또는 바이러스를 검사합니다.
- 감사. 누가 언제, 어디서, 무엇을 제출했는지 추적합니다.
그림 8-2에 나온 여러 하위 구성 요소와 프로세스가 이러한 기능을 지원합니다. 이 장에서는 이러한 하위 구성 요소와 프로세스에 대해 설명합니다. 또한 시스템 관리자는 여러 도구를 사용하여 이러한 기능을 활성화하고 구성할 수 있습니다. 이러한 도구에는 MTA 옵션, configutil 매개 변수, 매핑 테이블, 키워드, 채널, 다시 쓰기 규칙 등이 포함됩니다. 이러한 도구에 대해서는 MTA 다음 장에서 설명합니다.
그림 8-2 MTA 구조
MTA 구조 및 메일 흐름 개요이 절에서는 MTA 구조 및 메일 흐름(그림 8-2)의 개요를 설명합니다. MTA는 상당히 복잡한 구성 요소이며 그림 8-2는 시스템을 통과하는 메일 흐름을 단순하게 표현한 것임을 유의하십시오. 실제로 이 그림은 시스템을 통과하는 모든 메일 흐름을 정확하게 나타내지 않습니다. 그러나 개념적 논의를 위해서는 이 그림으로 충분할 것입니다.
디스패처 및 SMTP 서버(슬레이브 프로그램)
메일은 SMTP 세션을 통해 인터넷 또는 인트라넷에서 MTA로 들어옵니다. MTA가 SMTP 연결에 대한 요청을 받으면 MTA 디스패처(다중 스레드 연결 디스패칭 에이전트)는 SMTP 세션을 처리하기 위해 슬레이브 프로그램(tcp_smtp_server)을 실행합니다. 디스패처는 각 서비스에 대한 다중 스레드 프로세스 풀을 유지 관리합니다. 추가 세션이 요청되면 디스패처는 각 세션을 처리하기 위해 SMTP 서버 프로그램을 활성화합니다. 디스패처 프로세스 풀의 프로세스는 동시에 여러 연결을 처리할 수 있습니다. 디스패처와 슬레이브 프로그램은 서로 협력하여 각각의 받는 메일에 대한 여러 다른 기능을 수행합니다. 세 가지 기본 기능은 다음과 같습니다.
- 메일 차단 - 지정된 IP 주소, 메일 주소, 포트, 채널, 헤더 문자열 등에 기초하여 메일을 차단할 수 있습니다(17장, "메일 필터링 및 액세스 제어").
- 주소 변경 - 받는 From:또는 To: 주소를 다른 형식으로 다시 쓸 수 있습니다.
- 채널 대기열에 포함 - 메일을 보내야 하는 채널을 결정하기 위해 다시 쓰기 규칙을 통해 주소가 실행됩니다.
자세한 내용은 디스패처를 참조하십시오.
라우팅 및 주소 다시 쓰기
SMTP 서버가 메일을 대기열에 포함시키지만 변환 채널 및 재처리 채널을 비롯한 여러 다른 채널도 이를 수행할 수 있습니다. 이 전달 단계가 진행하는 동안에 여러 작업이 수행되지만 기본 작업은 다음과 같습니다.
채널
채널은 메일 처리에 사용되는 기본 MTA 구성 요소입니다. 채널은 다른 시스템(예: 다른 MTA, 다른 채널 또는 로컬 메시지 저장소)과의 메일 연결을 나타냅니다. 메일이 들어오면 메일의 소스 및 대상에 따라 각기 다른 메일에 다른 라우팅 및 처리가 필요합니다. 예를 들어, 로컬 메시지 저장소로 전달할 메일, 인터넷에 전달할 메일, 메일 시스템 내의 다른 MTA로 전달할 메일 등은 서로 다른 방식으로 처리됩니다. 채널은 각 연결에 필요한 처리 및 라우팅을 사용자 정의하기 위한 기법을 제공합니다. 기본 설치에서 대부분의 메일은 인터넷, 인트라넷 및 로컬 메일을 처리하는 채널로 이동합니다.
특정 상황을 위한 특수한 채널을 만들 수도 있습니다. 예를 들어, 특정 인터넷 도메인이 메일을 매우 느린 속도로 처리하기 때문에 이 도메인으로 주소 지정된 메일이 MTA의 성능을 저하시킨다고 가정해 봅니다. 이 경우 느린 도메인으로 주소 지정된 메일을 위한 특수한 처리를 제공하는 특정 채널을 만들어 이 도메인 병목 현상을 줄일 수 있습니다.
주소의 도메인 부분은 메일을 대기열에 포함시킬 채널을 결정합니다. 도메인을 읽고 적절한 채널을 결정하는 기법을 다시 쓰기 규칙이라고 부릅니다(다시 쓰기 규칙 참조).
채널은 일반적으로 채널 대기열과 마스터 프로그램이라고 부르는 채널 처리 프로그램으로 구성됩니다. 슬레이브 프로그램이 메일을 적절한 채널 대기열로 전달한 후 마스터 프로그램은 원하는 처리 및 라우팅을 수행합니다. 다시 쓰기 규칙과 마찬가지로 채널은 imta.cnf 파일에서 지정 및 구성합니다. 채널 항목의 예는 다음과 같습니다.
tcp_intranet smtp mx single_sys subdirs 20 noreverse maxjobs 7 SMTP_POOL maytlsserver allowswitchchannel saslswitchchannel tcp_auth
tcp_intranet-daemon이 경우에 첫 번째 단어 tcp_intranet은 채널 이름입니다. 마지막 단어는 채널 태그라고 부릅니다. 그 사이에 있는 단어는 채널 키워드라고 부르며 메일이 처리되는 방법을 지정합니다. 수백 개의 다른 키워드를 사용하여 메일을 다양한 방법으로 처리할 수 있습니다. 채널 키워드에 대한 자세한 내용은 Sun Java System Messaging Server Administration Reference 및 12장, "채널 정의 구성"에 설명되어 있습니다.
메일 전달
메일이 처리된 후 마스터 프로그램은 메일의 전달 경로를 따라 다음 정지 위치로 메일을 보냅니다. 이 위치는 의도한 수신자의 메일함, 다른 MTA 또는 심지어 다른 채널이 될 수 있습니다. 다른 채널로 전달하는 것은 이 그림에 나와 있지 않지만 실제로는 흔히 볼 수 있습니다.
주소와 수신된 필드의 로컬 부분이 일반적으로 7비트 문자라는 점을 주의하시기 바랍니다. MTA는 이러한 필드에서 8비트 문자를 읽을 경우 각 8비트 문자를 별표로 바꿉니다.
디스패처디스패처는 여러 다중 스레드 서버 프로세스가 SMTP 연결 서비스에 대한 역할을 공유할 수 있게 하는 다중 스레드 디스패칭 에이전트입니다. 디스패처를 사용하면 모두 동일한 포트에 대한 연결을 처리하는 여러 다중 스레드 SMTP 서버 프로세스를 동시에 실행할 수 있습니다. 또한 각 서버는 하나 이상의 활성 연결을 가질 수 있습니다.
디스패처는 자체 구성에 나열된 TCP 포트에 대한 중앙 수신기의 역할을 수행합니다. 연결이 설정된 후 디스패처는 정의된 각 서비스에 대해 하나 이상의 SMTP 서버 프로세스를 만들어 연결을 처리할 수 있습니다.
일반적으로 정의된 TCP 포트에 대한 연결을 수신하면 디스패처는 해당 포트의 사용 가능한 작업자 프로세스 풀에서 서비스를 검사하고 새 연결을 위한 최적의 후보를 선택합니다. 적절한 후보를 사용할 수 없는 경우 디스패처는 구성에서 허용하는 경우에 한하여 새 작업자 프로세스를 만들어 새 연결과 후속 연결을 처리할 수 있습니다. 또한 디스패처는 이후의 받는 연결을 예상하여 새 작업자 프로세스를 만들 수도 있습니다. 디스패처의 다양한 서비스 제어를 조정하고 특히 작업자 프로세스 수와 각 작업자 프로세스가 처리하는 연결 수를 제어하는 데 사용할 수 있는 여러 구성 옵션이 존재합니다.
자세한 내용은 디스패처 구성 파일을 참조하십시오.
서버 프로세스 작성 및 만료
디스패처 내의 자동 작업 관리 기능은 새 서버 프로세스의 작성과 오래된 또는 유휴 서버 프로세스의 만료를 제어합니다. 디스패처의 동작을 제어하는 기본 옵션은 MIN_PROCS 및 MAX_PROCS입니다. MIN_PROCS는 여러 서버 프로세스를 준비하고 받는 연결을 대기하여 보증된 서비스 수준을 제공합니다. 반면, MAX_PROCS는 주어진 서비스에 대해 동시에 활성화할 수 있는 서버 프로세스 수에 대한 상한값을 설정합니다.
최대한의 연결을 이미 처리하고 있거나 프로세스의 종료가 예약되었기 때문에 현재 실행 중인 서버 프로세스가 연결을 수락하지 못할 수 있습니다. 이 경우 디스패처는 이후의 연결을 지원하기 위해 추가 프로세스를 만들 수 있습니다.
MIN_CONNS 및 MAX_CONNS 옵션은 서버 프로세스 간에 연결을 분산시킬 수 있는 기법을 제공합니다. MIN_CONNS는 서버 프로세스를 "busy enough"(충분히 사용 중)로 플래그 지정하는 연결 수를 지정하고 MAX_CONNS는 서버 프로세스에 적용할 수 있는 "busiest"(최대한 사용 중)로 지정합니다.
일반적으로 디스패처는 현재 서버 프로세스 수가 MIN_PROCS보다 작거나 모든 기존 서버 프로세스가 "busy enough"(충분히 사용 중)이고 현재 활성화된 연결의 각 수가 최소한 MIN_CONNS인 경우 새 서버 프로세스를 만듭니다.
예를 들어, UNIX 시스템 kill 명령에 의해 서버 프로세스가 예기치 않게 종료할 경우 디스패처는 새 연결이 들어올 때와 마찬가지로 새 서버 프로세스를 만듭니다.
디스패처 구성에 대한 자세한 내용은 디스패처 구성 파일을 참조하십시오.
디스패처 시작 및 중지
디스패처를 시작하려면 다음 명령을 실행합니다.
start-msg dispatcher
이 명령은 디스패처가 관리하도록 구성된 MTA 구성 요소를 시작하기 위해 이전에 사용되던 다른 모든 start-msg 명령을 포함하므로 이러한 이전 명령은 더 이상 사용되지 않습니다. 특히 imsimta start smtp를 더 이상 사용해서는 안 됩니다. 폐기된 명령을 실행하려고 하면 MTA는 경고를 표시합니다.
디스패처를 종료하려면 다음 명령을 실행합니다.
stop-msg dispatcher
디스패처 종료 시에 서버 프로세스에서 수행되는 작업은 기본 TCP/IP 패키지에 따라 달라집니다. 디스패처에 적용되는 MTA 구성 또는 옵션을 수정할 경우 새 구성 또는 옵션이 적용되도록 디스패처를 다시 시작해야 합니다.
디스패처를 다시 시작하려면 다음 명령을 실행합니다.
imsimta restart dispatcher
디스패처를 다시 시작하면 현재 실행 중인 디스패처가 종료되고 새 디스패처가 즉시 시작됩니다.
다시 쓰기 규칙다시 쓰기 규칙은 다음을 결정합니다.
각 다시 쓰기 규칙은 패턴 및 템플리트로 구성됩니다. 패턴은 주소의 도메인 부분에 대해 일치하는 문자열입니다. 템플리트는 도메인 부분이 패턴과 일치할 경우 수행되는 작업을 지정합니다. 두 가지로 구성된 경우 1) 주소를 다시 쓰는 방법을 지정하는 명령 집합(즉, 제어 문자열) 및 2) 메일을 보내야 하는 채널 이름의 두 부분으로 구성됩니다. 주소가 다시 작성된 후 의도한 수신자에게 전달되도록 메일이 대상 채널의 대기열에 포함됩니다.
다시 쓰기 규칙의 예는 다음과 같습니다.
siroe.com $U%$D@tcp_siroe-daemon
siroe.com은 도메인 패턴입니다. siroe.com을 포함하는 주소를 가진 모든 메일은 템플리트 명령($U%$D)에 따라 다시 작성됩니다. $U는 다시 작성된 주소가 같은 아이디를 사용하도록 지정합니다. %는 다시 작성된 주소가 같은 도메인 구분자를 사용하도록 지정합니다. $D는 다시 작성된 주소가 패턴에서 일치했던 같은 도메인 이름을 사용하도록 지정합니다. @tcp_siroe-daemon은 다시 작성된 주소를 가진 메일이 tcp_siroe-daemon이라는 채널로 보내지도록 지정합니다. 자세한 내용은 11장, "다시 쓰기 규칙 구성"을 참조하십시오.
다시 쓰기 규칙의 구성에 대한 자세한 내용은 MTA 구성 파일 및 11장, "다시 쓰기 규칙 구성"을 참조하십시오.
채널채널은 메일을 처리하는 기본 MTA 구성 요소입니다. 채널은 다른 컴퓨터 시스템 또는 시스템 그룹과의 연결을 나타냅니다. 실제 하드웨어 연결 및/또는 소프트웨어 전송은 채널마다 크게 다를 수 있습니다.
채널은 다음 기능을 수행합니다.
메일은 MTA로 들어올 때 채널에 의해 대기열에 포함되고, 나갈 때 대기열에서 제외됩니다. 일반적으로 메일은 특정 채널을 통해 들어가고 다른 채널에 의해 나옵니다. 채널은 메일을 대기열에서 제외하거나, 메일을 처리하거나, 메일을 다른 MTA 채널의 대기열에 포함시킬 수 있습니다.
마스터 및 슬레이브 프로그램
항상 그런 것은 아니지만 채널은 일반적으로 마스터 및 슬레이브의 두 프로그램과 관련됩니다. 슬레이브 프로그램은 다른 시스템에서 메일을 수락하고 채널의 메일 대기열에 추가합니다. 마스터 프로그램은 채널에서 다른 시스템으로 메일을 전송합니다.
예를 들어, SMTP 채널은 메일을 전송하는 마스터 프로그램과 메일을 받는 슬레이브 프로그램을 가집니다. 이러한 프로그램은 각각 SMTP 클라이언트 및 서버입니다.
마스터 채널 프로그램은 일반적으로 MTA가 작업을 시작했던 보내는 연결을 담당합니다. 마스트 채널 프로그램은 다음을 수행합니다.
슬레이브 채널 프로그램은 일반적으로 MTA가 외부 요청에 응답하는 받는 연결을 수락합니다. 슬레이브 채널 프로그램을 다음을 수행합니다.
예를 들어, 그림 8-3에는 두 개의 채널 프로그램(채널 1 및 채널 2)이 나와 있습니다. 채널 1의 슬레이브 프로그램은 원격 시스템으로부터 메일을 받습니다. 이 프로그램은 주소를 확인하고 필요에 따라 다시 쓰기 규칙을 적용한 다음 다시 작성된 주소에 기초하여 해당 채널 메일 대기열에 메일을 포함시킵니다.
마스터 프로그램은 대기열에서 메일을 제외시키고 메일의 네트워크 전송을 시작합니다. 마스터 프로그램이 자신의 채널 대기열에서만 메일을 제외시킬 수 있다는 것을 유의하십시오.
그림 8-3 마스터 및 슬레이브 프로그램
일반 채널이 마스터 및 슬레이브 프로그램을 모두 가지지만 경우에 따라서는 슬레이브 프로그램 또는 마스터 프로그램만 포함할 수도 있습니다. 예를 들어, Messaging Server와 함께 제공되는 ims-ms 채널은 그림 8-4에 나온 것처럼 로컬 메시지 저장소에 대해서만 메일을 대기열에서 제외시키기 때문에 마스터 프로그램만 포함합니다.
그림 8-4 ims-ms 채널
채널 메일 대기열
모든 채널은 연관된 메일 대기열을 가집니다. 메일이 메시징 시스템으로 들어가면 슬레이브 프로그램은 메일을 포함시킬 메일 대기열을 결정합니다. 대기열에 넣은 메일은 채널 대기열 디렉토리의 메일 파일에 저장됩니다. 기본적으로 이러한 디렉토리는 msg_svr_base/data/queue/channel/* 위치에 저장됩니다.
주의
문제가 발생할 수 있으므로 MTA 대기열 디렉토리에서 파일이나 디렉토리(즉, imta_tailor 파일의 IMTA_QUEUE 값)를 추가하지 않도록 합니다. MTA 대기열 디렉토리에 대해 별개의 파일 시스템을 사용할 경우 해당 마운트 지점 아래에 하위 디렉토리를 만들고 이 하위 디렉토리를 IMTA_QUEUE 값으로 지정합니다.
채널 정의
채널 정의는 다시 쓰기 규칙에 뒤이어 MTA 구성 파일 imta.cnf의 하단부에 표시됩니다(MTA 구성 파일 참조). 이 파일에 있는 첫 번째 빈 행은 다시 쓰기 규칙 섹션의 끝 부분이자 채널 정의의 시작 부분을 나타냅니다.
채널 정의는 채널 이름을 포함하며 이어서 채널 구성을 정의하는 선택적 키워드 목록과 메일을 채널로 라우팅하기 위해 다시 쓰기 규칙에서 사용되는 고유한 채널 태그를 포함합니다. 채널 정의는 하나의 빈 행으로 구분됩니다. 채널 정의 안에 주석이 나타날 수 있지만 빈 행을 포함할 수는 없습니다.
채널 정의를 통틀어서 채널 호스트 테이블이라고 하며 개별 채널 정의를 채널 블록이라고 합니다. 예를 들어, 아래 예에서 채널 호스트 테이블은 세 개의 채널 정의 또는 블록을 포함합니다.
일반 채널 항목은 다음과 같이 나타납니다.
tcp_intranet smtp mx single_sys subdirs 20 noreverse maxjobs 7 SMTP_POOL maytlsserver allowswitchchannel saslswitchchannel tcp_auth
tcp_intranet-daemon이 경우 첫 번째 단어 tcp_intranet은 채널 이름이며 마지막 단어 tcp_intranet-daemon을 채널 태그라고 부릅니다. 채널 태그는 메일을 전송하기 위해 다시 쓰기 규칙에 사용되는 이름입니다. 채널 이름과 채널 태그 사이의 단어를 채널 키워드라고 하며, 메일이 처리되는 방법을 지정합니다. 수백 개의 다른 키워드를 사용하여 메일을 다양한 방법으로 처리할 수 있습니다. 채널 키워드의 전체 목록과 자세한 내용은 Sun Java System Messaging Server Administration Reference 및 12장, "채널 정의 구성"을 참조하십시오.
채널 호스트 테이블은 Messaging Server가 사용할 수 있는 채널과 각 채널에 연관되는 시스템의 이름을 정의합니다.
UNIX 시스템에서 파일의 첫 번째 채널 블록은 항상 로컬 채널 l을 설명합니다. (로컬 채널 앞에 놓일 수 있는 defaults 채널은 예외입니다.) 로컬 채널은 라우팅 결정을 내리고 UNIX 메일 도구에 의해 보내진 메일을 전송하는 데 사용됩니다.
MTA 옵션 파일 option.dat에서 채널에 대한 전역 옵션을 설정하거나 채널 옵션 파일의 특정 채널에 대한 옵션을 설정할 수도 있습니다. 옵션 파일에 대한 자세한 내용은 옵션 파일 및 TCP/IP(SMTP) 채널 옵션 파일을 참조하십시오. 채널 구성에 대한 자세한 내용은 12장, "채널 정의 구성"을 참조하십시오. MTA 채널 작성에 대한 자세한 내용은 MTA 구성 파일을 참조하십시오.
MTA 디렉토리 정보MTA는 각 메일을 처리할 때 지원되는 사용자, 그룹 및 도메인에 대한 디렉토리 정보에 액세스해야 합니다. 이 정보는 LDAP 디렉토리 서비스에 저장됩니다. MTA는 LDAP 디렉토리에 직접 액세스합니다. 이에 대한 자세한 내용은 9장, "MTA 주소 변환 및 라우팅"에 설명되어 있습니다.
Job Controller메일이 채널의 대기열에 포함될 때마다 Job Controller는 메일 전달을 위해 실행 중인 작업이 있는지 확인합니다. 여기에는 새 작업 프로세스를 시작하거나, 스레드를 추가하거나, 단순히 작업이 이미 실행 중인지 확인하는 것이 포함됩니다. 채널 또는 풀에 대한 작업 제한에 도달하여 작업을 시작할 수 없을 경우 Job Controller는 다른 작업이 종료할 때까지 기다립니다. 작업 제한을 더 이상 초과하지 않으면 Job Controller는 다른 작업을 시작합니다.
채널 작업은 Job Controller 내의 처리 풀 안에서 실행됩니다. 풀은 채널 작업이 실행되는 "장소"로 생각할 수 있습니다. 풀은 작업 세트가 풀 외부의 작업과 자원을 놓고 경쟁하지 않고도 작동할 수 있는 컴퓨팅 영역을 제공합니다. 풀에 대한 자세한 내용은 Job Controller 파일 및 채널 실행 작업의 처리 풀을 참조하십시오.
채널에 대한 작업 제한은 maxjobs 채널 키워드에 의해 결정되며 풀에 대한 작업 제한은 풀의 JOB_LIMIT 옵션에 의해 결정됩니다.
Messaging Server는 일반적으로 모든 메일을 즉시 전달하려고 시도합니다. 그러나 첫 번째 시도에서 메일을 전달할 수 없는 경우 해당 backoff 키워드에 지정된 기간 동안 메일이 지연됩니다. backoff 키워드에 지정된 시간이 경과하자마자 지연된 메일을 전달할 수 있으며 필요한 경우 메일을 처리하기 위해 채널 작업이 시작됩니다.
현재 처리 중인 메일과 처리 대기 중인 메일에 대한 Job Controller의 메모리 내장 데이터 구조는 일반적으로 MTA 대기열 영역의 디스크에 저장된 전체 메일 파일 집합을 반영합니다. 그러나 디스크의 메일 파일 백로그가 Job Controller의 메모리 내장 데이터 구조 크기 제한을 초과하기에 충분할 만큼 작성될 경우 Job Controller는 디스크의 전체 메일 파일 중 일부만 메모리에서 추적합니다. Job Controller는 메모리에서 추적 중인 메일만 처리합니다. 메모리 내장 저장소를 비워야 할 정도로 많은 메일이 전달된 경우 Job Controller는 MTA 대기열 영역을 스캔하여 메일 목록을 업데이트함으로써 메모리 내장 저장소를 자동으로 갱신합니다. 그런 다음 Job Controller는 디스크에서 방금 검색한 추가 메일 파일의 처리를 시작합니다. Job Controller는 MTA 대기열 영역에 대한 이러한 스캔 작업을 자동으로 수행합니다.
사이트에서 과도한 메일 백로그가 정기적으로 발생할 경우 MAX_MESSAGES 옵션을 사용하여 Job Controller를 조정할 수 있습니다. Job Controller가 더 많은 메모리를 사용할 수 있게 MAX_MESSAGES 옵션 값을 늘리면 메일 백로그가 Job Controller의 메모리 내장 캐시를 오버플로하는 경우를 줄일 수 있습니다. 또한 이 경우 Job Controller가 MTA 대기열 디렉토리를 스캔해야 할 때와 관련된 오버헤드가 줄어듭니다. 그러나 Job Controller가 메모리 내장 캐시를 다시 작성해야 할 경우 캐시가 더 크기 때문에 프로세스에 더 많은 시간이 걸린다는 것을 유의하십시오. 또한 Job Controller는 시작 또는 재시작될 때마다 MTA 대기열 디렉토리를 스캔해야 하므로 과도한 메일 백로그가 있다는 것은 그렇지 않을 때보다 Job Controller를 시작 또는 재시작할 때 많은 오버헤드가 발생한다는 것을 의미합니다.
풀과 Job Controller 구성에 대한 자세한 내용과 Job Controller 파일 및 메일 처리 및 전달 구성을 참조하십시오.
Job Controller 시작 및 중지
Job Controller를 시작하려면 다음 명령을 실행합니다.
start-msg job_controller
Job Controller를 종료하려면 다음 명령을 실행합니다.
stop-msg job_controller
Job Controller를 다시 시작하려면 다음 명령을 실행합니다.
imsimta restart job_controller
Job Controller를 다시 시작하면 현재 실행 중인 Job Controller가 종료되고 새 Job Controller가 바로 시작됩니다.
