Làm thế nào tôi có thể giữ cho Apache khỏi bị ngã?


8

Tôi có một cặp máy chủ lưu trữ một trang web thương mại điện tử Magento duy nhất với lưu lượng truy cập vừa phải (60k lượt xem trang mỗi ngày được báo cáo từ Google Analytics, tôi nghĩ khoảng 80k được báo cáo trên chính máy chủ). Máy chủ cơ sở dữ liệu chạy trơn tru và nhanh chóng, ngoài một tiếng nấc thỉnh thoảng hiếm gặp, nhưng máy chủ apache thường xuyên bị đổ.

Tôi đã thiết lập magento để sử dụng bộ đệm ẩn PHP (APC) được đề xuất, cũng như giữ các tệp bộ nhớ cache của riêng nó trong một tmpfs 1,5 gig (tmpfs này thường xuyên khá đầy đủ và tôi có một đoạn script chạy để xóa các tệp bộ đệm khi tmpfs đầy đủ hơn 80%). Tôi phục vụ hầu hết các hình ảnh từ amazon cloudfront. Gần đây tôi đã thiết lập nginx như một proxy ngược cho apache (nginx cũng phục vụ các tệp tĩnh). Tôi đã cấu hình apache theo khả năng tốt nhất của mình - thủ tục lưu trữ và máy chủ lưu trữ bị tắt và prefork được cấu hình như sau:

<IfModule prefork.c>
    StartServers      50
    MinSpareServers   50
    MaxSpareServers  100
    ServerLimit  512
    MaxClients   256
    MaxRequestsPerChild 400
</IfModule>

Tôi đã không tắt các tập tin .htaccess và đăng nhập truy cập được bật. Tôi biết có một số mô-đun tôi có thể tắt. Tôi không chắc chắn bất kỳ thay đổi nào trong ba thay đổi đó sẽ có, nếu có.

Máy chủ apache là một VPS có 6 GB RAM. Tính đến thời điểm viết máy chủ đang báo cáo load average: 17.77, 18.27, 49.76, nhưng có khoảng 2 GB RAM miễn phí. Khi nó trở nên rất tệ, tải sẽ chuyển sang 120+ và vẫn ở đó - apache khởi động lại sẽ đưa trang web trở lại và tải xuống trở lại.

vmstatlà (trong khi máy chủ đang báo cáo tải ở trên), tôi nghĩ, hiển thị giá trị nhàn rỗi của CPU dao động trong khoảng từ 0 đến 70 hoặc hơn. iostatđang hiển thị giá trị iowait trong khoảng từ 0 đến 0,2%.

Tôi hơi bị mắc kẹt. Điều tôi ít biết là nói với tôi rằng vấn đề là CPU bị quá tải do sự kết hợp của mã đang được chạy và số lượng người dùng. Nhưng tôi không đủ kinh nghiệm để chắc chắn rằng đó là vấn đề. Nếu đó là vấn đề, tôi nghĩ các giải pháp là cải thiện mã hoặc phân chia trang web lưu trữ trên hai VPS bằng bộ cân bằng tải.

Vì vậy, tôi đoán câu hỏi của tôi là:

  1. Tôi có thể làm gì khác để tìm sự cố hoặc tắc nghẽn trên máy chủ?
  2. Có bất kỳ thay đổi rõ ràng nào tôi có thể thực hiện cho cấu hình máy chủ để cải thiện điều này không?
  3. Có phải là một ý tưởng tốt để thiết lập một hệ thống tự động để khởi động lại apache khi tải vượt quá một mức nhất định?
  4. Từ những điều trên, có khả năng trang web đã vượt xa máy chủ như thế nào?

Biên tập:

Tôi tìm thấy một cái gì đó kỳ lạ - / var / spool / mail / root đã lớn ... 38 gig. Nghe có vẻ ... không lành mạnh. Có thể đó là vấn đề?


2
38GB thư? Tìm hiểu những gì đang xảy ra ở đó. Và sau đó sửa nó.
Alister Bulman

2
" Làm thế nào tôi có thể giữ cho apache không bị ngã " - Đưa cho anh ta một cái chân gỗ và giữ anh ta khỏi tấm ván.
Shaz

Mailfile có thể là do đầu ra lỗi cron hoặc crontab gốc. Nếu bạn có công việc trò chuyện, họ sẽ điền vào tệp này.
Kyle Smith

1
Nó có 6 GB ram, nhưng nó có phải là hệ điều hành 64 bit không? Bạn có thực sự có thể sử dụng nhiều hơn 4gb bạn đang sử dụng không? Nếu đây là hộp quan trọng cho nhiệm vụ, thì tôi chắc chắn sẽ chạy Linux-HA và chia nó thành hai hộp chỉ cho mục đích chuyển đổi dự phòng. Tôi sẽ nghĩ rằng ông chủ của bạn sẽ không bị đánh dấu như vậy nếu bạn không tác động đến điểm mấu chốt với mỗi vụ tai nạn.
Ori

Câu trả lời:


3

