MySql 8 gặp sự cố trên vòng lặp mà không có lỗi cụ thể và có đủ bộ nhớ

Tôi đang chạy Ubuntu 20.04.03 với Mysql 8.0.27. Tôi đã cài đặt lại LAMP từ đầu nhiều lần và hiện tại tôi chỉ có 3 trang web WordPress nhưng tôi cũng chỉ thử nghiệm 1 và chỉ 2 trang web. Tăng RAM lên 2GB và hoán đổi 3GB.

Dường như không có gì hoạt động vì Mysql 8.0.27 liên tục gặp sự cố gây ra sự cố kết nối cơ sở dữ liệu ở mọi trang web mỗi đêm ngay cả khi đây là những trang web hoàn toàn mới không có bất kỳ lưu lượng truy cập nào. Khi tôi đang chỉnh sửa một bài đăng hoặc thậm chí duyệt qua bất kỳ trang web nào trong số đó, MySql lại gặp sự cố. Đôi khi nó thậm chí sẽ không bắt đầu với systemctl khởi động lại mysql.

Nhật ký lỗi Apache không hiển thị bất cứ điều gì quan trọng:

/usr/sbin/mysqld (mysqld 8.0.27-0ubuntu0.20.04.1) bắt đầu từ quá trình 1524639

Quá trình khởi tạo InnoDB đã bắt đầu.

Quá trình khởi tạo InnoDB đã kết thúc.

Đang bắt đầu khôi phục sự cố XA... Khôi phục sự cố XA đã hoàn tất.

Phiên bản TLS không dùng nữa TLSv1 được bật cho kênh mysql_main

Phiên bản TLS không dùng nữa TLSv1.1 được bật cho kênh mysql_main

Chứng chỉ CA ca.pem tự ký.

Kênh mysql_main được định cấu hình để hỗ trợ TLS. Kết nối được mã hóa hiện được hỗ trợ cho kênh này.

X Plugin đã sẵn sàng cho các kết nối. Địa chỉ liên kết: '127.0.0.1' cổng: 33060, ổ cắm: /var/run/mysqld/mysqlx.sock

Tôi đã kiểm tra rằng trên thực tế, cấu hình đang tải tất cả các phiên bản TLS có thể chấp nhận được. Vì vậy, không có lỗi thực sự ở đó.

tạp chí -u mysql Nhật ký nhật ký cuối cùng:

Ngày 28 tháng 1 10:29:37 www.ignicion.org systemd[1]: mysql.service: Không thành công với kết quả 'tín hiệu'.
Ngày 28 tháng 1 10:29:37 www.ignicion.org systemd[1]: mysql.service: Công việc khởi động lại theo lịch trình, bộ đếm khởi động lại ở mức 5.
Ngày 28 tháng 1 10:29:37 www.ignicion.org systemd[1]: Máy chủ cộng đồng MySQL đã ngừng hoạt động.
Ngày 28 tháng 1 10:29:37 www.ignicion.org systemd[1]: Bắt đầu Máy chủ cộng đồng MySQL...
Ngày 28 tháng 1 10:29:43 www.ignicion.org systemd[1]: mysql.service: Quá trình chính đã thoát, code=killed, status=9/KILL
Ngày 28 tháng 1 10:29:43 www.ignicion.org systemd[1]: mysql.service: Không thành công với kết quả 'tín hiệu'.
Ngày 28 tháng 1 10:29:43 www.ignicion.org systemd[1]: Không thể khởi động Máy chủ cộng đồng MySQL.
Ngày 28 tháng 1 10:29:43 www.ignicion.org systemd[1]: mysql.service: Công việc khởi động lại theo lịch trình, bộ đếm khởi động lại ở mức 6.
Ngày 28 tháng 1 10:29:43 www.ignicion.org systemd[1]: Máy chủ cộng đồng MySQL đã ngừng hoạt động.
Ngày 28 tháng 1 10:29:43 www.ignicion.org systemd[1]: Bắt đầu Máy chủ cộng đồng MySQL...
Ngày 28 tháng 1 10:29:50 www.ignicion.org systemd[1]: Bắt đầu Máy chủ cộng đồng MySQL.

