☰

RoundCube는 mysql에 절전 연결이 너무 많습니다.

tag-icon • tag-icon mysql httpd roundcube
RoundCube는 mysql에 절전 연결이 너무 많습니다.

다음과 같은 세부정보가 포함된 메일 ​​서비스가 있습니다.

    1-Centos 6.4
    2:Postfix 2.6.6
    3:roundcube 0.8 
    4:dovecot 2.0.9.7
    5:mysql-server 5.1.71

모든 것이 정상이지만 최대 사용 시간에는 roundcube 절전 연결이 10분 이내에 1, 2 또는 3에서 270으로 증가하고 해당 피크 시간에 Apache에서 열린 파일(lsof로 측정)이 4000에서 20000으로 증가합니다.

이것은 apache conf입니다: (아파치는 프리포크 모드에서 작동합니다)

PidFile run/httpd.pid
Timeout 60
KeepAlive On
MaxKeepAliveRequests 100
<IfModule prefork.c>
StartServers       8
MinSpareServers    5
MaxSpareServers   20
ServerLimit      256
MaxClients       256
MaxRequestsPerChild  4000
</IfModule>
TraceEnable off
LimitRequestLine 1024
LimitRequestFields 100
LimitRequestFieldsize 1024
LimitRequestBody 10241024

다음은 mysql 구성입니다.

secure_auth=1
local_infile=0
max_connections        = 600
max_allowed_packet    = 16M
key_buffer        =256M
wait_timeout=240
interactive_timeout=180
connect_timeout=10
innodb_buffer_pool_size=2G

roundcube의 절전 연결이 100 이상으로 증가하면 거의 서비스(웹, 메일, mysql)가 다운됩니다....

어떤 제안이라도 감사드립니다.

답변1

정답은:

Apache max_client 옵션을 더 낮은 값으로 편집했습니다. 256 --> 50 왜!?

(여전히) 알려지지 않은 문제의 경우 모든 사전 포크된 Apache 프로세스는 CPU 사용량을 약 100%로 차지합니다(잠시 동안 사전 포크된 Apache 프로세스를 실행하는 해당 코어의 100% 사용량).

따라서 시스템이 다운됩니다. Apache의 256개 프로세스가 모두 100% CPU 사용량을 사용할 때 시스템에 64개의 CPU 코어가 있기 때문에 시스템과 서비스가 다운됩니다.

문제는 여전히 존재하지만 서비스에는 문제가 없습니다. 네트워크 공격과 관련된 문제인 것 같습니다(모니터링 도구는 하루에 많은 공격을 보고합니다). 리소스 잠금이나 기타 문제를 일으키는 경우도 있습니다.

모든 제안에 감사드립니다.

답변2

지금

약 5년 후

문제는 며칠 만에 감지되어 해결되었습니다.

저 같은 주니어 시스템 관리자에게는 너무 복잡했습니다. ;)

팀원이 iSCSI LUN에서 준비한 GFS2 클러스터 파일 시스템에 문제가 있었고 이 문제로 인해 Dovecot 및 roundcube(그리고 apache)에서 다양한 문제가 발생했습니다.

참고로, top 명령의 %wa 매개변수에 주의를 기울였을 때(약 90%였습니다) 파일 시스템 수준에 문제가 있다고 생각했습니다.

그런 다음 GFS가 더 이상 사용되지 않기 때문에 모든 데이터를 새로운 클러스터 파일 시스템(ocfs2)으로 전송하기로 결정했습니다!

우선, 모든 데이터를 새로운 클러스터 파일 시스템(ocf2)으로 이동한 다음 debian wheezy의 Pacemake haproxy를 기반으로 전체 시스템을 다시 설계했습니다!

관련 정보