Chúng ta có cần phân vùng Hoán đổi trên máy chủ LAMP không?


14

Chúng ta có thực sự cần trao đổi phân vùng trên máy chủ ubfox với LAMP không? Tôi nghĩ rằng tôi không cần nó, nhưng tốt hơn là biết chắc chắn nếu nó sẽ không gây ra một số hành vi không dự đoán được.
Thật ra suy nghĩ của tôi là:

  • Máy chủ không bao giờ ngủ đông
  • Nếu nó đang hoán đổi, người ta cần nghĩ về cân bằng tải / định hình lưu lượng, v.v ...

Tôi có đúng không, tôi có thể tắt trao đổi cho máy chủ sản xuất không?

Cảm ơn!

Câu trả lời:


14

Tôi có đúng không, tôi có thể tắt trao đổi cho máy chủ sản xuất không?

Không. Luôn có một số không gian hoán đổi.

Tôi đã thử chạy một máy chủ sản xuất mà không trao đổi một lần và khoảng một tuần sau, sau khi cập nhật Wordpress, PHP bắt đầu ăn nhiều RAM hơn chúng ta đã tính. Khi bạn hết RAM và bạn đã bật tính năng trao đổi, mọi thứ sẽ chậm lại (đôi khi rất nhiều, đôi khi chỉ một chút, tùy thuộc vào những gì bị đẩy vào đó) nhưng bạn có thể đăng nhập, tìm sự cố và cố gắng khắc phục nó

Khi bạn hết RAM và không có trao đổi, quá trình sẽ chết, mọi thứ bị đình trệ và rất nhiều thời gian, lựa chọn duy nhất của bạn là khởi động lại. Nhưng cho đến khi bạn làm điều đó khởi động lại, mọi thứ có thể sẽ phá vỡ.

Trong thế giới của tôi, tan vỡ là tồi tệ hơn nhiều so với chậm.

Tất nhiên, nếu bạn thấy hệ thống của mình liên tục sử dụng các phần trao đổi lớn (nó sẽ thường sử dụng một số thứ giống như cách di chuyển các thứ đã lưu trong bộ nhớ cache cũ), rõ ràng bạn có một vấn đề ("xin vui lòng chèn RAM"), nhưng có nó như là một mạng lưới an toàn chắc chắn được khuyến khích.


Đáp lại bình luận từ SpamapS:

Trong thế giới của "các trang web thành công", bạn có các lỗi dự phòng nóng, cân bằng tải và các công cụ khác cho phép máy phát nổ và không ảnh hưởng đến phần còn lại của trang web. Nhưng điều đó cần rất nhiều tiền mặt. Có phần cứng dự phòng không phải là kinh tế cho hầu hết các trang web, ngay cả khi họ kiếm được tiền.

Tôi hoàn toàn không đồng ý với nhận xét của bạn về thời gian hoạt động. Trong thiết lập thương mại điện tử truyền thống nếu mọi người không thể nhìn thấy trang web của bạn, họ không thể mua hàng của bạn. Đây không chỉ là thương mại điện tử, tất cả các lợi ích thương mại trực tuyến sẽ mất nhiều thời gian hơn nếu bạn thất vọng trong bất kỳ giai đoạn nào. Tôi biết vì tôi lưu trữ các trang web và dịch vụ cho các công ty và điều hành các trang web của riêng tôi. Chậm = gắt gỏng nhưng Xuống = giận dữ. Ngay cả khi bạn chỉ xuống một phút một lần, nếu người dùng thấy thông báo "không bảo trì" nhiều hơn một vài lần, họ cho rằng bạn không thể duy trì trang web.

Một máy chủ chậm không phải là lý tưởng nhưng trao đổi không phải lúc nào cũng được chạy, đó là biện pháp cuối cùng để cho phép mọi thứ tiếp tục chạy trong khi bạn sửa chúng.

Bạn cũng cho rằng chỉ có một dịch vụ chạy trên máy. Một lần nữa điều này có thể đúng nếu bạn có megabucks để phân chia mọi thứ nhưng trong thế giới thực, mọi thứ lại được gộp lại với nhau. Nhiều trang web, ssh daemon, máy chủ ftp, máy chủ email, v.v ... Một quá trình rò rỉ vào trao đổi thậm chí có thể không ảnh hưởng đến dịch vụ khác. Không có trao đổi, mọi thứ đều có cơ hội chấm dứt ngẫu nhiên, tức thời. Bạn không có quyền kiểm soát nó.

Tất nhiên trao đổi không phải là câu trả lời duy nhất. Bạn cần theo dõi để cảnh báo bạn khi bạn hết ram, nhưng chỉ cần rút phích cắm và khởi động lại không phải là câu trả lời cho phần lớn mọi người. Tôi chắc chắn rằng điều này hoạt động cho bất kỳ trang web đa quốc gia nào mà bạn chịu trách nhiệm nhưng đối với chúng tôi chỉ là những người phàm trần (chiếm phần lớn internet), thì đó là tự sát thương mại.


