최근에 클라이언트 웹 사이트 (concrete5 CMS 사용)를 Gentoo, Apache 2.2, PHP5 및 MySQL 5를 실행하는 VPS로 옮겼으며 Apache 응답 시간이 꽤 나쁘다는 것을 알았습니다 (이전 서버에서 동일 함) , 때로는 최대 8-9 초이지만 더 자주 300ms와 3 초 사이입니다 (300ms를 향하여 마음에 들지 않습니다). 서버에 약 30ms의 핑이 있기 때문에 네트워크 대기 시간이 아니라는 것을 알고 있습니다.
시간의 예는 다음과 같습니다 (처음 대기 한 후 시간이 지남을 알 수 있습니다).
나는 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 항목이 있거나이 설정 속도를 높이기 위해 캐싱이 필요하다는 것을 알았습니다.
어떤 도움이라도 대단히 감사하겠습니다!
답변
아파치 작업자 프로세스가 어떻게 진행되고 있는지 정확히 알고 있습니까? 이것을보십시오 :
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+에서 크게 개선되기 때문에 주로 말합니다.
답변
다음은 strace를 사용하여 이러한 종류의 문제를 해결하기위한 훌륭한 입문서 입니다.
Maximum possible memory usage: 219.7M (93% of installed RAM)
저사양 VPS 박스 여야합니까?
- 당신은 당신의 MySQL 설정을 다이얼 다운 할 수 있습니다
- httpd 포크 수를 줄이기 위해 Apache 조정
- 스와핑을 활성화 할 수 있는지 확인
- APC가 자동으로 opcode를 캐시하도록 설정되어 있습니까? apc와 함께 배포 된 ‘apc.php’스크립트를 사용하여 확인하십시오.
답변
지연 시간의 원인으로 네트워크, 아파치, mysql 및 php를 분리해야합니다.
아파치에서 이미지를 빠르게 가져올 수 있다면 (첫 번째 바이트까지 매우 낮은 시간), 네트워크와 아파치는 일반적으로 좋습니다.
phpinfo () 문만으로 페이지를 가져올 수 있다면 평소 PHP는 괜찮습니다 (몇 가지 조정이 필요할 수 있습니다).
간단한 DB 연결 테스트를 작성하고 빠르면 일반적으로 해당 계층도 괜찮습니다.
마지막으로 응용 프로그램 페이지를 당기십시오. 속도가 느리면 응용 프로그램 처리에 문제가있는 것입니다. 튜닝이 도움이 될 수 있지만 해결하기가 훨씬 어렵습니다.
응용 프로그램을 프로파일 링하지 않으면 문제를 찾기가 어려울 수 있습니다. NewRelic과 같은 도구는이 문제를 해결하는 데 도움이되지만 치료법은 아닙니다.
앱에 시간이 소비되는 위치를 보여주는 모든 유형의 내부 디버깅이 있습니까?
답변
렌더링 시간 측정을 추가하고 서버가 순수한 HTML 페이지를 렌더링하는 데 걸리는 시간을 확인하는 것이 좋습니다. 그런 다음 CMS 또는 다른 곳에 있는지 알 수 있습니다. 서버 구성이 아닌 내 2cent에 베팅했습니다. / 마딘