Điểm:0

Máy chủ bị lỗi sử dụng bộ nhớ MySQL

lá cờ cn

Tôi chỉ muốn mở đầu điều này với thực tế là tôi chưa quen với công việc quản trị máy chủ như thế này, nhưng tôi rất quan tâm và mong muốn học hỏi. Tôi đang lưu trữ một trang WordPress nhỏ trên Digital Ocean, trang này tương đối mới và có ít hoặc không có lưu lượng truy cập. Giọt đang chạy một ngăn xếp LAMP điển hình và có bộ nhớ 1GB, theo kinh nghiệm của tôi trước đây là đủ vì tôi có xu hướng không sử dụng nhiều plugin và sử dụng các chủ đề khá nhẹ. Plugin duy nhất tôi đã cài đặt mà tôi chưa từng sử dụng trước đây là WordFence. Dù sao đi nữa, trong quá trình phát triển, thỉnh thoảng tôi gặp lỗi "Lỗi thiết lập kết nối với DB", đôi khi trang web hoàn toàn không tải và kết nối qua SSH cực kỳ chậm. Hôm nay tôi đã gặp sự cố này và sau khi sự cố tự khắc phục, tôi đã SSH vào để xem những gì tôi có thể tìm thấy. Dưới đây là những gì tôi đã có thể thu thập:

hàng đầu liên tục liệt kê mysql lên hàng đầu vì mức sử dụng của nó cao

1724 mysql 20 0 1333488 405436 0 S 0,7 40,5 0:11,53 mysqld

grep -Ei 'oom|hết bộ nhớ' /var/log/syslog

Ngày 25 tháng 1 15:18:40 droplet kernel: [599977.961722] oom_kill_ process.cold+0xb/0x10
Ngày 25 tháng 1 15:18:40 droplet kernel: [599977.961936] [ pid ] uid tgid total_vm rss pgtables_bytes hoán đổi tên oom_score_adj
Ngày 25 tháng 1 15:18:40 droplet kernel: [599977.962031] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/system.slice/mysql.service,task= mysqld,pid=31337,uid=112
Ngày 25 tháng 1 15:18:40 droplet kernel: [599977.962130] Hết bộ nhớ: Quá trình bị giết 31337 (mysqld) total-vm:1342776kB, anon-rss:439804kB, file-rss:0kB, shmem-rss:0kB, UID:112 pgtables:1264kB oom_score_adj:0
Ngày 25 tháng 1 15:18:40 hạt nhân giọt: [599978.039990] oom_reaper: quy trình đã gặt hái 31337 (mysqld), giờ là anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
Ngày 25 tháng 1 15:26:50 droplet kernel: [600468.028506] systemd đã gọi oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0
Ngày 25 tháng 1 15:26:50 droplet kernel: [600468.028534] oom_kill_ process.cold+0xb/0x10
Ngày 25 tháng 1 15:26:50 droplet kernel: [600468.028658] [ pid ] uid tgid total_vm rss pgtables_bytes hoán đổi tên oom_score_adj
Ngày 25 tháng 1 15:26:50 droplet kernel: [600468.028754] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/system.slice/mysql.service,task= mysqld,pid=67924,uid=112
Ngày 25 tháng 1 15:26:50 droplet kernel: [600468.028885] Hết bộ nhớ: Quá trình bị giết 67924 (mysqld) total-vm:1310584kB, anon-rss:385228kB, file-rss:0kB, shmem-rss:0kB, UID:112 pgtables:1132kB oom_score_adj:0
Ngày 25 tháng 1 15:26:50 hạt nhân giọt: [600468.092875] oom_reaper: quy trình đã gặt 67924 (mysqld), giờ là anon-rss:0kB, file-rss:0kB, shmem-rss:0kB

Là người mới làm quen với điều này, tôi không chắc đây có phải là vấn đề đáng lo ngại hay không (có thể là một cuộc tấn công nào đó) hay đó chỉ đơn giản là một cấu hình Cài đặt WordPress bằng một cú nhấp chuột của Digital Ocean hoặc có thể bộ nhớ 1GB không còn đủ nữa. Mọi thông tin chi tiết sẽ được đánh giá rất cao!

lá cờ ua
Có phải tất cả các thành phần trong một giọt duy nhất? Hay là MySQL trong giọt riêng của nó? Giá trị của `innodb_buffer_pool_size` là gì?
lá cờ cn
@RickJames Mọi thứ nằm trong một giọt - PHP 8.0, MySQL8, Apache2, Ubuntu20.04 và WordPress. Chạy ```mysql> SELECT @@innodb_buffer_pool_size``` đã cho tôi 134217728.
lá cờ ua
Tôi nghĩ bạn sẽ phải lấy một giọt lớn hơn. Đó là quá nhiều để vắt thành một giọt.
Điểm:0
lá cờ gp
Tim