Những trải nghiệm tương tự ở đây, hơi ... đó là một sai lầm ở phía tôi không phải là một quyết định có chủ ý. Một máy chủ không có trao đổi là một địa ngục để sửa chữa, đặc biệt nếu nó quyết định giết sshd.
Javier Rivera

Tôi có RAM khoảng 16Gb, một nửa trong số đó được lưu trữ cho IO nhanh, phần còn lại dành cho LAMP, Trao đổi luôn miễn phí hoặc đôi khi có vài megs ở đó, nhưng tôi nghĩ nó luôn tắt ...
Arman

3
Trong thế giới của các trang web thành công, không phản hồi là tồi tệ hơn bị hỏng. Người dùng thực sự sẽ đánh giá cao một thất bại NHANH CHÓNG (trong đó, mã giao diện javascript của bạn sẽ được xử lý một cách duyên dáng btw), nhưng họ sẽ ghét bạn vì chậm. Bỏ việc trao đổi, nó chỉ trì hoãn là không thể tránh khỏi. -1
SpamapS

1
@Oli: Chạy N + 1 không còn mất megabucks, hoặc thậm chí rất nhiều tiền. Trong thực tế, nó hầu như không có kỹ năng đặc biệt. Không thể tránh khỏi việc một máy chủ sẽ ngừng hoạt động vì bất kỳ lý do nào, và không khó để ngăn chặn điều này không phải là vấn đề. Nếu bạn có một máy chủ LAMP độc lập làm mọi thứ, thì chi phí sẽ cao hơn; Thiết lập thêm hai và một bộ cân bằng tải (trên EC2 với ảnh chụp nhanh t1.micros và EBS, đây có thể là RẤT rẻ), hoặc trang web của bạn bị chậm một cách bất thường trong ngày trọng đại nhất của nó? Kiểm tra dữ liệu từ google ... Tôi nghĩ rằng bit
SpamapS

1
Câu trả lời tuyệt vời, bao gồm các trường hợp máy chủ trong thế giới thực. Thêm phần cứng dự phòng, LB, giám sát, bộ nhớ RAM, v.v ... đều cực kỳ quan trọng và bạn sẽ có thời gian để thiết lập và gỡ lỗi chúng nếu bạn không làm phiền vì bạn đã hết tiền trên không gian trao đổi.
ImaginaryRobots

4

Tôi phải không đồng ý với việc trao đổi trên các máy chủ sản xuất.

Theo kinh nghiệm của tôi, trao đổi đĩa quay làm cho hệ thống của bạn ít dự đoán hơn và dễ gây ra sự thất vọng cho toàn bộ hệ thống. Một máy chủ phổ biến, tải cao, đang làm bất cứ điều gì với một đĩa chậm cục bộ sẽ nhanh chóng chuyển thành một thứ tồi tệ hơn nhiều so với trạng thái thất bại. Thời gian phản hồi sẽ tăng lên 100 lần mức bình thường của họ và những việc đơn giản như đăng nhập qua bảng điều khiển hoặc ssh có thể mất vài phút.

Trao đổi SSD là một trường hợp đặc biệt và ít nhất sẽ loại bỏ thời gian tìm kiếm chậm lại thường giết chết hệ thống. Tuy nhiên, việc viết vẫn còn chậm, vì vậy bạn vẫn sẽ chờ đợi một thời gian dài để hồi phục sau quá trình mất kiểm soát.

Nếu không trao đổi, máy chủ LAMP của bạn sẽ đơn giản tiêu diệt các tiến trình để giải phóng RAM. Giám sát đúng cách sẽ cảnh báo bạn về điều này và loại bỏ các máy chủ khỏi sản xuất nếu các quy trình quan trọng bị giết. Trường hợp xấu nhất ở đây là các phương thức đăng nhập của bạn đều bị tắt và bạn phải thực hiện một chu trình thiết lập lại / cấp điện cứng. Trường hợp xấu nhất này vẫn có khả năng xảy ra với một máy đổi chỗ ngoài tầm kiểm soát, nhưng khó phát hiện hơn nhiều.

Nếu bạn đang sử dụng PHP, hãy bật giới hạn bộ nhớ và theo dõi nhật ký của bạn để biết các lỗi của chúng. Đây là một mẹo, đặt giới hạn thấp hơn trên máy chủ dev của bạn so với trong sản xuất. Nếu bạn đang sử dụng mod_php trong apache, hãy đặt MaxRequestsPerChild thành vài nghìn, để httpd chết trước khi tăng quá lớn theo thời gian. Trên hết, theo dõi việc sử dụng bộ nhớ! Thường thì bộ nhớ tăng lên theo thời gian và bạn chỉ cần khởi động lại dịch vụ bị rò rỉ định kỳ trong khi bạn gỡ lỗi.


