Linux 上で MySQL (Percona サーバー) がクラッシュする原因を特定するにはどうすればよいでしょうか

Question

Percona バージョンの MySQL Server v5.6 を実行していますが、数日ごとに MySQL がクラッシュし、その後自動的に再起動するようです。クラッシュの原因を突き止めるにはどうしたらよいでしょうか? 他の人が MySQL を突然停止したのを見たことがありますが、メモリの問題のようです。しかし、その場合、エラー ログにそのことが記録されています。私の場合は、実際に再起動するまでログ ファイルに何も表示されません。

以下に、最後の「予期される」エラーと、MySQL の再起動時にログに記録される内容を含む関連ログ ファイルを示します。クラッシュ前のさまざまな「バイナリ ログに書き込まれた安全でないステートメント」警告が含まれていますが、これがクラッシュの原因であるとは考えていません。(ON DUPLICATE KEYログがいっぱいになるのを防ぐために、ステートメントを停止する構文を使用しないように、すぐにステートメントを更新します。また、レプリケーションは行わないため、現時点ではそれほど重要ではないと考えています。)

サーバーは、仮想マシン (Virtuozzo) 上で実行されている 64 ビット Centos 6.6 です。

クラッシュの原因を特定するために、誰かが私に正しい方向を指し示してくれることを願っています。 ありがとうございます!

ログファイルは以下の通りです:

