Thời gian chờ đợi lâu trước khi phản hồi của máy chủ Apache 2.2 (Gentoo LAMP)

Gần đây tôi đã chuyển trang web của khách hàng (sử dụng CMS cụ thể5) sang VPS chạy Gentoo, Apache 2.2, PHP5 và MySQL 5 và tôi nhận thấy rằng thời gian phản hồi của Apache khá tệ (tương tự trên máy chủ cũ) , đôi khi lên tới 8-9 giây, nhưng thường xuyên hơn trong khoảng từ 300ms đến 3 giây (đối với 300ms tôi không bận tâm). Tôi biết đó không phải là độ trễ mạng, vì máy chủ có ping (từ vị trí của tôi) khoảng 30ms.

Đây là một ví dụ về thời gian (bạn có thể thấy nó linh hoạt sau khi chờ đợi ban đầu):

Tôi đang chạy APC (mặc dù tôi không chắc là nó hoạt động tốt ...) và SuExec. Các mô-đun Apache là:

 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)

và các mô-đun PHP là:

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

Tôi đã kích hoạt gzip trên tất cả các tệp có liên quan.

Apache đang chạy bằng prefork và các cài đặt trong httpd.conf là:

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

HostnameLookups Off

Tôi đã nhận thấy rằng các trang (tôi nghĩ) nặng về cơ sở dữ liệu, chẳng hạn như Bảng điều khiển của CMS, thường chậm hơn. Tôi nghĩ điều này có nghĩa là MySQL có thể được tối ưu hóa. Tôi cũng băn khoăn về các mô-đun Apache - Tôi bị nhầm lẫn giữa mod_php5, mod_cgi, mod_fastcgi, v.v. - có một lời khuyên mâu thuẫn trên mạng về cách tốt nhất để sử dụng.

Đây là đầu ra của 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)

Tôi nhận thấy khi một trang nặng DB được tải, mức sử dụng CPU tăng vọt ở mức 57% (sử dụng hàng đầu) - với tôi điều đó cho thấy có một số nội dung MySQL được tối ưu hóa kém hoặc bộ nhớ đệm là hoàn toàn cần thiết để tăng tốc thiết lập này.

Bất kì sự trợ giúp nào đều được đánh giá cao!

Bạn có biết chính xác những gì các quy trình công nhân apache đang được treo trên? Hãy thử điều này để xem:

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

Tải một vài trang mới (tức là không được lưu trong bộ nhớ cache cục bộ) trong trình duyệt của bạn, CTRL + C để dừng strace sau đó sắp xếp strace.logs theo thời gian dành cho mỗi cuộc gọi:

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

Xem bất kỳ strace.log nào với hơn 1 giây gọi và tìm kiếm theo thời gian từ đầu ra của lệnh trước đó. Điều này sẽ chỉ cho bạn bước chính xác mà họ đang bị treo.

Bạn có thay đổi có cài đặt tường lửa như CSF không? Tôi thấy vấn đề tương tự trên VPS. Khi gỡ lỗi các tiến trình httpd với strace, nó mất tới 5 giây hoặc hơn cho các cuộc gọi gettimeofday. Thật kỳ lạ, tôi đã thu hẹp điều này xuống CSF, công ty đang cố gắng lọc giao diện venet0, giao diện loopback trong các thùng chứa OpenVZ hoặc Virtuozzo. Đặt tham số này trong /etc/csf/csf.conf hầu như đã sửa nó cho tôi:

"ETH_DEVICE_SKIP = "venet0,lo"

Tôi nói chủ yếu là vì đôi khi vẫn còn 500-1000ms chờ kết nối được thiết lập nhưng đó là một cải tiến lớn từ 5000+.

Đây là một mồi / hướng dẫn tuyệt vời để khắc phục các loại sự cố này bằng cách sử dụng strace.

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

Đây phải là một hộp VPS cấp thấp?

• Bạn có thể muốn quay số cài đặt MySQL của bạn
• Điều chỉnh Apache để giảm số lượng nhánh httpd
• Kiểm tra xem bạn có thể bật hoán đổi không
• APC có được thiết lập để tự động lưu trữ opcodes không? Kiểm tra bằng cách sử dụng tập lệnh 'apc.php' được phân phối với apc.

Bạn phải tách mạng, apache, mysql và php làm nguồn của độ trễ.

Nếu bạn có thể kéo một hình ảnh từ apache một cách nhanh chóng (thời gian rất thấp đến byte đầu tiên), thì mạng và apache thường ổn.

Nếu bạn có thể kéo một trang chỉ bằng một câu lệnh phpinfo (), thì PHP thông thường là ổn (có thể cần một vài điều chỉnh).

Nếu bạn viết một bài kiểm tra kết nối DB đơn giản và nó nhanh, thì lớp đó thường cũng ổn.

Cuối cùng, kéo trang ứng dụng. Nếu nó chậm thì vấn đề là nội bộ đối với việc xử lý các ứng dụng. Trong khi điều chỉnh có thể giúp đỡ, điều này là khó khăn hơn nhiều để giải quyết.

Không có hồ sơ ứng dụng, có thể khó tìm ra vấn đề. Các công cụ như NewRelic có thể giúp giải quyết vấn đề này nhưng không phải là cách chữa trị.

Ứng dụng của bạn có bất kỳ loại gỡ lỗi nội bộ nào để hiển thị thời gian đang sử dụng không?

tôi đề nghị thêm một phép đo thời gian kết xuất và kiểm tra xem máy chủ sẽ mất bao lâu để hiển thị trang HTML thuần túy. Sau đó, bạn biết nếu nó trong CMS hoặc nơi khác. Tôi đặt cược 2cent của tôi không phải cấu hình máy chủ của bạn. / maddin