Apache 2.4의 MPM 주요설정값 초과시 메시지 예시

Apache 2.4는 MPM(Multi-Processing Module) 구조를 통해 여러 클라이언트 요청을 효율적으로 처리할 수 있도록 설계되어 있다. 하지만 MPM의 주요 설정값들이 현재 시스템 환경에 적절히 설정되지 않으면, 접속 지연, 연결 거부, 리소스 과다 사용 등의 문제가 발생할 수 있다. 이 글에서는 Apache 2.4의 대표적인 MPM 모듈들과 주요 설정값, 그리고 설정값 초과 시 나타나는 문제점과 그 해결책에 대해 정리해보았습니다.

1. ServerLimit 초과 메시지

ServerLimit을 초과했을 때 Apache는 다음과 같은 오류 메시지를 로그에 기록합니다:

MaxRequestWorkers of 565 exceeds ServerLimit value of 256 servers, lowering MaxRequestWorkers to 256. To increase, please see the ServerLimit directive.

또는:

AH00159: ServerLimit of 512 exceeds compile-time limit of 256 servers, limiting to 256. To increase, please see the ServerLimit directive.

2. MaxRequestWorkers 초과 메시지

MaxRequestWorkers 한도에 도달하면 다음과 같은 메시지가 나타납니다:

[Thu Apr 16 14:20:15.123456 2025] [mpm_event:error] [pid 12345] AH00161: server reached MaxRequestWorkers setting, consider raising the MaxRequestWorkers setting

또는:

[Thu Apr 16 14:20:15.123456 2025] [mpm_prefork:error] [pid 12345] AH00161: server reached MaxRequestWorkers setting, consider raising the MaxRequestWorkers setting

3. ThreadLimit 초과 메시지

ThreadLimit을 초과하면 다음과 같은 오류가 발생합니다:

WARNING: ThreadsPerChild of 100 exceeds ThreadLimit value of 64 threads, lowering ThreadsPerChild to 64. To increase, please see the ThreadLimit directive.

또는:

AH00526: Invalid ThreadLimit value, using default of 64 threads. To increase, please see the ThreadLimit directive.

4. MaxSpareThreads 초과 메시지

MaxSpareThreads 값을 초과하면 다음과 같은 메시지가 로그에 기록됩니다:

[Thu Apr 16 14:20:15.123456 2025] [mpm_worker:notice] [pid 12345] AH00292: Too many idle threads, reducing worker thread count from 150 to 100 threads

5. ThreadsPerChild 초과 메시지

ThreadsPerChild 설정을 초과하면 다음과 같은 메시지가 나타납니다:

AH00326: Server ran out of threads to serve requests. Consider raising the ThreadsPerChild setting

또는 다음과 같은 메시지도 발생할 수 있습니다:

[Thu Apr 16 14:20:15.123456 2025] [mpm_worker:error] [pid 12345] scoreboard is full, not at MaxRequestWorkers

6. LimitRequestBody 초과 메시지

LimitRequestBody 제한을 초과하면 클라이언트는 일반적으로 HTTP 413 응답(Request Entity Too Large)을 수신하며, Apache 오류 로그에는 다음과 같은 메시지가 기록됩니다:

[Thu Apr 16 14:20:15.123456 2025] [core:error] [pid 12345] [client 192.168.1.1:55555] AH00413: Requested content-length of 2097153 is larger than the configured limit of 1048576

7. KeepAliveTimeout 초과 메시지

KeepAliveTimeout이 초과되면 Apache는 다음과 같은 메시지를 로그에 기록합니다:

[Thu Apr 16 14:20:15.123456 2025] [core:info] [pid 12345] [client 192.168.1.1:55555] AH00341: KeepAlive timeout exceeded, closing connection

또는 KeepAlive 연결이 타임아웃 되면 다음 메시지를 볼 수 있습니다:

[Thu Apr 16 14:20:15.123456 2025] [core:debug] [pid 12345] [client 192.168.1.1:55555] AH03090: keep alive connection closed after 15 seconds

이러한 메시지들은 Apache의 설정값이 초과된 상황을 파악하고 적절한 대응을 하는 데 중요한 정보를 제공합니다. 서버 관리자는 이런 메시지를 모니터링하여 Apache 서버의 성능을 최적화하고 문제를 해결할 수 있습니다.

