Tôi có một máy chủ sản xuất, dưới đây:

Hệ thống đang sử dụng 1GB trao đổi, trong khi vẫn duy trì gần 40 GB dung lượng bộ nhớ trống, không sử dụng. Tôi có nên lo lắng về điều này, hay nó hầu như là bình thường?

Đây không phải là một vấn đề và có khả năng là bình thường. Rất nhiều mã (và có thể là dữ liệu) rất hiếm khi được sử dụng vì vậy hệ thống sẽ trao đổi nó để giải phóng bộ nhớ.

Trao đổi chủ yếu chỉ là một vấn đề nếu bộ nhớ được trao đổi liên tục. Đó là loại hoạt động giết chết hiệu suất và gợi ý một vấn đề ở nơi khác trên hệ thống.

Nếu bạn muốn theo dõi hoạt động trao đổi của mình, bạn có thể với một số tiện ích nhưng vmstatthường khá hữu ích, vd

$ vmstat 1
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0      0 348256  73540 274600    0    0     1     9    9    6  2  0 98  0  0
 0  0      0 348240  73544 274620    0    0     0    16   28   26  0  0 100  0  0
 0  0      0 348240  73544 274620    0    0     0     0   29   33  0  0 100  0  0
 0  0      0 348240  73544 274620    0    0     0     0   21   23  0  0 100  0  0
 0  0      0 348240  73544 274620    0    0     0     0   24   26  0  0 100  0  0
 0  0      0 348240  73544 274620    0    0     0     0   23   23  0  0 100  0  0

Bỏ qua dòng đầu tiên vì đó là hoạt động kể từ khi hệ thống bắt đầu. Lưu ý sivà socác cột dưới ---swap--; nhìn chung chúng phải là những con số khá nhỏ nếu không phải là 0 trong phần lớn thời gian.

Một điều đáng nói nữa là sự hoán đổi ưu tiên này có thể được kiểm soát bằng cài đặt kernel. Tệp tại /proc/sys/vm/swappinesschứa một số từ 0 đến 100 cho biết hạt nhân có thể trao đổi bộ nhớ mạnh như thế nào. Cat tập tin để xem những gì được thiết lập. Theo mặc định, hầu hết các bản phân phối Linux mặc định là 60, nhưng nếu bạn không muốn thấy bất kỳ sự hoán đổi nào trước khi hết bộ nhớ, hãy lặp lại 0 vào tệp như thế này:

echo 0 >/proc/sys/vm/swappiness

Điều này có thể được thực hiện vĩnh viễn bằng cách thêm

vm.swappiness = 0

để /etc/sysctl.conf.

Linux sẽ viết trước các trang ra đĩa nếu không có gì tốt hơn để làm. Điều đó không có nghĩa là nó sẽ đuổi những trang đó ra khỏi bộ nhớ. Chỉ là trong trường hợp nó phải đuổi những trang đó vào lúc nào đó trong tương lai, thì không cần phải đợi chúng được ghi vào đĩa, bởi vì chúng đã ở đó.

Rốt cuộc, lý do bạn sắp hết bộ nhớ, có lẽ là do máy của bạn đã làm việc rất chăm chỉ, bạn không muốn thêm gánh nặng cho nó bằng cách tráo đổi. Tốt hơn để thực hiện trao đổi khi máy không làm gì.

Vì một lý do tương tự, bộ nhớ của bạn phải luôn đầy. Các trang bộ nhớ, bộ đệm hệ thống tập tin tmpfs, có quá nhiều thứ có thể được giữ trong bộ nhớ. Thực sự, bạn nên quan tâm nếu bộ nhớ của bạn trống rỗng; Rốt cuộc, bạn đã trả rất nhiều tiền cho nó (ít nhất là so với cùng một dung lượng đĩa), vì vậy nó được sử dụng tốt hơn!

