Mysql
MySQL突然崩潰
MySQL 似乎突然崩潰但在大約 2 分鐘後恢復。我在 Ubuntu 18.04(16vcpu,32GB RAM)上執行。我不知道是什麼原因造成的。
這是我的.ini
[mysql] default-character-set=utf8mb4 [mysqld] lower_case_table_names = 1 pid-file = /var/run/mysqld/mysqld.pid socket = /var/run/mysqld/mysqld.sock datadir = /data/mysql log-error = /var/log/mysql/error.log # By default we only accept connections from localhost #bind-address = 127.0.0.1 # Disabling symbolic-links is recommended to prevent assorted security risks symbolic-links=0 max_allowed_packet=1G max_connect_errors=1000 max_connections=2500 character-set-server=utf8mb4 collation-server=utf8mb4_unicode_ci innodb_buffer_pool_size=27G server-id=2 log-bin=env1 expire_logs_days=2 sql_mode='STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION' net_read_timeout=300 net_write_timeout=300 log_bin_trust_function_creators=1
如上圖所示,事故發生在上午 8:11 左右
我試圖找到這個的根本原因。Ubuntu 中是否有任何日誌可供我查看以查找有關導致 MySQL 崩潰的原因的更多資訊?
編輯:我在 /var/log/syslog 上看到 OOM(記憶體不足)錯誤。知道是什麼原因造成的嗎?
innodb_buffer_pool_size=27G 太接近限制,尤其是在有大量(最大)連接的情況下。
降低它並檢查使用率。
show global status like 'innodb_buffer_pool_pages%
經過合理的熱身(24小時以上)後應該是滿的
show global status like 'innodb_buffer_pool_read%
.read_requests
vsreads
應該相當大。(reads
% < 1%)。一旦你有了這個平衡,希望有足夠的記憶體來避免 OOM,但仍然有足夠的性能。