ServerLimit

ServerLimit 지시어는 Apache가 생성할 수 있는 최대 프로세스 수의 상한을 정합니다. 이 값이 적절하게 설정되지 않으면 여러 상황에서 경고나 오류가 발생합니다:

• MaxRequestWorkers보다 ServerLimit이 낮은 경우 (설정 불일치): MaxRequestWorkers가 ServerLimit보다 큰 값으로 설정되면 Apache는 시작 시 해당 값을 자동으로 낮추고 경고를 남깁니다. 예를 들어 기본 ServerLimit 256보다 MaxRequestWorkers를 높게 설정하면 다음과 같은 경고가 error_log에 기록됩니다:

  예시 error_log: AH00180: WARNING: MaxRequestWorkers of 512 exceeds ServerLimit value of 256 servers, decreasing MaxRequestWorkers to 256. To increase, please see the ServerLimit directive.

  위 메시지는 MaxRequestWorkers=512 설정이 현재 ServerLimit=256을 넘어서기 때문에, Apache가 MaxRequestWorkers를 256으로 낮추었음을 나타냅니다. 이러한 경고가 나타나면 ServerLimit을 함께 높여야 합니다. 또한 MaxRequestWorkers가 ThreadsPerChild의 배수가 아니어서 필요한 프로세스 수가 ServerLimit을 초과하는 경우 유사한 경고가 발생합니다 (AH00318 등).

• 컴파일 시 상한 초과: 설정한 ServerLimit 값이 Apache 컴파일 시 정의된 절대 상한을 넘는 경우, Apache는 시작 시 값을 줄이고 경고를 남깁니다. (예: “ServerLimit of X exceeds compile-time limit of Y, decreasing to Y.” 형식의 경고). 일반적인 바이너리 배포판에서는 컴파일 상한이 매우 커서 드물지만, 만약 이 한계를 넘을 경우 로그로 알려줍니다.

• 스코어보드(scoreboard) 가득 참: Apache의 프로세스/스레드 관리 구조인 scoreboard 엔트리가 모두 사용되고 더 이상 프로세스를 생성할 수 없는 경우, 실제 MaxRequestWorkers에 도달하지 않았더라도 아래와 같은 오류가 발생할 수 있습니다:

  예시 error_log: [mpm_event:error] ... AH03490: scoreboard is full, not at MaxRequestWorkers. Increase ServerLimit. (Apache 2.4.37 reload causes error “scoreboard is full, not at MaxRequestWorkers.Increase ServerLimit.” - Server Fault)

  이 오류는 “스코어보드가 가득 찼지만 MaxRequestWorkers 한도에는 이르지 않았다. ServerLimit을 늘리라”는 내용입니다. 주로 이전 워커 프로세스들이 정상 종료되지 않고 남아있는 경우(예: Graceful restart 이후 프로세스가 정체됨) 발생하며, Apache가 추가 프로세스를 못 띄우는 상황입니다 (Apache 2.4.37 reload causes error “scoreboard is full, not at MaxRequestWorkers.Increase ServerLimit.” - Server Fault). 이 때는 ServerLimit을 높여 scoreboard 슬롯을 늘리거나, Apache 버그 패치/MPM 설정 조정이 필요합니다.

MaxRequestWorkers

MaxRequestWorkers(이전 버전 용어 MaxClients)는 동시에 처리할 수 있는 최대 요청(스레드)의 수를 정의합니다. 이 값과 ServerLimit 또는 쓰레드 관련 값이 맞지 않으면 오류/경고가 발생하며, 런타임에 실제 한도에 도달해도 메시지가 남습니다:

• 현상: 동시에 요청 가능한 클라이언트 수를 넘어서면, 새로운 요청은 대기하거나 거부됨

• 설정 불일치: 위의 ServerLimit과 연관된 사례처럼, MaxRequestWorkers가 너무 높게 설정되어 ServerLimit이나 ThreadsPerChild 제약을 벗어나면 Apache는 시작 시 경고를 출력합니다. 예를 들어, MaxRequestWorkers가 ThreadsPerChild의 정수 배수가 아닌 경우 Apache는 이를 가장 가까운 배수로 줄이고, 필요한 프로세스 수가 ServerLimit을 넘는다면 추가로 값을 감소시킵니다. 실제 로그 예시는 다음과 같습니다.

  예시 error_log: AH00316: WARNING: MaxRequestWorkers of 512 is not an integer multiple of ThreadsPerChild of 25, decreasing to nearest multiple 500, for a maximum of 20 servers.