Tôi biết đó là vấn đề về bộ nhớ nhưng tại sao? Không giống như máy chủ đang làm rất nhiều. Tôi đã theo dõi quá trình và Mysql là thứ ngốn hết bộ nhớ. Cơ sở dữ liệu mới tương tự này đã hoạt động tốt trên Ubuntu 18, vì vậy tôi thực sự hết ý tưởng và không thể tìm ra giải pháp nào cho các vấn đề liên quan mà tôi đã tìm thấy trên diễn đàn. Một số giải pháp tôi đã tìm thấy đang nói về lỗi cơ sở dữ liệu/bảng nhưng đây là cơ sở dữ liệu hoàn toàn mới và sự cố phần cứng đã bị Bộ phận hỗ trợ của Digital Ocean loại bỏ.

Tôi sẽ đánh giá cao bất kỳ thông tin chi tiết nào

Cập nhật số 1 Không có bản sao lưu hoặc bất kỳ nhiệm vụ nào khác được lên lịch. Nó chỉ là một cài đặt hoàn toàn mới và cơ sở dữ liệu mới. Đây là tệp cấu hình của tôi trong Ubuntu 20: /etc/mysql/mysql.conf.d

[mysqld]
người dùng = mysql
địa chỉ liên kết = 127.0.0.1
địa chỉ liên kết mysqlx = 127.0.0.1
key_buffer_size = 16M
myisam-recover-options = SAO LƯU
log_error = /var/log/mysql/error.log
max_binlog_size = 100M
innodb_file_per_table = 1

Và từ tệp nhật ký Kernel của tôi (đuôi -100 /var/log/kern.log), có vẻ như SIGKILL 9 Term Kill tín hiệu signal đang giết mysql vì sử dụng quá nhiều bộ nhớ