Tôi không phải là chuyên gia về MySQL nhưng tôi đã dành một chút thời gian để giảm mức sử dụng bộ nhớ MySQL 8.0 trên máy chủ cá nhân không quan trọng mà tôi điều hành và nó hoạt động tốt. Những người khác có thể đăng câu trả lời tốt hơn - hãy cùng họ vượt qua điều này.

Tôi chạy một máy chủ AWS EC2 t3a.nano với năm phiên bản Wordpress, MySQL 8.x., PHP 7.x và một số thứ khác với RAM 512MB và 1GB hoán đổi, vì vậy 1GB là đủ cho một trang web có dung lượng thấp. Bạn có thể thêm một số không gian trao đổi nếu muốn, hệ điều hành của bạn sẽ loại bỏ dữ liệu không cần thiết để các quy trình đang chạy có thêm RAM.

Bạn cần định cấu hình MySQL để chạy với bộ nhớ hạn chế, chẳng hạn như giảm kích thước RAM, bộ đệm và tắt lược đồ hiệu suất.Giảm mức sử dụng RAM PHP cũng sẽ giúp giảm khả năng bộ nhớ bị tấn công. MySQL 8.0 vẫn sử dụng nhiều RAM hơn MySQL 5.6, mặc dù một chuyên gia có thể giảm nhiều hơn tôi.

Đây là những phần chính từ cấu hình MySQL 8 của tôi - lưu ý ở đây rằng tôi không phải là chuyên gia về MySQL và bạn nên thực hiện một số nghiên cứu để hiểu cấu hình này trước khi áp dụng nó. Một số trong số này có thể là giá trị mặc định, nhưng tôi thường đặt hầu hết các tham số gần giá trị thấp nhất cho phép của chúng.

Các tệp cấu hình của bạn có thể ở các vị trí khác nhau. Đảm bảo rằng bạn thực hiện sao lưu toàn bộ máy chủ một cách lý tưởng trước khi bắt đầu bất kỳ thay đổi nào và sao lưu các tệp của mình trước khi thay đổi chúng.

/etc/mysql/conf.d/mysql.cnf

# thiết lập toàn cầu
performance_schema = TẮT

innodb_buffer_pool_size=50M
innodb_flush_method=O_DIRECT
innodb_log_buffer_size=1048576
innodb_log_file_size=4194304
innodb_max_undo_log_size=10485760
innodb_sort_buffer_size=64K
innodb_ft_cache_size=1600000
innodb_max_undo_log_size=10485760
max_connections=20
key_buffer_size=1M

# cài đặt mỗi luồng
thread_stack=140K
thread_cache_size = 2
read_buffer_size=8200
read_rnd_buffer_size=8200
max_heap_table_size=16K
tmp_table_size=128K
temptable_max_ram=2097152
bulk_insert_buffer_size=0
tham gia_buffer_size=128
net_buffer_length=1K

/etc/mysql/mysql.conf.d/mysqld.cnf

key_buffer_size = 16M
thread_stack = 256K

Đây là một số chỉnh sửa tôi đã thực hiện với cấu hình PHP để giảm mức sử dụng RAM

/etc/php/7.4/fpm/pool.d/www.conf

pm.max_children = 3
pm.start_servers = 1
pm.min_spare_servers = 1
pm.max_spare_servers = 1
pm. process_idle_timeout = 20 giây;
pm.max_requests = 50
php_admin_value[memory_limit] = 64M

Thống kê máy chủ

Đây là một số thống kê từ lệnh 'top' của máy chủ

Tổng thể

  • Mem 448MB, 42MB trống, 190MB đã sử dụng, 216MB bộ đệm/cache
  • Swap 1024, 725MB miễn phí, 300MB đã sử dụng

quy trình

  • MySQL Virt 1459020 Res 44696 CPU 3% Mem 10%
  • PHP FPM 7.x Virt 223124 Res 32464 CPU 0% Mem 7%
  • CPU Nginx Virt 63932 Res 7520 0% Mem 2%

Đăng câu trả lời

Hầu hết mọi người không hiểu rằng việc đặt nhiều câu hỏi sẽ mở ra cơ hội học hỏi và cải thiện mối quan hệ giữa các cá nhân. Ví dụ, trong các nghiên cứu của Alison, mặc dù mọi người có thể nhớ chính xác có bao nhiêu câu hỏi đã được đặt ra trong các cuộc trò chuyện của họ, nhưng họ không trực giác nhận ra mối liên hệ giữa câu hỏi và sự yêu thích. Qua bốn nghiên cứu, trong đó những người tham gia tự tham gia vào các cuộc trò chuyện hoặc đọc bản ghi lại các cuộc trò chuyện của người khác, mọi người có xu hướng không nhận ra rằng việc đặt câu hỏi sẽ ảnh hưởng—hoặc đã ảnh hưởng—mức độ thân thiện giữa những người đối thoại.