AH00318: WARNING: MaxRequestWorkers of 500 would require 20 servers and would exceed ServerLimit of 16, decreasing to 400. To increase, please see the ServerLimit directive.

  위 예시는 MaxRequestWorkers를 무심코 512로 올렸을 때 발생한 경고로, 512가 ThreadsPerChild(25)의 배수가 아니어서 500으로 조정되고, 그 결과 필요한 프로세스 수 20개가 ServerLimit 16을 넘어서므로 최대 워커를 400으로 다시 낮춘 상황입니다.

• 최대 워커수 도달 (런타임): 서버 운용 중 동시 접속자가 설정된 MaxRequestWorkers에 도달하면, 새로운 연결은 대기하거나 거부되며 error_log에 오류가 기록됩니다. 이때 남는 워커가 없다는 의미로 다음 메시지가 나타납니다:

  예시 error_log: AH00161: server reached MaxRequestWorkers setting, consider raising the MaxRequestWorkers setting

  위와 같은 AH00161 오류는 Prefork MPM에서 흔히 보이는 형식이며 (mpm_prefork:error 로 표시), MPM에 따라 AH00286, AH00484 등 코드만 달리하여 동일한 문구가 출력됩니다. 이 메시지는 “서버가 MaxRequestWorkers 한도에 도달했으니 값을 올리는 것을 고려하라”는 권고입니다. 이 상황에서는 Apache가 더 이상 새로운 요청을 처리하지 못하므로 MaxRequestWorkers (및 필요 시 ServerLimit)을 늘려야 합니다.

• 한도 근접 경고: 최대 워커에 거의 도달했을 때 Apache 2.4 스레드형 MPM은 사전에 경고를 남길 수 있습니다. 기본 여유 스레드 설정과 비교하여, 남은 여유 스레드가 얼마 없으면 다음과 같은 AH00287 경고가 나타납니다:

  예시 error_log: AH00287: server is within MinSpareThreads of MaxRequestWorkers, consider raising the MaxRequestWorkers setting (Server is within MinSpareThreads of MaxRequestWorkers, consider raising the MaxRequestWorkers setting – cPanel)

  위 메시지는 현재 유휴 스레드 수가 MinSpareThreads 수준까지 떨어져 MaxRequestWorkers에 근접했음을 뜻합니다. 실제 예에서는 “MinSpareThreads (여유 스레드 최소치)와 MaxRequestWorkers 한도가 매우 가까우니 MaxRequestWorkers를 올리라”는 권고로 로그에 기록되었습니다 (Server is within MinSpareThreads of MaxRequestWorkers, consider raising the MaxRequestWorkers setting – cPanel). 이 경우 곧 최대치에 이를 수 있다는 신호이며, proactive하게 워커 한도를 조정하는 것이 좋습니다.

ThreadLimit

ThreadLimit은 각 Apache 자식 프로세스 당 생성할 수 있는 최대 스레드 수의 상한입니다. mpm_worker나 mpm_event와 같은 스레드 기반 MPM에서 사용되며, ThreadsPerChild과 밀접한 관계가 있습니다. 설정 충돌이나 한도 초과 시 다음과 같은 로그가 나타납니다:

• ThreadsPerChild가 ThreadLimit를 넘는 경우: ThreadsPerChild를 ThreadLimit보다 크게 설정하면 Apache는 시작 시 자동으로 ThreadsPerChild를 줄이고 경고 메시지를 남깁니다. 예를 들어 ThreadLimit=64로 두었는데 ThreadsPerChild=100으로 설정한 경우:

  예시 error_log: WARNING: ThreadsPerChild of 100 exceeds ThreadLimit value of 64 threads, lowering ThreadsPerChild to 64. To increase, please see the ThreadLimit directive. (Apache httpd 2.2 starts with ThreadsPerChild exceeding ThreadLimit warning message - Red Hat Customer Portal)

  위와 같은 경고는 설정된 ThreadsPerChild (100)이 허용된 최대 스레드 수(64)를 초과하여, Apache가 이를 64로 낮추었음을 나타냅니다 (Apache httpd 2.2 starts with ThreadsPerChild exceeding ThreadLimit warning message - Red Hat Customer Portal). 이러한 상황에서는 ThreadLimit을 충분히 키운 뒤 Apache를 재시작해야 경고 없이 설정한 스레드 수를 활용할 수 있습니다.