Hoán đổi được sử dụng không phải là xấu, nhưng rất nhiều hoạt động trao đổi là

  vmstat 1
  procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
  6  0 521040 114564   6688 377308    8   13   639   173    0 1100  5  4 90  0
  1  0 521040 114964   6688 377448    0    0   256     0    0 1826  3  4 94  0
  0  0 521040 115956   6688 377448    0    0     0     0    0 1182  7  3 90  0
  0  0 521036 115992   6688 377448    4    0    16     0    0 1154 10  2 88  0
  3  0 521036 114628   6696 377640    0    0   928   224    0 1503 15 17 67  1

Việc hoán đổi cột không có vấn đề gì cả. Giá trị khác không trên các cột si và do đó gây tử vong cho hiệu suất máy chủ. Đặc biệt là những người có nhiều RAM.

Cách tốt nhất là tắt tính năng hoán đổi trên các máy có nhiều GB ram:

sysctl -w vm.swappiness=0

Điều này sẽ không vô hiệu hóa trao đổi. Nó sẽ chỉ hướng dẫn Linux sử dụng trao đổi như là biện pháp cuối cùng. Điều này sẽ lãng phí một vài MB chương trình không cần trong RAM ... Nhưng tốt nhất là nên trao đổi hàng đợi truy cập ổ đĩa của bạn.

Chỉnh sửa 1: tại sao giá trị mặc định của swappiness không tối ưu

Chúng ta phải nhớ hai thập kỷ trước, một chiếc 486 lớn chỉ có 32Mb RAM. Các thuật toán hoán đổi được phát triển khi toàn bộ RAM có thể được chuyển sang đĩa trong một phần nhỏ của giây. Ngay cả với các đĩa chậm hơn thời gian đó. Đó là lý do tại sao các chính sách hoán đổi mặc định rất tích cực. RAM là nút cổ chai những ngày đó. Kể từ đó, kích thước RAM tăng hơn 10.000 lần và tốc độ ổ đĩa dưới 10 lần. Điều này đã thay đổi nút cổ chai sang băng thông đĩa.

Chỉnh sửa 2: tại sao si hoạt động gây chết người cho máy chủ?

Si và vì vậy hoạt động trên các máy có hàng tấn RAM gây chết người vì có nghĩa là hệ thống đang tự chiến đấu với RAM. Điều gì xảy ra là các đĩa, thậm chí các kho lớn quá chậm khi so sánh với RAM. Trao đổi tích cực ủng hộ bộ đệm đĩa nhân trên dữ liệu ứng dụng và là nguồn chiến đấu phổ biến nhất cho RAM. Vì HĐH sẽ phải giải phóng bộ nhớ cache trên mỗi si , thời gian tồn tại của bộ đệm bổ sung mà trao đổi cung cấp quá thấp để có thể trở nên hữu ích. Kết quả là bạn đang lấy băng thông đĩa để lưu trữ bộ đệm có thể sẽ không được sử dụng và tạm dừng các chương trình của bạn để chờ các trang si . Có nghĩa là tiêu thụ nhiều tài nguyên quan trọng với rất ít hoặc không có lợi cho các ứng dụng.

Lưu ý tiêu đề của phản hồi "rất nhiều hoạt động trao đổi trên các máy chủ có nhiều RAM". Điều này không áp dụng cho các máy có si thường xuyên và hoạt động như vậy. Điều này có thể không áp dụng trong tương lai nếu các thuật toán trao đổi thông minh hơn được phát triển trong các HĐH.

Chỉnh sửa 3: trang "lạnh"

Mọi người lãng mạn hóa thuật toán hoán đổi. Một số người nói "nó chiếm ít trang sử dụng RAM hơn", nhưng đây không phải là điều mà kernel làm. Điều khó hiểu về trao đổi là kernel không biết "trang lạnh" là gì. Hạt nhân không có số liệu tốt để xác định xem trang được sử dụng hay có khả năng được sử dụng trong tương lai gần. Để phá vỡ rằng kernel đặt các trang trong trao đổi ngẫu nhiên nhiều hơn hoặc ít hơn và các trang không cần thiết vẫn ở đó. Vấn đề của thuật toán đó là các trang cần phải đi đến trao đổi để biết liệu chúng có cần thiết cho các ứng dụng hay không. Và điều này có nghĩa là rất nhiều trang "nóng" sẽ được trao đổi. Vấn đề với đó là đĩa quá chậm so với RAM.