2018-03-19 08:39:51 21476 [警告] BINLOG_FORMAT = STATEMENT であるため、ステートメント形式を使用してバイナリ ログに安全でないステートメントが書き込まれました。複数の UNIQUE KEY を持つテーブルでの INSERT... ON DUPLICATE KEY UPDATE は安全ではありません。ステートメント: INSERT INTO xxxx ON DUPLICATE KEY UPDATE xxxx
180319 08:39:52 mysqld_safe 現在実行中のプロセス数: 0
180319 08:39:52 mysqld_safe mysqldが再起動しました
2018-03-19 08:39:53 0 [警告] 暗黙の DEFAULT 値を持つ TIMESTAMP は非推奨です。--explicit_defaults_for_timestamp サーバー オプションを使用してください (詳細についてはドキュメントを参照してください)。
2018-03-19 08:39:53 20217 [警告] myisam-recover-options の代わりに固有のオプション プレフィックス myisam-recover を使用することは非推奨であり、将来のリリースで削除される予定です。代わりにフルネームを使用してください。
2018-03-19 08:39:53 20217 [注意] プラグイン「FEDERATED」は無効になっています。
2018-03-19 08:39:53 20217 [注記] InnoDB: アトミックを使用してバッファプールページを参照カウントする
2018-03-19 08:39:53 20217 [注意] InnoDB: InnoDB メモリヒープが無効になっています
2018-03-19 08:39:53 20217 [注記] InnoDB: ミューテックスと rw_locks は GCC アトミック組み込み関数を使用します
2018-03-19 08:39:53 20217 [注意] InnoDB: メモリバリアは使用されません
2018-03-19 08:39:53 20217 [注記] InnoDB: 圧縮テーブルは zlib 1.2.3 を使用します
2018-03-19 08:39:53 20217 [メモ] InnoDB: LinuxネイティブAIOの使用
2018-03-19 08:39:53 20217 [注意] InnoDB: CPU crc32 命令の使用
2018-03-19 08:39:53 20217 [注記] InnoDB: バッファプールを初期化しています。サイズ = 3.0G
2018-03-19 08:39:54 20217 [注記] InnoDB: バッファプールの初期化が完了しました
2018-03-19 08:39:54 20217 [注記] InnoDB: サポートされている最高のファイル形式は Barracuda です。
2018-03-19 08:39:54 20217 [注記] InnoDB: ログスキャンがチェックポイント lsn 123717382274 を超えて進行しました
2018-03-19 08:39:54 20217 [注意] InnoDB: データベースが正常にシャットダウンされませんでした。
2018-03-19 08:39:54 20217 [注記] InnoDB: クラッシュリカバリを開始しています。
2018-03-19 08:39:54 20217 [注記] InnoDB: .ibd ファイルからテーブルスペース情報を読み取っています...
2018-03-19 08:39:54 20217 [注記] InnoDB: 半分書き込まれた可能性のあるデータページの復元
2018-03-19 08:39:54 20217 [注記] InnoDB: ダブルライト バッファから...
InnoDB: リカバリを実行しています: ログ シーケンス番号 123717811056 までスキャンしました
InnoDB: トランザクション 790235434 は XA 準備状態でした。
InnoDB: ロールバックまたはクリーンアップする必要があるトランザクションが 1 件あります
InnoDB: 元に戻す行操作は合計 0 行です
InnoDB: Trx ID カウンターは 790235904 です
2018-03-19 08:39:55 20217 [注記] InnoDB: データベースへのログ レコードの適用バッチを開始しています...
InnoDB: 進捗状況（パーセント）: 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 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 7
InnoDB: バッチ適用が完了しました
InnoDB: 最後の MySQL binlog ファイルの位置 0 697177863、ファイル名 mysql-bin.000227
InnoDB: コミットされていないトランザクションのロールバックをバックグラウンドで開始する
2018-03-19 08:39:56 20217 [注記] InnoDB: 128 個のロールバック セグメントがアクティブです。
2018-03-19 08:39:56 7f481bd03700 InnoDB: 準備されていないトランザクションのロールバックが完了しました
2018-03-19 08:39:56 20217 [メモ] InnoDB: パージの開始を待機しています
2018-03-19 08:39:56 20217 [注記] InnoDB: Percona XtraDB (http://www.percona.com) 5.6.22-71.0 が起動しました。ログ シーケンス番号 123717811056
2018-03-19 08:39:56 20217 [注記] /var/lib/mysql/mysql-bin を使用してクラッシュ後に回復する
2018-03-19 08:46:36 20217 [注意] クラッシュリカバリを開始しています...
2018-03-19 08:46:36 7f491ce677e0 InnoDB: XA トランザクションのリカバリを開始しています...
2018-03-19 08:46:36 7f491ce677e0 InnoDB: トランザクション 790235434 はリカバリ後の準備済み状態です
2018-03-19 08:46:36 7f491ce677e0 InnoDB: トランザクションには 1 行の変更が含まれています
2018-03-19 08:46:36 7f491ce677e0 InnoDB: リカバリ後に準備状態のトランザクションが 1 件あります
2018-03-19 08:46:36 20217 [注記] InnoDB に準備されたトランザクションが 1 つ見つかりました
2018-03-19 08:46:36 20217 [注記] クラッシュリカバリが完了しました。
2018-03-19 08:46:36 20217 [注意] RSA 秘密鍵ファイルが見つかりません: /var/lib/mysql//private_key.pem。一部の認証プラグインは動作しません。
2018-03-19 08:46:36 20217 [注意] RSA 公開鍵ファイルが見つかりません: /var/lib/mysql//public_key.pem。一部の認証プラグインは動作しません。
2018-03-19 08:46:36 20217 [注記] サーバーホスト名 (バインドアドレス): '*'; ポート: 3306
2018-03-19 08:46:36 20217 [注意] IPv6が利用可能です。
2018-03-19 08:46:36 20217 [注記] - '::' は '::' に解決されます。
2018-03-19 08:46:36 20217 [注記] IP: '::' にサーバー ソケットが作成されました。
2018-03-19 08:46:37 20217 [メモ] イベントスケジューラ: 0 件のイベントが読み込まれました
2018-03-19 08:46:37 20217 [注記] /usr/sbin/mysqld: 接続準備完了。
バージョン: '5.6.22-71.0-log' ソケット: '/var/lib/mysql/mysql.sock' ポート: 3306 Percona Server (GPL)、リリース 71.0、リビジョン 726
2018-03-19 08:46:38 20217 [警告] BINLOG_FORMAT = STATEMENT であるため、ステートメント形式を使用してバイナリ ログに安全でないステートメントが書き込まれました。複数の UNIQUE KEY を持つテーブルでの INSERT... ON DUPLICATE KEY UPDATE は安全ではありません。ステートメント: INSERT INTO xxxx ON DUPLICATE KEY UPDATE xxxx

編集：コメント欄の@impimpの質問に応じて、以下は/var/log/messages

3月18日 04:02:22 HOSTNAME rsyslogd: [origin software="rsyslogd" swVersion="5.8.10" x-pid="474" x-info="http://www.rsyslog.com"] rsyslogd が HUP されました
3月19日 08:39:52 HOSTNAMEカーネル: [103311785.405884] UB 650543のメモリ不足: OOMがプロセス21476 (mysqld)を強制終了しました。スコア0 vm:6363484kB、rss:4024500kB、swap:45536kB
3月20日 09:17:35 HOSTNAMEカーネル: [103400050.711461] UB 650543のメモリ不足: OOMがプロセス20217 (mysqld)を強制終了しました スコア0 vm:6382720kB、rss:4066652kB、swap:0kB