Apache 2.2 서버 응답 (Gentoo LAMP) 이전 대기 시간


9

최근에 클라이언트 웹 사이트 (concrete5 CMS 사용)를 Gentoo, Apache 2.2, PHP5 및 MySQL 5를 실행하는 VPS로 옮겼으며 Apache 응답 시간이 꽤 나쁘다는 것을 알았습니다 (이전 서버에서 동일 함) , 때로는 최대 8-9 초이지만 더 자주 300ms와 3 초 사이입니다 (300ms를 향하여 마음에 들지 않습니다). 서버에 약 30ms의 핑이 있기 때문에 네트워크 대기 시간이 아니라는 것을 알고 있습니다.

시간의 예는 다음과 같습니다 (처음 대기 한 후 시간이 지남을 알 수 있습니다).

Firebug Net 패널 타임 라인

나는 APC ( 잘 작동하는지 잘 모르겠지만 )와 SuExec을 실행하고 있습니다. 아파치 모듈은 :

 core_module (static)
 authn_file_module (static)
 authn_default_module (static)
 authz_host_module (static)
 authz_groupfile_module (static)
 authz_user_module (static)
 authz_default_module (static)
 auth_basic_module (static)
 include_module (static)
 filter_module (static)
 deflate_module (static)
 log_config_module (static)
 env_module (static)
 expires_module (static)
 headers_module (static)
 setenvif_module (static)
 version_module (static)
 ssl_module (static)
 mpm_prefork_module (static)
 http_module (static)
 mime_module (static)
 status_module (static)
 autoindex_module (static)
 asis_module (static)
 info_module (static)
 suexec_module (static)
 cgi_module (static)
 negotiation_module (static)
 dir_module (static)
 actions_module (static)
 userdir_module (static)
 alias_module (static)
 rewrite_module (static)
 so_module (static)
 suphp_module (shared)

PHP 모듈은 다음과 같습니다.

bcmath
calendar
ctype
curl
db
dbase
domxml
exif
ftp
gd
gettext
iconv
imap
mbstring
mcrypt
mime_magic
mysql
openssl
overload
pcre
posix
session
standard
sysvsem
sysvshm
tokenizer
xml
xslt
zlib

모든 관련 파일에서 gzip을 사용하도록 설정했습니다.

Apache는 prefork를 사용하여 실행 중이며 httpd.conf의 설정은 다음과 같습니다.

<IfModule prefork.c>
StartServers         10
MinSpareServers      10
MaxSpareServers      20
MaxClients           250
MaxRequestsPerChild  4000
</IfModule>

HostnameLookups Off

CMS의 대시 보드와 같이 데이터베이스가 많은 페이지는 일반적으로 느리다는 것을 알았습니다. 이것이 MySQL을 최적화 할 수 있음을 의미한다고 생각했습니다. 나는 또한 mod_php5, mod_cgi, mod_fastcgi 등과 같은 아파치 모듈에 대해 궁금해했다. 사용하기 가장 좋은 것에 관해서는 상충되는 충고가있다.

다음은 MySQLTuner 의 출력입니다 .

-------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.0.44-log
[OK] Operating on 64-bit architecture

-------- Storage Engine Statistics -------------------------------------------
[--] Status: -Archive -BDB -Federated -InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 35M (Tables: 161)
[!!] Total fragmented tables: 15

-------- Security Recommendations  -------------------------------------------
[OK] All database users have passwords assigned

-------- Performance Metrics -------------------------------------------------
[--] Up for: 3d 21h 44m 16s (293K q [0.868 qps], 1K conn, TX: 135M, RX: 90M)
[--] Reads / Writes: 99% / 1%
[--] Total buffers: 58.0M global + 1.6M per thread (100 max threads)
[!!] Maximum possible memory usage: 219.7M (93% of installed RAM)
[OK] Slow queries: 0% (0/293K)
[OK] Highest usage of available connections: 2% (2/100)
[OK] Key buffer size / total MyISAM indexes: 16.0M/20.9M
[OK] Key buffer hit rate: 99.6% (5M cached / 21K reads)
[!!] Query cache is disabled
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 3K sorts)
[!!] Temporary tables created on disk: 47% (2K on disk / 5K total)
[!!] Thread cache is disabled
[!!] Table cache hit rate: 6% (64 open / 1K opened)
[OK] Open file limit used: 12% (128/1K)
[OK] Table locks acquired immediately: 100% (356K immediate / 356K locks)

-------- Recommendations -----------------------------------------------------
General recommendations:
    Run OPTIMIZE TABLE to defragment tables for better performance
    Reduce your overall MySQL memory footprint for system stability
    Enable the slow query log to troubleshoot bad queries
    When making adjustments, make tmp_table_size/max_heap_table_size equal
    Reduce your SELECT DISTINCT queries without LIMIT clauses
    Set thread_cache_size to 4 as a starting value
    Increase table_cache gradually to avoid file descriptor limits
Variables to adjust:
  *** MySQL's maximum memory usage is dangerously high ***
  *** Add RAM before increasing MySQL buffer variables ***
    query_cache_size (>= 8M)
    tmp_table_size (> 32M)
    max_heap_table_size (> 16M)
    thread_cache_size (start at 4)
    table_cache (> 64)

DB가 많은 페이지가로드되었을 때 CPU 사용량이 57 % (상단 사용)로 급증했습니다. 나에게 나쁘게 최적화 된 MySQL 항목이 있거나이 설정 속도를 높이기 위해 캐싱이 필요하다는 것을 알았습니다.

