FASTCGI(php-cgi.exe) 대용량 파일 전송 끊김 문제 해결

저번 포스팅에서 완벽하게 해결되지 못 했던

Fastcgi로 대용량 파일 보내기 중 다운로드 속도가 0이 되면서 멈추던 문제.

사실 이 증상 하나만은 해결했지만 이것 때문에 DB를 못 불러와서 페이지 로딩이 극악으로 느린 사태가 발생했다.

php-cgi.exe가 대용량 파일 전송을 감당하지 제대로 못 하는지 다운로드를 시작하면

이런식으로 php-cgi.exe 프로세스가 왕창 생성되는데 이때문에 프로세스 수의 제한에 걸려서 더 이상 프로세스를 생산하지 못하고

페이지 로딩을 처리할 프로세스가 남아나질 않는 문제였다.

위에 보면 178개 이미, 기본 설정에서는 상상도 못 할 숫자다. 글을 쓰고 있는 지금도 260개 돌파, 343 돌파!

원인을 찾기 위해서 FastCgi 설정에서 시간 제한 시리즈를 낮추고, 대용량 파일을 다운로드하면서

마리아DB에 딸려있던 관리 프로그램으로 php-cgi의 상태를 보니 60초 쯤에서 프로세스들이 마구마구 죽어나가는 모습을 발견하는데 성공(은 저번 포스팅에서 한 일)

그리고 그로 인해 페이지 로딩이 느려터졌던 문제는 조금 위에 있는 최대 인스턴스 수를 500개로 임의로 지정해줌으로써 해결!

결국

내 기준(IIS + PHP + 마리아DB) 세팅에서 대용량 파일을 유저에게 보내기 위해서 필요한 세 가지 세팅은

1. Fastcgi 설정에서 최대 인스턴스 수(0이면 안 됨 임의로 크게 설정해야 프로세스를 많이 뽑을 수 있음), ~~ 시간 제한 삼총사

2. 요청 필터링에서 최대 콘텐츠 길이

3. 널리 알려진 PHP.ini에서 최대 시간 2종 세트와 메모리 제한(이건 업로드 관련일 듯)

그리고

이 수 많은 프로세스들을 버텨낼 쓸만한 CPU 정도...

2500k로는 버겁나... 4790k 도로 달아줘야하나...

덤으로 1~2년 동안 나를 계속 괴롭혀오던 이 HTTP 500.0 FastCGI 프로세스가 최근에 자주 실패했습니다. 에러도

위처럼 프로세스 10개(기본 설정)가 1분 동안 킬 당하면 발생하는 에러인 것 같다.

시벌!

여기까지 오는데 서버질 3년, 원인 분석 1년이 걸렸다.

아따 잘 된다.