• 컴파일 시 한도 초과: ThreadLimit 역시 컴파일 시 상한이 있습니다. 만약 이 상한을 넘는 값으로 설정하면 Apache는 시작 시 해당 값을 줄이며 경고합니다 (예: “ThreadLimit of X exceeds compile-time limit of Y, decreasing to Y.” 형태). 이런 메시지가 보이면 Apache가 허용하는 최대 스레드 수 이상으로 설정되었음을 의미하며, 일반적으로 매우 큰 값(수천 이상)을 넣지 않는 한는 드문 경우입니다.

• 유효 범위 이하로 설정: ThreadLimit은 1 이상의 값이어야 합니다. 0이나 음수 등 잘못된 값을 넣으면 Apache는 "ThreadLimit of X not allowed, increasing to 1" 형태로 최소값으로 올렸다는 경고(AH00307 등)를 남기며, 서비스를 기동합니다. 즉, 값이 너무 작아도 Apache가 강제로 1로 변경합니다.

요약하면, ThreadLimit과 ThreadsPerChild는 항상 ThreadLimit ≥ ThreadsPerChild를 만족해야 하며, 그렇지 않으면 Apache가 설정을 조정하면서 위와 같은 경고를 출력합니다.

MaxSpareThreads

MaxSpareThreads는 유휴 상태로 유지할 최대 스레드 수를 의미하며, 웹 서버가 부하 감소 시 불필요하게 많은 스레드를 가지고 있지 않도록 제어합니다. 관련 설정인 MinSpareThreads(유휴 스레드 최소 수)와 잘못된 조합으로 설정하면 Apache는 자동으로 값을 조정하거나 경고를 남깁니다:

• MinSpareThreads보다 낮게 설정된 경우: MaxSpareThreads는 항상 MinSpareThreads보다 크거나 같아야 합니다. 만약 반대로 설정하면 Apache는 시작 시 설정을 교정합니다. 예를 들어 MinSpareThreads=50인데 MaxSpareThreads=40으로 설정했다면, Apache는 경고를 표시하고 MaxSpareThreads를 최소값 이상으로 늘리거나(MinSpareThreads로 맞춤) 서비스를 시작합니다. 실제 Apache 동작으로 미루어 볼 때, Prefork MPM에서 MaxSpareServers < MinSpareServers인 경우 _MaxSpareServers를 MinSpareServers로 자동 상향_하며 경고를 남기는 것으로 알려져 있습니다 (How to optimize Apache performance - Knowledgebase). 스레드의 경우도 이와 유사하게 “MaxSpareThreads cannot be less than MinSpareThreads” 경고를 출력하고, 필요한 경우 값을 조정합니다.

• ThreadsPerChild와의 관계: Apache 2.4 문서에 따르면, MaxSpareThreads 값은 MinSpareThreads + ThreadsPerChild의 합보다 크거나 같도록 설정하는 것이 바람직합니다. 그렇지 않으면, 유휴 스레드가 부족할 때 불필요한 프로세스 스폰/종료가 반복되거나 경고가 발생할 수 있습니다. 특히 값이 너무 작으면 Apache가 최대 프로세스 수(ServerLimit) 내에서 유휴 스레드를 확보하기 어려워져 scoreboard 부족 현상 등을 유발할 수 있습니다.

예시 error_log: (Startup 경고) AH00157: WARNING: MaxSpareThreads of 40 less than MinSpareThreads of 50, increasing to 50. (가상의 예시)

위와 같은 형태로 Apache는 잘못된 유휴 스레드 설정을 감지하여 경고하고 안전한 값으로 수정합니다. 정확한 AH코드와 수치는 Apache 버전/MPM에 따라 다를 수 있지만, 경고의 핵심은 MaxSpareThreads 값이 MinSpareThreads보다 작아서 조정했음을 알리는 것입니다. 적절한 설정 범위 내에서는 일반적으로 이러한 경고 없이 동작하며, 기본값 (MinSpareThreads=25, MaxSpareThreads=75)은 대부분의 상황에서 충분함이 문서에도 언급되어 있습니다.