1
Cảm ơn vì đã chia sẽ kinh nghiệm của bạn. Tôi đã hạch toán với các vấn đề tương tự, khi ssh đang dùng Inf. Tôi chỉ buộc các tiến trình có bộ nhớ hạn chế, điều đó cho phép tôi chạy ssh và sửa các tập lệnh lỗi.
Arman

Một trong những cuộc thảo luận thú vị nhất về không gian hoán đổi trong sản xuất mà tôi đã thấy trên internet. (toàn bộ chủ đề, pro & cons)
dpb 18/12/13

3

Không gian hoán đổi được sử dụng khi hệ thống của bạn quyết định rằng nó cần bộ nhớ vật lý cho các quy trình hoạt động và không có đủ bộ nhớ vật lý không sử dụng. Nếu hệ thống tình cờ cần thêm tài nguyên bộ nhớ hoặc dung lượng bộ nhớ, các trang không hoạt động trong bộ nhớ vật lý sẽ được chuyển sang không gian hoán đổi do đó giải phóng bộ nhớ vật lý đó cho các mục đích sử dụng khác.

Tình trạng này sẽ xảy ra nhiều lần trong máy chủ.

a). Một tập lệnh không được tối ưu hóa có thể tiêu thụ một lượng lớn bộ nhớ
b). Các tập lệnh như sao lưu sẽ luôn tiêu thụ bộ nhớ lớn
c). nhiều xe cộ lưu thông

Vì vậy, đó là một thực hành tốt để có một số không gian trao đổi.

Thêm chi tiết: https://help.ubfox.com/community/SwapFaq


Cám ơn vì sự giải thích. Nếu ai đó có một tập lệnh lỗi thì trong mọi trường hợp bạn sẽ làm sập máy chủ, các giới hạn hệ thống sẽ kiểm soát các tập lệnh của bạn, phải không?
Arman

aneeshep, nếu bạn trao đổi trong khi lưu lượng truy cập lớn, hệ thống của bạn sẽ chậm hơn 100 lần so với bình thường. Đó thường không được chấp nhận.
SpamapS

2

Sử dụng trao đổi sẽ cung cấp cho bạn một biện pháp bảo vệ bổ sung chống lại sự mất ổn định của máy chủ. Cũng có thể có lúc RAM hết và trên máy chủ không có trao đổi có thể dẫn đến sự cố mềm.

Bây giờ tôi có thể là thiểu số khi tôi nói, nó vẫn có ý nghĩa, như họ đã từng đề nghị, có số lượng trao đổi gấp đôi so với bạn có bộ nhớ chính. Ngay cả trên một hệ thống có 96GB RAM.

Nó không tốn nhiều tiền và, nếu bạn cần nó một ngày, bạn sẽ rất vui vì bạn đã nhận được nó. Lý do cho phép hoán đổi chỉ là một phân tích lợi ích chi phí rất đơn giản. Làm đi! :-)


0

Tôi muốn cảm ơn Oli vì câu trả lời đẹp - tôi biết cũ -. Tôi thấy phân vùng là một chủ đề luôn luôn xanh! Tôi hoàn toàn đồng ý với dòng bài đăng của Oli và tôi muốn chia sẻ điều này - tất nhiên là có thể điều chỉnh được - kịch bản tôi sử dụng để theo dõi việc sử dụng trao đổi máy chủ của mình.

Tôi luôn cấu hình máy chủ và dịch vụ để hoạt động mà không xảy ra trao đổi. Khi đó, chắc chắn rằng có điều gì đó không ổn, hoặc tốt nhất, một cái gì đó đang vượt qua kế hoạch ban đầu của bạn.

Tôi crontab kịch bản này cứ sau nửa giờ trong môi trường sản xuất. Nó sẽ gửi cho tôi một thông báo nếu sử dụng Hoán đổi! = 0k. Tôi sẽ có thể nhanh chóng điều tra / thực hiện các hành động về vấn đề này, hầu hết các lần, trước khi mọi thứ thực sự sai .

Yêu cầu bạn có: bash, top, echo, awk và một lệnh mail hoạt động, mà không thực hiện bất kỳ kiểm tra nào.

Mong rằng sẽ giúp.

#!/bin/bash
CURRSWAP=$(top -b -n1 |grep Swap |awk '{print $4}')
ECOMM="echo $CURRSWAP means healthy, I wont take any action."
CURRDATE=$(date)
MAILDST="your@email.addr"

case $CURRSWAP in
  [0]k) $ECOMM
        exit 0
        ;;
  *)    echo -e "Server: $HOSTNAME \n Date: $CURRDATE \n Current Swap partition usage: $CURRSWAP" | mail -s "Warning from $HOSTNAME" -- $MAILDST
        exit 0
        ;;
esac
exit 0
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.