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

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년이 걸렸다.

아따 잘 된다.

집에 돌아오면 나를 기다리는 KT 기사 아저씨가 설치해놓은 4대의 추가 모뎀

아저씨 랜선은요?

그보다 심각한건 PCI-E x4 슬롯을 사용하면 PCI-E x1 슬롯 두 개가 사용 불능하다는

구매할 당시에 아무도 읽지 않는 메인보드의 스펙이 불러온 참사 dafaq

일단 2개 회선이나마 추가합니다 징징

레이드 0 깨먹어서 복구하느라 3시간 써먹은 건 덤이죠.

x4 슬롯 쓴다고 x1 슬롯 두 개가 마비된다니 정신 나간 것 같다.

x16 슬롯도 x4만큼 밖에 안 쓰는데 어떻게 좀 분배라도 안 됩니까 기가바이트씨

래크 끝에 글루건으로 떡칠해놓은 저 부분을 안 떡칠하고 했다가 집게가 빠져서 망