我的网站位于具有 1 GN RAM 的 VPS 上,出于某种原因,它有时会自动崩溃。我可以查看 error.log,但无法理解错误的含义以及真正的原因是什么。以下是上次 mysql 服务器崩溃时生成的日志。
[Warning] Changed limits: max_open_files: 1024 (requested 5000)
[Warning] Changed limits: table_open_cache: 431 (requested 2000)
[Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).
[Note] /usr/sbin/mysqld (mysqld 5.7.18-0ubuntu0.16.04.1) starting as process 27819 ...
[Note] InnoDB: PUNCH HOLE support available
[Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
[Note] InnoDB: Uses event mutexes
[Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
[Note] InnoDB: Compressed tables use zlib 1.2.8
[Note] InnoDB: Using Linux native AIO
[Note] InnoDB: Number of pools: 1
[Note] InnoDB: Using CPU crc32 instructions
[Note] InnoDB: Initializing buffer pool, total size = 128M, instances = 1, chunk size = 128M
[Note] InnoDB: Completed initialization of buffer pool
[Note] InnoDB: If the mysqld execution user is authorized, page cleaner thread priority can be changed. See the man page of setpriority().
[Note] InnoDB: Highest supported file format is Barracuda.
[Note] InnoDB: Log scan progressed past the checkpoint lsn 599964175
[Note] InnoDB: Doing recovery: scanned up to log sequence number 599964380
[Note] InnoDB: Doing recovery: scanned up to log sequence number 599964380
[Note] InnoDB: Database was not shutdown normally!
[Note] InnoDB: Starting crash recovery.
[Note] InnoDB: Starting an apply batch of log records to the database...
InnoDB: Progress in percent: 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99
[Note] InnoDB: Apply batch completed
[Note] InnoDB: Removed temporary tablespace data file: "ibtmp1"
[Note] InnoDB: Creating shared tablespace for temporary tables
[Note] InnoDB: Setting file './ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
[Note] InnoDB: File './ibtmp1' size is now 12 MB.
[Note] InnoDB: 96 redo rollback segment(s) found. 96 redo rollback segment(s) are active.
[Note] InnoDB: 32 non-redo rollback segment(s) are active.
[Note] InnoDB: Waiting for purge to start
[Note] InnoDB: 5.7.18 started; log sequence number 599964380
[Note] InnoDB: Loading buffer pool(s) from /var/lib/mysql/ib_buffer_pool
[Note] Plugin 'FEDERATED' is disabled.
[Warning] Failed to set up SSL because of the following SSL library error: SSL context is not usable without certificate and private key
[Note] Server hostname (bind-address): '127.0.0.1'; port: 3306
[Note] - '127.0.0.1' resolves to '127.0.0.1';
[Note] Server socket created on IP: '127.0.0.1'.
[Note] InnoDB: Buffer pool(s) load completed at 170609 9:13:52
[Note] Event Scheduler: Loaded 0 events
[Note] /usr/sbin/mysqld: ready for connections.
Version: '5.7.18-0ubuntu0.16.04.1' socket: '/var/run/mysqld/mysqld.sock' port: 3306 (Ubuntu)
[Note] Executing 'SELECT * FROM INFORMATION_SCHEMA.TABLES;' to get a list of tables using the deprecated partition engine. You may use the startup option '--disable-partition-engine-check' to skip this check
[Note] Beginning of list of non-natively partitioned tables
[Note] End of list of non-natively partitioned tables
[Note] Access denied for user 'root'@'localhost' (using password: NO)
[ERROR] /usr/sbin/mysqld: Table './table_name/wp_posts' is marked as crashed and should be repaired
[Warning] Checking table: './table_name/wp_posts'
[ERROR] /usr/sbin/mysqld: Table './table_name/wp_postmeta' is marked as crashed and should be repaired
[Warning] Checking table: './table_name/wp_postmeta'
[ERROR] /usr/sbin/mysqld: Table './table_name/wp_comments' is marked as crashed and should be repaired
[Warning] Checking table: './table_name/wp_comments'
[ERROR] /usr/sbin/mysqld: Table './table_name/wp_commentmeta' is marked as crashed and should be repaired
[Warning] Checking table: './table_name/wp_commentmeta'
[ERROR] /usr/sbin/mysqld: Table './table_name/wp_options' is marked as crashed and should be repaired
[Warning] Checking table: './table_name/wp_options'
[ERROR] /usr/sbin/mysqld: Table './table_name/wp_term_taxonomy' is marked as crashed and should be repaired
[Warning] Checking table: './table_name/wp_term_taxonomy'
[ERROR] /usr/sbin/mysqld: Table './table_name/wp_term_relationships' is marked as crashed and should be repaired
[Warning] Checking table: './table_name/wp_term_relationships'
[ERROR] /usr/sbin/mysqld: Table './table_name/wp_termmeta' is marked as crashed and should be repaired
[Warning] Checking table: './table_name/wp_termmeta'
[ERROR] /usr/sbin/mysqld: Table './table_name/wp_users' is marked as crashed and should be repaired
[Warning] Checking table: './table_name/wp_users'
[ERROR] /usr/sbin/mysqld: Table './table_name/wp_usermeta' is marked as crashed and should be repaired
[Warning] Checking table: './table_name/wp_usermeta'
[ERROR] /usr/sbin/mysqld: Table './table_name/wp_woocommerce_order_items' is marked as crashed and should be repaired
[Warning] Checking table: './table_name/wp_woocommerce_order_items'
[ERROR] /usr/sbin/mysqld: Table './table_name/wp_woocommerce_order_itemmeta' is marked as crashed and should be repaired
[Warning] Checking table: './table_name/wp_woocommerce_order_itemmeta'
[ERROR] /usr/sbin/mysqld: Table './table_name/wp_woocommerce_sessions' is marked as crashed and should be repaired
[Warning] Checking table: './table_name/wp_woocommerce_sessions'
您能帮我解读日志并指导我找到解决方案吗?谢谢!
答案1
也许 MySQL 服务器被 OOM 终止程序终止了。查看以dmesg | grep -i memory
检查是否有 OOM 干预。
答案2
我同意初段绍克。您的 MySQL 被 OOM-killer 杀死。如果您没有启用交换并在 VPS 上使用 Apache,它可能会占用所有内存并调用 OOM-killer,有时它会杀死 MySQL。要检查它,您可以运行cat /var/log/syslog | grep kill
答案3
请检查 MySQL 中最大的数据库。您可以在 MySQL 数据目录中使用 du 命令。然后尝试从生产服务器禁用数据库。最有可能是最大的数据库之一导致了这种情况。每当尝试使用特定数据库时都会导致这种情况。此外,您可以跟踪数据库中可能已损坏或包含无效数据的任何特定表。
答案4
我也同意这里所说的内容,这是我读到的内容。
OOM 杀手
Linux 内核具有一项名为“内存不足杀手”(或 OOM 杀手)的功能,负责处理内存耗尽问题。如果系统达到可能很快耗尽所有内存的程度,OOM 杀手会寻找可以杀死的进程并终止其生命。
May 16 00:12:33 mysql-server-01 kernel: Out of Memory: Killed process 3154 (mysqld).
它是如何工作的以及为什么它经常会杀死 MySQL?
OOM Killer 使用启发式系统来选择要终止的进程。它基于与每个正在运行的应用程序相关联的分数,该分数由 Linux 内核中的 oom_badness() 调用(以前称为 badness())计算得出。对更多详细信息感兴趣的人可以查看 mm/oom_kill.c 中的源代码。
该算法相对简单,通常进程使用的内存越多,其得分就越高,因此被杀死的可能性就越大。但实际上需要考虑的因素更多:
内存消耗
流程所有权
进程年龄(仅限较老的 kenerls)
CPU 使用的时长(仅限旧内核)
进程 nice 值(仅限旧内核)
进程标志
oom_adj/oom_score_adj 设置
由于该算法在内核 2.6.29 中大部分被重写,因此不同 Linux 版本的完整列表可能有所不同。
过去,修饰符会对分数产生很大影响,例如,如果某个任务的优先级高于零,则其分数会翻倍。如果该任务由特权用户拥有,则分数除以八。在新内核中,情况不再如此。例如,属于 root 的进程现在只能获得 1000 分中的 30 分,这非常少见。有了这些变化,开发人员想要一种更可预测的算法,显然这就是实现这一目标的方法。
所以为什么它会杀死 MySQL这么频繁吗?答案很简单——因为 MySQL 通常使用最多的内存在系统中运行的所有进程中。
这是我读到这篇文章的链接。 https://www.psce.com/blog/2012/05/31/mysql-oom-killer-and-everything-related/