Ngày 28 tháng 1 18:12:26 hạt nhân www: [623011.971582] oom-kill:constraint=CONSTRAINT_NONE, 
nodemask= (null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/system.slice/mysql.service,task=mysqld,pid=1669785,uid=113

Ngày 28 tháng 1 18:12:26 www kernel: [623011.971617] Hết bộ nhớ: Quá trình bị giết 166978 
5 (mysqld) tổng-vm:720836kB, anon-rss:292028kB, tệp-rss:804kB, shmem-rss:0kB, 
UID:113 pgtables:816kB oom_score_adj:0

Ngày 28 tháng 1 18:12:26 www kernel: [623012.005506] oom_reaper: quá trình đã gặt 1669785 (mysqld), giờ là anon-rss:0kB, file-rss:0kB, shmem-rss:0kB

Vì vậy, tôi đã đọc rằng tôi nên kiểm tra cấu hình bộ đệm Mysql và đó là nơi tôi đang ở hiện tại.

CẬP NHẬT #2 mèo /proc/meminfo

MemTotal: 2030808 kB
Bộ nhớ miễn phí: 54016 kB
Bộ nhớ có sẵn: 3424 kB
Bộ đệm: 240 kB
Bộ nhớ cache: 285620 kB
SwapCached: 44532 kB
Đang hoạt động: 1188660 kB
Không hoạt động: 495868 kB
Đang hoạt động (không hoạt động): 1187984 kB
Không hoạt động (không hoạt động): 495088 kB
Đang hoạt động (tệp): 676 kB
Không hoạt động (tệp): 780 kB
Không thể tránh khỏi: 19120 kB
Mlocked: 19120 kB
SwapTotal: 3145724 kB
SwapMiễn phí: 0 kB
Bẩn: 0 kB
Viết lại: 0 kB
Trang Anon: 1383352 kB
Đã ánh xạ: 284872 kB
Bộ nhớ: 276064 kB
KCó thể nhận lại: 47968 kB
Tấm: 171388 kB
SCó thể nhận lại: 47968 kB
Yêu cầu bồi thường: 123420 kB
Ngăn xếp hạt nhân: 7744 kB
Bảng trang: 59832 kB
NFS_Không ổn định: 0 kB
Thoát: 0 kB
Ghi lạiTmp: 0 kB
Giới hạn cam kết: 4161128 kB
Đã cam kết_AS: 9186644 kB
VmallocTổng: 34359738367 kB
VmallocĐã sử dụng: 16512 kB
VmallocChunk: 0 kB
Bộ xử lý: 1808 kB
Phần cứng bị hỏng: 0 kB
AnonHugePages: 0 kB
ShmemHugeTrang: 0 kB
ShmemPmdMapped: 0 kB
FileHugePages: 0 kB
TệpPmdMapped: 0 kB
CmaTổng: 0 kB
CmaMiễn phí: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Kích thước trang lớn: 2048 kB
Hugetlb: 0 kB
DirectMap4k: 1335276 kB
DirectMap2M: 761856 kB

ps -aux --sort -rss|đầu -5

USER PID %CPU %MEM VSZ RSS TTY STAT THỜI GIAN BẮT ĐẦU LỆNH
mysql 1715614 6.7 18.8 1763392 383344? SSL 22:21 0:01 /usr/sbin/mysqld
aceitep+ 1686006 0.0 2.0 342620 41076 ? 19:44 0:02 /bin/php-cgi7.4
aceitep+ 1686009 0.0 1.9 265576 39268 ? 19:44 0:02 /bin/php-cgi7.4
aceitep+ 1686001 0.0 1.8 342152 38348 ? 19:44 0:04 /bin/php-cgi7.4

Và vì tôi nghĩ rằng nó có liên quan đến một số biến mysql nên tôi đã chạy MySql Tunner và đây là khuyến nghị:

Các biến để điều chỉnh:
    innodb_buffer_pool_size (>= 391,3M) nếu có thể.
    innodb_log_file_size phải là (=16M) nếu có thể, do đó, tổng kích thước tệp nhật ký của InnoDB bằng 25% kích thước nhóm bộ đệm.

Vì vậy, tôi sẽ kiểm tra để tăng điều này và sẽ đăng kết quả.

CẬP NHẬT #3 Thêm innodb_buffer_pool_size = 512M với tôi /etc/mysql/mysql.conf.d/mysqld.cnf tập tin và vẫn bị lỗi. Nhật ký vẫn như cũ. :(

Có bình thường không khi Tổng bộ nhớ lớn của tôi được phân bổ bằng 0 khi tôi chạy Show Trạng thái InnoDB của động cơ;

----------------------
BỘ ĐỆM POOL VÀ BỘ NHỚ
----------------------
**Tổng bộ nhớ lớn được phân bổ 0**
Bộ nhớ từ điển được phân bổ 1009720
Kích thước vùng đệm 32765
Bộ đệm miễn phí 29298
Trang cơ sở dữ liệu 3405
Cơ sở dữ liệu cũ trang 1276
Trang db đã sửa đổi 0

Và những gì về khi tôi chạy chương trình các biến như 'innodb_%';

innodb_buffer_pool_size | 536870912
innodb_change_buffer_max_size | 25

Tại sao kích thước vùng đệm không khớp và điều này là gì innodb_change_buffer_max_size có nghĩa là gì? Tôi nên kiểm tra những biến nào khác? Cảm ơn các bạn một lần nữa

Vâng. Giải quyết ngay bây giờ. Không có giải pháp cụ thể nào cho loại hành vi này vì kernel đang giết mysql do sử dụng quá nhiều RAM và khi bạn cố gắng tìm lý do tại sao, không có lý do cụ thể nào. Vì vậy, điều duy nhất bạn có thể làm là thử chơi với các biến và thử nghiệm thật nhiều. Những gì tôi học được:

• Theo kinh nghiệm ngắn của tôi, tôi không biết rằng tệp cấu hình Myslq (/etc/mysql/mysql.conf.d/mysqlconf.d trên Ubuntu 20.04) không hiển thị nhiều biến trên đó vì các biến này được đặt theo mặc định, vì vậy nếu chúng tôi muốn đặt một giá trị khác, chúng ta phải thêm thủ công từng biến trên tệp cấu hình.

• Cài đặt và chạy bộ điều chỉnh mysql (google nó) để nó có thể chỉ ra nơi bắt đầu cho các cài đặt cụ thể của bạn. Trong trường hợp của tôi, đề xuất tăng innodb_buffer_pool_size. Và giá trị innodb_log_file_size phải bằng 25% giá trị innodb_buffer_pool_size để có hiệu suất tối ưu. ví dụ: innodb_buffer_pool_size = 1Gb innodb_log_file_size = 0,25Gb

• Tôi đặt innodb_buffer_pool_size = 512M vì tôi có 2GB RAM. Điều này chỉ làm cho máy chủ tồn tại lâu hơn một chút trước khi gặp sự cố lần nữa. Vì vậy, đó là nơi bạn phải bắt đầu tìm hiểu thêm về từng biến Mysql và tính toán tùy thuộc vào kích thước cơ sở dữ liệu của bạn.

Đây là tệp cấu hình Mysql cuối cùng của tôi để bạn có thể dùng thử cấu hình này. Chỉ cần biết rằng kích thước cơ sở dữ liệu của tôi hiện tại là 394 MB:

[mysqld]
bỏ qua đăng nhập
người dùng = mysql
địa chỉ liên kết = 127.0.0.1
địa chỉ liên kết mysqlx = 127.0.0.1
myisam-recover-options = SAO LƯU
log_error = /var/log/mysql/error.log
chung_log = trên
general_log_file=/var/log/mysql/General.log

key_buffer_size = 1M
max_allowed_packet = 1M
thread_stack = 200K
thread_cache_size = 8
max_connect_errors = 100
max_connections = 100
#table_cache = 64
#thread_concurrency = 30
binlog_cache_size = 1M
net_buffer_length = 1 triệu

default_storage_engine = InnoDB
innodb_buffer_pool_instances = 1 # Sử dụng 1 phiên bản trên 1GB kích thước nhóm InnoDB
innodb_buffer_pool_size = 400M # Sử dụng tới 70-80% RAM
innodb_file_per_table = 1
innodb_flush_log_at_trx_commit = 0
innodb_flush_method = O_DIRECT
innodb_log_buffer_size = 16 triệu
innodb_log_file_size = 16 triệu
innodb_stats_on_metadata = 0
#innodb_thread_concurrency = 0
innodb_read_io_threads = 40
innodb_write_io_threads = 40
innodb_buffer_pool_chunk_size = 10
innodb_lock_wait_timeout = 600
innodb_flush_log_at_trx_commit = 1
innodb_io_abilities = 3000
innodb_io_capital_max = 4000
innodb_buffer_pool_dump_pct = 80
innodb_flush_neighbor = 0
innodb_doublewrite = 0
innodb_change_buffer_max_size = 10
innodb_old_blocks_pct = 70
innodb_old_blocks_time = 5000
innodb_use_native_aio = BẬT

# Số giây mà máy chủ chờ hoạt động trên một kết nối tương tác trước khi đóng nó.
Interactive_timeout = 600

# Số giây máy chủ chờ hoạt động trên kết nối không tương tác trước khi đóng nó.
chờ_thời gian chờ = 600
net_read_timeout = 300
net_write_timeout = 300
connect_timeout = 1800

# Cài đặt bảng
table_definition_cache = 1K
table_open_cache = 2K
table_open_cache = 2K
open_files_limit = 4000

max_heap_table_size = 100M
tmp_table_size = 100 triệu

#
# * Cấu hình bộ đệm truy vấn
#
#query_cache_limit = 1M
#query_cache_size = 100M
#query_cache_size = 0
#query_cache_type = 0



# Cài đặt bộ đệm
tham gia_buffer_size = 256K
read_buffer_size = 256K
read_rnd_buffer_size = 256K
sort_buffer_size = 128K
performance_schema = BẬT

Nếu kích thước cơ sở dữ liệu của tôi tăng theo thời gian (chắc chắn chúng sẽ tăng), tôi sẽ phải tăng các giá trị này:

key_buffer_size = 1M
max_connections = 100
innodb_buffer_pool_size = 400M
tham gia_buffer_size = 256K
read_buffer_size = 256K
read_rnd_buffer_size = 256K
sort_buffer_size = 128K

Tôi có thể tăng innodb_buffer_pool_size lên 1Gb nhưng điều đó có nghĩa là tôi sẽ phải giảm các biến khác và kiểm tra lại để kiểm tra cài đặt hiệu suất tốt nhất. (tôi đã nói thế nào, nếu bạn không biết, cần phải nghiên cứu nhiều về các biến này) Mặt khác, tôi chỉ có thể để các giá trị này giống nhau ngay cả khi cơ sở dữ liệu của tôi tăng theo thời gian nhưng Mysql sẽ bắt đầu chiếm nhiều bộ nhớ Swamp hơn nên các truy vấn sẽ chậm hơn một chút theo thời gian.

Và một lần nữa, bạn chỉ có thể tăng RAM trên máy chủ của mình nếu bạn có đủ khả năng.

Hy vọng điều này sẽ giúp bất cứ ai.Tôi chưa có kinh nghiệm nên tôi cũng đăng câu trả lời này để tham khảo về tương lai của mình :)