Magento và Zend Framework khá nặng CPU, như bạn nhận thấy. Cách tốt nhất để tránh tải CPU chỉ đơn giản là hiển thị bất kỳ nội dung nào chỉ một lần, cho đến khi nó thay đổi. Hầu hết các phần trong danh mục của bạn không thay đổi thường xuyên và thường chỉ có khối giỏ hàng trên trang của bạn hoặc khối 'các mặt hàng phổ biến nhất' là các phần động duy nhất.

Tôi sẽ đề nghị đặt một bộ đệm Varnish trước Apache. Điều này cung cấp cho bạn bộ nhớ đệm trang hiệu suất cao có thể giảm tải nghiêm trọng ngăn xếp LAMP của bạn. Gần đây chúng tôi đã sống sót sau khi ra mắt một trang web rất công khai nhờ Varnish và tôi rất ấn tượng bởi tốc độ và tải cpu thấp. Varnish là miễn phí và đủ linh hoạt để lưu trữ toàn bộ trang hoặc chỉ lưu trữ các phần tương đối tĩnh và bao gồm cả giỏ hàng một cách linh hoạt.

Tuy nhiên, Varnish sẽ không lưu trữ nhiều bộ đệm khi cài đặt Magento mặc định, vì có rất nhiều nội dung động của mỗi người dùng, cookie, v.v. Một mô-đun Magento như ' PageCache được cung cấp bởi Varnish ' sửa đổi Magento hoạt động tốt với Varnish. Nó cũng cung cấp một tệp cấu hình Varnish phù hợp với thiết lập Magento. Cả hai cùng nhau tạo nên một thiết lập rất hiệu quả. Đó là một mô-đun thương mại, nhưng giá cả phải chăng hơn nhiều so với một máy chủ mạnh hơn.

Các phần mà bạn giảm tải cho CDN hoặc Nginx không phải là vấn đề thực sự của bạn, mặc dù nó có ích. Ngay cả Apache cũng có thể xử lý khá nhiều yêu cầu tĩnh. Bạn cần lưu trữ những thứ cần nỗ lực để tạo ra nhiều lần, tức là các phần động của bạn.


Tôi đã xem Varnish và đó có vẻ là một giải pháp tốt để giảm tải CPU, ít nhất là cho đến khi tôi có thể chuyển đến một máy chủ có thiết lập CPU tốt hơn. Cảm ơn.
Dave Child

3

Tôi thường thiết lập MaxRequestsPerChild ở mức hàng nghìn - thường là gần 10.000.

Bạn nói rằng bạn có "bộ nhớ đệm PHP được đề xuất" - nhưng bạn đã cài đặt APC chưa? Cuối cùng, có bao nhiêu người dùng bạn thấy nhấn trang web cùng một lúc. Nếu bạn có số liệu thống kê mở rộng của Apache, bạn sẽ có thể thấy có bao nhiêu quá trình Apache thực sự ở trạng thái Chạy tại một thời điểm.

800 lần truy cập tệp APC mỗi giây và 200 bộ đệm người dùng khác là rất nhiều. Nếu đó là lõi kép hoặc lõi tứ, tôi hy vọng nó sẽ tiếp tục ổn. Nếu cơ sở dữ liệu thực sự theo kịp, thì việc có được một cỗ máy lớn hơn - và nhiều CPU hơn, có thể là điều tốt nhất cho nó, ít nhất là ngay bây giờ.


Đầu tiên, cảm ơn! Tải vẫn còn khá cao, vì vậy tôi có thể thử ngay một số thứ này, điều này rất hữu ích :). Tôi đã tăng MaxRequestsPerChild lên 4000 - tải ngay lập tức và tăng rất cao. Tôi đã giảm nó xuống 1000 và tải đã giảm xuống một chút, mặc dù vẫn còn quá cao. APC được cài đặt. SHM là 256. Ghi đè bao gồm bao gồm.
Dave Child

nếu APC đã được cài đặt, báo cáo apc.php sẽ làm gì? - Tải xuống từ svn.php.net/viewvc/pecl/apc/trunk/apc.php?view=markup
Alister Bulman

Đây là đầu ra (Tôi không muốn liên kết trực tiếp đến trang web / máy chủ): dl.dropbox.com/u/16366/apc.htm
Dave Child

Xin lỗi, không nhận ra bạn đã chỉnh sửa câu trả lời của bạn. Vâng, đó là VPS lõi kép (Xeon 2.4ghz). Tôi đã nghĩ rằng máy chủ này sẽ có thể xử lý tải hiện tại của nó, đó là lý do tại sao tôi lo lắng tôi đã bỏ lỡ một cái gì đó trong cấu hình hoặc đã không phát hiện ra một nút cổ chai ở đâu đó.
Dave Child

2

Tải trung bình của bạn hoàn toàn quá cao đối với VPS lõi kép. 8 nên là tối đa.

Tôi đã thành công với việc sử dụng mod_pagespeed và MPM sự kiện cho Magento. Tôi khuyên bạn nên chuyển sang sử dụng MPM sự kiện và cài đặt mod_pagespeed.

