Theo dõi các vấn đề bộ nhớ ảnh hưởng đến một trang web


7

Tôi đã có một trang web (dựa trên Wordpress) đã không phản hồi. Tôi SSH vào máy chủ và thấy rằng chúng tôi đã hết bộ nhớ. Lỗi trong các tệp nhật ký apache của tôi chỉ ra điều tương tự ... những thứ không được phân bổ do thiếu bộ nhớ). Khởi động lại máy chủ sửa nó.

Vì vậy, tôi tìm trong access.log và error.log trong khoảng thời gian xảy ra sự cố nhưng tôi thấy không có gì lạ. Không có lưu lượng truy cập thêm, không có yêu cầu bất thường. Trong thực tế, yêu cầu duy nhất trong khoảng thời gian xảy ra sự cố là một từ Googlebot cho một nguồn cấp dữ liệu rss ... tại thời điểm đó tôi bắt đầu thấy 500 mã phản hồi trong nhật ký cho đến khi máy được khởi động lại. Tôi tìm trong message.log hy vọng sẽ thấy một cái gì đó nhưng không có gì cả trong cả ngày đó (điều này thật kỳ quặc vì có những mục cho mỗi ngày khác).

Trang web có một lượng lớn bộ nhớ được phân bổ cho nó và thường chạy bằng khoảng 30% những gì có sẵn. Câu hỏi của tôi ... làm thế nào bạn sẽ cố gắng theo dõi điều này vào thời điểm này? Một số tệp nhật ký khác tôi có thể kiểm tra hoặc chiến lược tôi có thể thực hiện là gì?

apache 

Sử dụng munin để ghi lại các thay đổi trong bộ nhớ ở dạng biểu đồ .. nó sẽ không cho bạn biết nguyên nhân gây ra sự cố nhưng nó có thể giúp xác định thời điểm của các xu hướng và tăng đột biến.
joshuahedlund

Câu trả lời:


1

Các khuyến nghị chung:

  • sử dụng plugin bộ nhớ cache để cài đặt WP của bạn
  • giảm bộ nhớ PHP_limit xuống ( 32..96M ) để bắt đầu thấy bộ nhớ PHP vượt quá lỗi
  • vô hiệu hóa các plugin vô dụng và mới
  • đảm bảo tất cả các cài đặt báo cáo được bật
  • giảm quy trình công nhân tối đa bằng tay (3..10)
  • đặt nonzero MaxRequestsPerChild nếu bạn nghĩ rằng PHP / Apache có thể bị rò rỉ (lỗi trong mã được biên dịch của trình thông dịch PHP hoặc máy chủ Apache)
  • giảm ServerLimit
  • giảm MaxClents
  • sử dụng PHP trong chế độ FPM

Lời khuyên cụ thể:

  • viết một tập lệnh bash để đo mức sử dụng bộ nhớ hoặc thu thập đỉnh và đặt nó vào cron. Bạn sẽ có số liệu thống kê cho việc sử dụng bộ nhớ của một quá trình theo thời gian.
  • hoặc sử dụng munin như giải pháp tiên tiến hơn.

0

Kiểm tra dòng wa ở trên cùng nó sẽ hiển thị nếu bạn chờ io

Nếu vậy, hãy kiểm tra nhật ký lỗi MySQL của bạn và cố gắng phân tích / sửa chữa các bảng của bạn.

Đây có thể là một vấn đề mạng hoặc lưu trữ. Trung bình chờ sẽ cho bạn biết rằng.

Hi vọng điêu nay co ich


0

Trước tiên bạn nên vô hiệu hóa tất cả các plugin của mình, sau đó khởi động lại máy chủ apache của bạn. Chạy top hoặc mtop trong terminal và xác định xem có bị rò rỉ bộ nhớ không. Nếu vậy, hãy bắt đầu kích hoạt plugin và đợi 10 - 15 phút và kiểm tra mức sử dụng bộ nhớ của bạn trên máy chủ để thử và xác định xem đó có phải là plugin không.


0

Top và PS là những công cụ rất tốt. Tôi cũng sẽ xem xét / Proc / meminfo. Bạn có thể bắt đầu Valgrind cùng với Apache để kiểm tra rò rỉ bộ nhớ. Nhưng dù sao tôi cũng không khuyên dùng Apache. Tôi có thể giới thiệu lighttpd hoặc nginx.


Bạn sẽ đề xuất gì thay vì Apache?
Lèse majesté

Chà, nếu Apache là thứ mang đến cho bạn những vấn đề, thì nginx (phát âm là "engine-x") là một lựa chọn tốt.
Matt

@Matt - Tôi luôn nghĩ đó là en-jincks, nhưng nếu bạn nói đó là engine-x ... :)
Ẩn danh

1
@Anonymous Từ wiki.nginx.org/Faq : Làm thế nào để bạn phát âm "Nginx"? Cách phát âm đúng có vẻ như: "engine-ex". (Câu hỏi tiếp theo: "Điều đó có nghĩa là gì?" - Chính xác là chúng tôi không biết.)
Lekensteyn

0

Bạn có thể sử dụng một cái gì đó như New Relic , ví dụ http://blog.newrelic.com/2010/12/16/measuring-wordpress-performance-with-new-relic-rpm/


Kịch bản này cũng tiện dụng: http://www.pixelbeat.org/scripts/ps_mem.py

Ví dụ sử dụng (lấy từ đây ):

-bash-3.2$ wget http://www.pixelbeat.org/scripts/ps_mem.py
-bash-3.2$ sudo python ps_mem.py
 Private  +   Shared  =  RAM used   Program 

 92.0 KiB +  12.0 KiB = 104.0 KiB   qmail-clean
 96.0 KiB +  14.0 KiB = 110.0 KiB   splogger
116.0 KiB +  23.0 KiB = 139.0 KiB   init
128.0 KiB +  12.0 KiB = 140.0 KiB   qmail-rspawn
124.0 KiB +  16.0 KiB = 140.0 KiB   syslogd
132.0 KiB +  12.0 KiB = 144.0 KiB   qmail-lspawn
148.0 KiB +  13.0 KiB = 161.0 KiB   qmail-send
208.0 KiB +  28.5 KiB = 236.5 KiB   dbus-daemon
232.0 KiB +  36.5 KiB = 268.5 KiB   xinetd
240.0 KiB +  32.5 KiB = 272.5 KiB   mysqld_safe
328.0 KiB +  20.5 KiB = 348.5 KiB   udevd
348.0 KiB +  66.0 KiB = 414.0 KiB   courierlogger (4)
444.0 KiB +  85.5 KiB = 529.5 KiB   bash
480.0 KiB +  50.0 KiB = 530.0 KiB   xfs
592.0 KiB +  36.0 KiB = 628.0 KiB   crond
544.0 KiB + 114.0 KiB = 658.0 KiB   couriertcpd (4)
  1.3 MiB +  82.5 KiB =   1.4 MiB   sw-cp-serverd
  1.2 MiB +   1.1 MiB =   2.3 MiB   sshd (3)
  3.1 MiB + 205.5 KiB =   3.3 MiB   named
  3.9 MiB +  48.2 MiB =  52.1 MiB   spamd (2)
 63.7 MiB + 387.0 KiB =  64.1 MiB   mysqld
108.3 MiB +   9.2 MiB = 117.5 MiB   httpd (7)
---------------------------------
                        245.4 MiB
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.