ThreadsPerChild

ThreadsPerChild는 각 Apache 프로세스가 생성하는 워커 쓰레드의 수를 지정합니다 (Prefork MPM에서는 해당 없음). 이 값은 ThreadLimit 및 MaxRequestWorkers와 연관되어, 설정이 부적절하면 경고 메시지가 발생합니다:

• ThreadLimit 초과: 앞서 ThreadLimit 항목에서 설명한 대로, ThreadsPerChild가 ThreadLimit보다 크면 Apache는 ThreadsPerChild를 ThreadLimit로 낮추고 경고를 출력합니다 (Apache httpd 2.2 starts with ThreadsPerChild exceeding ThreadLimit warning message - Red Hat Customer Portal). 이는 두 지시어가 일치하지 않을 때 나타나는 대표적인 설정 오류입니다.

• MaxRequestWorkers와의 배수 관계: 하이브리드 MPM(worker/event)에서는 MaxRequestWorkers = ServerLimit × ThreadsPerChild이므로, MaxRequestWorkers는 ThreadsPerChild의 정수배가 되어야 합니다. 만약 그렇지 않으면 Apache는 최대 워커수를 _ThreadsPerChild의 배수_로 내립니다. 예를 들어 ThreadsPerChild=25인데 MaxRequestWorkers=30으로 설정하면, 30은 25의 배수가 아니므로 Apache는 이를 25로 줄이고 다음과 같은 경고를 남깁니다:

  예시 error_log: AH00513: WARNING: MaxRequestWorkers of 30 is not an integer multiple of ThreadsPerChild of 25, decreasing to nearest multiple 25 ([Server Optimization

  Websites’ Development with Drupal](https://drupal.mamatuik.com/server/optimize#:~:text=Server%20Optimization%20,64%20ThreadsPerChild%2025%20MaxRequestWorkers%2030))

  위 메시지는 ThreadsPerChild=25일 때 MaxRequestWorkers는 25, 50, 75,… 처럼 25의 배수여야 함을 보여줍니다. 배수가 아닌 30을 설정한 경우 Apache가 자동으로 25로 조정했음을 경고하고 있습니다. 이러한 제약은 프로세스 수를 산정하는 내부 계산 때문이며, 배수가 아닌 경우 일부 워커 스레드가 할당되지 못하는 문제가 생기기에 Apache가 이를 예방하는 것입니다.

• ServerLimit와 연계된 조정: ThreadsPerChild 값을 변경하면, 사용할 프로세스 수(MaxRequestWorkers / ThreadsPerChild)도 변경됩니다. 이때 요구 프로세스 수가 현재 ServerLimit을 넘어설 경우 추가 경고(AH00318 등)가 발생하며, Apache가 MaxRequestWorkers나 ThreadsPerChild를 다시 낮춥니다. 그러므로 ThreadsPerChild를 크게 늘릴 때는 그만큼 ServerLimit도 높여야 합니다. 예를 들어 ThreadsPerChild를 기본 25에서 64로 증가시켰다면, MaxRequestWorkers나 ServerLimit도 그에 맞게 재계산해 설정해야 “MaxRequestWorkers… would exceed ServerLimit” 경고를 피할 수 있습니다.

정리하면 ThreadsPerChild는 ThreadLimit 이하로, 그리고 MaxRequestWorkers와 ServerLimit과 조화를 이루도록 설정해야 하며, 이를 어길 경우 위와 같은 경고 로그가 error_log에 기록됩니다. 이러한 메시지가 보이면 해당 지시어 값들을 서로 맞춰주는 것이 필요합니다.

LimitRequestBody

LimitRequestBody는 클라이언트 요청 본문의 최대 허용 크기(바이트)를 지정합니다. 이 값을 초과하는 큰 요청이 들어오면 Apache는 요청을 거부하며 HTTP 413 (Request Entity Too Large) 응답을 반환하고, error_log에 관련 오류를 남깁니다. 발생 조건과 로그 예시는 다음과 같습니다:

• 요청 본문 크기 초과: 클라이언트가 LimitRequestBody에서 허용한 크기를 넘는 콘텐츠를 업로드하거나 전송하면, Apache 코어에서 이를 즉시 차단합니다. 이때 error_log에는 다음과 같은 메시지가 기록됩니다:

  예시 error_log: AH01588: Requested content-length of 524355 is larger than the configured limit of 524288 ([2917975 - How to restrict the size of a document that can be uploaded to SAP Content Server 6.50

  SAP Knowledge Base Article](https://userapps.support.sap.com/sap/support/knowledge/en/2917975#:~:text=error_log,50))

  위 로그는 요청된 본문 길이(Content-Length 헤더 기준)가 524,355바이트인데, 서버에 설정된 한도는 524,288바이트여서 제한을 초과했음을 나타냅니다 ([2917975 - How to restrict the size of a document that can be uploaded to SAP Content Server 6.50

  SAP Knowledge Base Article](https://userapps.support.sap.com/sap/support/knowledge/en/2917975#:~:text=error_log,50)). Apache는 이 상황에서 해당 요청을 처리하지 않고 413 오류를 클라이언트에 전달합니다. 실제 운영 예시로, 워드프레스 파일 업로드 시 50MB 제한이 걸린 서버에 ~~약 48MB 파일을 보내면 error_log에 “… content-length of 48443338 is larger than the configured limit of 10240000” 과 같은 문구가 기록되고 업로드가 실패합니다 ([content-length issue when uploading large files

  Plesk Forum](https://talk.plesk.com/threads/content-length-issue-when-uploading-large-files.333364/#:~:text=Domain%20has%20PHP%20Settings%20in,to%20allow%20uplaoding%20large%20files)).

• ModSecurity 등과의 관계: 별도 모듈이 없다면 Apache 코어가 위와 같은 메시지를 남기지만, ModSecurity와 같이 요청 본문을 검사하는 모듈이 있으면 해당 모듈의 로그 형식으로 추가 메시지가 기록될 수 있습니다. 예를 들어 ModSecurity 기본 설정이 1MB로 되어 있을 경우, “ModSecurity: Request body no files data length is larger than the configured limit (1048576)”라는 오류가 남고, 이로 인해 413이 발생하기도 합니다. 하지만 이것은 ModSecurity의 한도이며, Apache 자체의 LimitRequestBody 제한에 걸리면 AH01588 코드의 메시지로 기록되는 것이 일반적입니다.

• 기본값 변경 이슈: Apache 2.4.54부터 LimitRequestBody의 기본값이 0(제한없음) → 1GiB(1073741824 바이트)로 변경되었습니다. 따라서 별도로 설정하지 않은 환경에서도 1GiB를 넘는 요청은 413으로 거부되며, error_log에 _요청 길이가 1073741824바이트 한도를 초과했다_는 메시지가 나타날 수 있습니다 (Requested content-length is larger than the configured limit of 1073741824 ( Apache 2.4.54 , 413 error code ) – cPanel) (Requested content-length is larger than the configured limit of 1073741824 ( Apache 2.4.54 , 413 error code ) – cPanel). 업그레이드 후 대용량 파일 업로드가 실패한다면 이 변경 사항을 의심해야 합니다.

요약하면, LimitRequestBody를 설정하거나 기본 1GiB 한도를 넘는 요청이 들어오면 Apache는 요청을 차단하고 error_log에 AH01588 형태의 로그를 남깁니다. 이러한 로그를 확인했다면 LimitRequestBody 값을 늘리거나 클라이언트 요청 크기를 줄이는 대처가 필요합니다 (Requested content-length is larger than the configured limit of 1073741824 ( Apache 2.4.54 , 413 error code ) – cPanel) (Requested content-length is larger than the configured limit of 1073741824 ( Apache 2.4.54 , 413 error code ) – cPanel).

KeepAliveTimeout

KeepAliveTimeout은 HTTP 지속연결(Keep-Alive)에서 다음 요청을 기다리는 최대 초(second) 단위를 정의합니다. 이 값 자체는 다른 지시어처럼 명시적 오류를 발생시키지는 않지만, 너무 낮거나 높게 설정된 경우 연결의 종료/유지 관련 이슈로 간접적인 로그나 현상이 나타날 수 있습니다:

• 짧은 KeepAliveTimeout으로 인한 조기 연결 종료: Keep-Alive 대기 시간이 너무 짧으면 클라이언트가 두 번째 요청을 보내기도 전에 서버가 연결을 닫아버릴 수 있습니다. 이 경우 별도의 error_log 오류 없이도, 클라이언트 측에서 연결이 리셋되거나(ERR_CONNECTION_RESET 등) 응답 지연이 발생할 수 있습니다. Apache는 짧은 keep-alive로 인한 정상적인 연결 종료에 대해 특별한 로그를 남기지 않으며, 경우에 따라 access log에 HTTP 408 Request Timeout이 기록되기도 합니다. 하지만 이는 오류가 아닌 설정에 따른 동작입니다.

• 긴 KeepAliveTimeout으로 인한 리소스 점유: KeepAliveTimeout을 너무 크게 잡으면, 각 연결이 오랫동안 유지되어 유휴 상태의 워커 스레드/프로세스가 늘어나게 됩니다. 이렇게 되면 트래픽이 많은 서버에서는 성능 문제가 생길 수 있으며 (core - Apache HTTP Server Version 2.4), 특히 워커가 계속 붙잡혀 있으므로 MaxRequestWorkers 한도에 빨리 도달할 위험이 있습니다. 실제로 KeepAliveTimeout을 높게 설정한 환경에서 동시 접속자 증가 시 Apache는 유휴 연결들 때문에 워커를 소진하여 앞서 소개한 “server reached MaxRequestWorkers” 오류를 더 쉽게 만날 수 있습니다. Apache 공식 문서에서도 “KeepAliveTimeout을 너무 크게 잡으면 부하가 큰 서버에서 성능 문제가 생긴다”고 경고하고 있습니다 (core - Apache HTTP Server Version 2.4).

• 요청 헤더 타임아웃 로그: Keep-Alive 상태에서 클라이언트가 새로운 요청을 보내지 않은 채 Timeout이 경과하면, Apache는 해당 연결을 종료합니다. 이 과정에서 mod_reqtimeout 모듈이 활성화되어 있으면, 일정 시간 응답이 없는 요청에 대해 다음과 같은 정보를 error_log에 남길 수 있습니다:

  예시 error_log: [reqtimeout:info] [client 37.103.75.185:49577] AH01382: Request header read timeout

  위 메시지는 지속연결 중 클라이언트의 요청 헤더를 제한 시간 내에 받지 못해 타임아웃으로 연결을 닫았음을 나타냅니다. 기본적으로 mod_reqtimeout은 헤더를 20초 내에 못 받으면 AH01382 로그를 남기며 연결을 종료하도록 설정되어 있으며, 이 시간은 KeepAliveTimeout보다 길게 설정되는 경우가 많습니다. 하지만 만약 KeepAliveTimeout을 매우 크게 설정했다면, mod_reqtimeout이 개입하여 _미사용 연결_을 정리하고 로그를 남기는 일이 발생할 수 있습니다. (KeepAliveTimeout 자체로는 error_log에 별다른 기록을 남기지 않습니다.)

요약하면, KeepAliveTimeout 값 그 자체로 직접적인 error_log “오류” 메시지를 생성하지는 않습니다. 대신 너무 낮으면 연결이 금방 닫혀 클라이언트에 영향을 줄 수 있고, 너무 높으면 워커가 놀면서도 차지되어 MaxRequestWorkers 등 다른 한도를 소진시키는 부작용이 있습니다 (core - Apache HTTP Server Version 2.4). 따라서 KeepAliveTimeout은 일반적으로 수 초 수준으로 적정하게 유지하는 것이 좋습니다 (기본값 5초). 만약 위 예시처럼 Request header read timeout 등의 로그가 자주 보인다면 KeepAlive 관련 설정 및 mod_reqtimeout 설정을 재검토해볼 필요가 있습니다.

참고 자료: Apache 공식 문서 및 커뮤니티 조언에 따르면, KeepAliveTimeout을 과도하게 높이지 말고 과도하게 낮추지도 말 것을 권장하며, 이는 error_log 메시지보다는 성능과 리소스 문제로 드러나는 설정 항목입니다 (core - Apache HTTP Server Version 2.4).