어떤 도움이라도 대단히 감사하겠습니다!


2
생각 만 : HostnameLookup로그 구성이 활성화되어 있습니까? 그렇다면 액세스 로그에 추가 할 요청 클라이언트의 DNS 조회가 매우 느리거나 첫 번째 DNS 서버가 시간 초과되어 전체 요청이 느려질 수 있습니다.
jCoder

사용 중지되었습니다. 원래 게시물에 추가하겠습니다.
melat0nin

PHP 관련 요청 만있는 경우 APC에서 조각화를 확인하십시오. 또한 리소스 사용량을 면밀히 모니터링해야합니다. 서버가 모든 리소스를 사용하고 있습니까?
Kvisle

이미 오전 (OP 참조) :)
melat0nin

그것에 대해 죄송합니다 :)-내 의견을 업데이트; PHP 요청 또는 다른 요청인지 확인 했습니까? 서버가 유휴 상태입니까? APC가 조각화 되었습니까? 다른 것들에 비해 '캐시'되는 메모리는 얼마입니까?
Kvisle

답변:


14

아파치 작업자 프로세스가 어떻게 진행되고 있는지 정확히 알고 있습니까? 이것을보십시오 :

mkdir /strace; ps auxw | grep httpd | awk '{print"-p " $2}' | xargs strace -o /strace/strace.log -ff -s4096 -r

브라우저에 몇 가지 새로운 (즉, 로컬로 캐시되지 않은) CTRL + C 페이지를로드하여 strace를 중지 한 다음 각 호출에 소비 된 시간별로 strace.log를 정렬하십시오.

for i in `ls /strace/*`; do echo $i; cat $i | cut -c11-17 | sort -rn | head; done

1.0 초가 넘는 호출로 strace.log를보고 이전 명령의 출력에서 ​​시간별로 검색하십시오. 이렇게하면 그들이 걸려있는 정확한 단계를 알 수 있습니다.

CSF와 같은 방화벽이 설치되어 있습니까? VPS에서도 이와 동일한 문제가 발생했습니다. strace로 httpd 프로세스를 디버깅 할 때 gettimeofday 호출에서 최대 5 초 이상이 걸렸습니다. 이상하게도 OpenFZ 또는 Virtuozzo 컨테이너의 루프백 인터페이스 인 venet0 인터페이스를 필터링하려고하는 CSF로 범위를 좁혔습니다. /etc/csf/csf.conf에서이 매개 변수를 설정하면 대부분 나를 위해 수정했습니다.

"ETH_DEVICE_SKIP = "venet0,lo"

나는 종종 연결이 설정되기를 기다리는 데 여전히 500-1000ms가 있기 때문에 5000+에서 크게 개선되기 때문에 주로 말합니다.


1
답변 주셔서 감사합니다! 결국 APC가 제대로 작동했을 때 상황이 정렬되는 것처럼 보였습니다.이 사이트는 매우 빠릅니다. 그러나 훌륭한 지침을 얻으려면 +1이며, 이와 같은 것을 다시 보게 될 경우를 대비하여 설명하겠습니다.
melat0nin

3

다음은 strace를 사용하여 이러한 종류의 문제를 해결하기위한 훌륭한 입문서 입니다.

Maximum possible memory usage: 219.7M (93% of installed RAM)

저사양 VPS 박스 여야합니까?

  • 당신은 당신의 MySQL 설정을 다이얼 다운 할 수 있습니다
  • httpd 포크 수를 줄이기 위해 Apache 조정
  • 스와핑을 활성화 할 수 있는지 확인
  • APC가 자동으로 opcode를 캐시하도록 설정되어 있습니까? apc와 함께 배포 된 'apc.php'스크립트를 사용하여 확인하십시오.

3

지연 시간의 원인으로 네트워크, 아파치, mysql 및 php를 분리해야합니다.

아파치에서 이미지를 빠르게 가져올 수 있다면 (첫 번째 바이트까지 매우 낮은 시간), 네트워크와 아파치는 일반적으로 좋습니다.

phpinfo () 문만으로 페이지를 가져올 수 있다면 평소 PHP는 괜찮습니다 (몇 가지 조정이 필요할 수 있습니다).

간단한 DB 연결 테스트를 작성하고 빠르면 일반적으로 해당 계층도 괜찮습니다.

마지막으로 응용 프로그램 페이지를 당기십시오. 속도가 느리면 응용 프로그램 처리에 문제가있는 것입니다. 튜닝이 도움이 될 수 있지만 해결하기가 훨씬 어렵습니다.

응용 프로그램을 프로파일 링하지 않으면 문제를 찾기가 어려울 수 있습니다. NewRelic과 같은 도구는이 문제를 해결하는 데 도움이되지만 치료법은 아닙니다.

앱에 시간이 소비되는 위치를 보여주는 모든 유형의 내부 디버깅이 있습니까?


0

렌더링 시간 측정을 추가하고 서버가 순수한 HTML 페이지를 렌더링하는 데 걸리는 시간을 확인하는 것이 좋습니다. 그런 다음 CMS 또는 다른 곳에 있는지 알 수 있습니다. 서버 구성이 아닌 내 2cent에 베팅했습니다. / 마딘


렌더링 시간을 측정하는 방법을 제안 할 수 있습니까? 정적 HTML 페이지의 Firebug 's Net 패널은 충분합니까?
melat0nin
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.