Thông tin thêm về Sự kiện MPM: Tài liệu MPM sự kiện Apache

Và mod_pagespeed: Google Code: mod_pagespeed

Nếu bạn tiếp tục gặp sự cố tải ngay cả sau khi thực hiện các thay đổi ở trên, bạn có thể muốn xem xét chuyển sang gói VPS khác tốt hơn.


2

Như Alister gợi ý, giá trị MaxRequestsPerChild là 400 thấp một cách vô lý.

Trung bình tải rất cao - nhưng 60k lượt xem trang mỗi ngày không có nhiều lưu lượng truy cập.

bạn thường có bao nhiêu quy trình phục vụ yêu cầu?

Tôi không quen thuộc với Magento nhưng có vẻ như có gì đó không ổn với thiết lập này. Tôi hy vọng rằng bạn có thể nhận được nhiều thông lượng hơn đáng kể ở mức tải thấp hơn.

Đi lấy một bản sao của cuốn sách Steve Souder và đọc nó. Cho phép nén cho tất cả nội dung HTML đi (tĩnh và động). Và chắc chắn rằng bạn đã có một cấu hình bộ đệm tốt. Bắt đầu đăng nhập% D trong tệp access_log của bạn và xây dựng một số công cụ để phân tích dữ liệu / cách ly sự chậm chạp. Tương tự đối với MySQL.

Hãy thử mysqltuner.pl và xem nếu nó đánh dấu bất kỳ vấn đề nào.


Thông thường, một cái gì đó như 10-20 quy trình tích cực phục vụ các yêu cầu tại bất kỳ thời điểm nào. Khi tải cực kỳ cao, sau đó rất nhiều. Magento là một thứ quái vật để chạy, vì vậy trong khi tôi hy vọng các hệ thống khác sẽ ổn với lưu lượng truy cập và thiết lập này, tôi có thể tin rằng đây có thể chỉ là Magento vượt trội so với hộp. Cảm ơn vì giới thiệu quyển sách.
Dave Child

mod_pagespeed giúp Magento rất nhiều. Thử nó.
laebshade

2

Tôi chạy một thiết lập tương tự, nhưng với nginx / php-fpm / apc (opcode và fast_backend / memcached (Slow_backend). Tôi thấy php là vấn đề tài nguyên lớn nhất, có lẽ vì magento quá lớn hoặc chỉ bị mã hóa kém. nhìn vào chính xác những gì đang ăn tài nguyên, nó có thể là php như trong trường hợp của tôi không?

Ngoài những gì Martijn Heemels viết, còn có một mô-đun véc ni mã nguồn mở mà bạn có thể thử. Kiểm tra http://moprea.ro/2011/may/6/magento-performance-optimization-varnish-cache-3/https://github.com/madalinoprea/magneto-varnish .
Tôi chỉ thử nghiệm nó trong một môi trường thử nghiệm, và cho đến nay rất tốt.


Bạn có lưu phiên trong cơ sở dữ liệu hoặc trên đĩa (và nếu vậy, trên tmpfs) không?


Họ được lưu trong một tmpfs.
Dave Child

1

Khi bạn sử dụng VPS, bạn đang chia sẻ CPU. Tôi khuyên bạn nên nói chuyện với chủ nhà để chuyển VPS sang phần cứng ít bận rộn hơn hoặc dành riêng.

Do CPU được chia sẻ, các ứng dụng của bạn không thể chạy đúng giờ và liên tục bị xếp hàng xây dựng các yêu cầu cao hơn để xử lý và cả các chi phí đi kèm. Cuối cùng, có một điều kiện trong đó Apache hoặc php hoặc mysql sẽ vượt quá giới hạn của chính nó và những điều đó gây ra vấn đề.

Kết quả là. VPS về cơ bản là dùng chung CPU. Máy chủ của bạn có thể đang đặt quá nhiều tài khoản VPS trên cùng một CPU.

Nếu bạn muốn sử dụng đầy đủ CPU được phân bổ, hãy yêu cầu Máy chủ tốt hơn với ít VPS hơn nếu có thể (di chuyển máy chủ mặc dù điều đó gây phiền hà) hoặc dành riêng.

Bạn cũng có thể chọn Amazon hoàn toàn và không lo lắng về nginx bằng cách sử dụng bộ cân bằng tải của họ, một vài lần nhấp để thiết lập cho tất cả các máy chủ của bạn dưới đám mây của họ.

thư mục /var/mail.../root là màu sắc có nghĩa là nó thu thập rất nhiều email đến từ các ứng dụng của bạn thường. Ví dụ: tập lệnh php lỗi đang cố gửi email hoặc tất cả các công việc cron được cấu hình để gửi email cho bạn trạng thái của cron chạy và đầu ra. Bạn có thể nhìn vào bên trong thư và xem những gì tập tin có. Tôi đoán các thông báo lỗi của nó để bạn có thể tìm thấy nó đến từ đâu.

Tôi sẽ bổ sung thêm nếu bạn cần thêm thông tin và có thể tôi cũng sẽ cần một số thông tin

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.