Tôi đã xây dựng điểm chuẩn của riêng mình, đó là một kịch bản thực tế rất phổ biến đối với nhiều ứng dụng có khối lượng khá. Từ các thử nghiệm của tôi, tôi thấy không có lợi ích nào về thông lượng hoặc độ trễ khi hoán đổi được sử dụng. Cách xa nó. Khi hoán đổi bắt đầu, nó làm chậm cả thông lượng và độ trễ ít nhất là một độ lớn.

Tôi đi xa hơn một chút về điều này: Tôi hiểu trao đổi không phải để xử lý. Hoán đổi chỉ dành cho trường hợp khẩn cấp. Những khoảnh khắc khi có quá nhiều ứng dụng đang chạy cùng một lúc và bạn sẽ tăng bộ nhớ. Nếu không trao đổi, điều này sẽ gây ra lỗi hết bộ nhớ. Tôi coi việc sử dụng trao đổi là một thất bại của các nhóm phát triển và sản xuất. Đây chỉ là một ý kiến ​​vượt xa những gì chúng ta đã thảo luận ở đây, nhưng là những gì tôi nghĩ. Tất nhiên các ứng dụng của tôi có quản lý bộ nhớ tuyệt vời của chính họ.

Đây không phải là một câu trả lời cho câu hỏi của bạn; nhưng đúng hơn, chỉ cần thêm thông tin để giúp bạn đưa ra quyết định sáng suốt.

Nếu bạn muốn biết các quy trình cụ thể đang sử dụng bao nhiêu trao đổi, thì đây là một tập lệnh shell nhỏ:

#!/bin/bash

set -o posix
set -u

OVERALL=0
for DIR in `find /proc/ -maxdepth 1 -type d -regex "^/proc/[0-9]+"` ; do
  PID=`echo $DIR | cut -d / -f 3`
  PROGNAME=`ps -p $PID -o comm --no-headers`

  SUM=0
  for SWAP in `grep Swap $DIR/smaps 2>/dev/null| awk '{ print $2 }'` ; do
    let SUM=$SUM+$SWAP
  done
  echo "PID=$PID - Swap used: $SUM - ($PROGNAME )"

  let OVERALL=$OVERALL+$SUM
done
echo "Overall swap used: $OVERALL"

Tôi cũng nên thêm rằng tmpfs cũng sẽ trao đổi. Điều này phổ biến hơn trên các hệ thống linux hiện đại sử dụng systemd tạo lớp phủ không gian người dùng / tmp bằng tmpfs.

Tôi đã nhận thấy sao chép cụm MySQL chậm hoặc thất bại khi các tác nhân hoán đổi mạnh. Có thể một số ứng dụng không bận tâm hoặc thậm chí có thể được hưởng lợi từ một số trao đổi nhưng cơ sở dữ liệu thực sự có vẻ bị ảnh hưởng bởi nó. Tuy nhiên, nhiều cuộc thảo luận tôi đã thấy trên các diễn đàn thảo luận về trao đổi được giải mã từ các cuộc thảo luận về tải công việc cụ thể.

Trong thế giới DBA, sự đồng thuận dường như là "Điều thông thường là khi bạn chạy MySQL (hoặc thực sự là bất kỳ DBMS nào khác), bạn không muốn thấy bất kỳ I / O nào trong không gian trao đổi của mình. Thu nhỏ kích thước bộ đệm (sử dụng innodb_buffer_pool_size trong trường hợp của MySQL) là thông lệ tiêu chuẩn để đảm bảo có đủ bộ nhớ trống nên không cần trao đổi.

Nhưng nếu bạn mắc một số sai lầm hoặc tính toán sai, và hoán đổi xảy ra thì sao? Nó thực sự ảnh hưởng đến hiệu suất bao nhiêu? Đây chính xác là những gì tôi đặt ra để điều tra. "

Tôi hy vọng độc giả sẽ tìm thấy các liên kết apropos sau đây.

https://www.percona.com/blog/2017/01/13/impact-of-swicking-on-mysql-performance/

https://www.percona.com/blog/2010/01/18/why-swicking-is-bad-for-mysql-performance/