pthread_mutex_lock問題のデバッグと分析

pthread_mutex_lock問題のデバッグと分析

私は最近、Linuxミューテックス、特にMySQL、memcache、APCuに関連するいくつかの重要な問題に直面しました。

例:

  • SQLSTATE[HY000]: 一般エラー: 1205 ロック待ちタイムアウト、トランザクションの再始動試行: INSERT INTO
  • 銅銅:https://github.com/krakjoe/apcu/issues/416
  • Memcache OOM:メモリ不足に関連するもの

Linuxに関する私の知識は非常に基本的で制限的です。私はミューテックスが2つ以上の同時プロセスがクラッシュしたり競合状態を引き起こしたりしないようにするメカニズムであることを知っています。

  • MySQLの場合、MySQLが一部のInnoDBテーブルにロックを設定したことがわかっているため、再起動すると問題が解決しました。しかし、私が理解していないのは、そのロックを維持しながらどのプロセスが終了するかです。誰が、何らかの理由で殺されたのか、そしてそのシーンを引き起こしたコードは何でしたか?私はMySQL 8を使用していますが、Performance_schema.data_lock_waitsを確認できますか?しかし、次に取るべき措置は何ですか?
  • APCuの場合:実行中のPHPプロセスでstraceを実行し、FUTEX_WAITを取得し、GDBを実行しましたが、apcu_incがpthread_rwlock_wrlockで停止しました。 APCuを無効にすると問題が解決し、アップグレードも完了しました。これはこの問題をさらに調査する機会でしたが、本番サーバーでこの問題をすばやく解決する必要があるため、これはできませんでした。再現できます。 APCuを使用するパッケージが多く、そうでない場合でもpthread_mutex_lockを使用するパッケージが多いため、関連内容を削除することはできません。
  • memcachedの場合:非常に古いバージョン(2012バージョン)を使用しているため、競合が発生し続けます。リリースノートを見ると、Memcacheがこれに関していくつかの困難を経験していることがわかります。買収と概要に関連するさまざまな問題を調査し、それをさらに調査するのに役立つ可能性があるかどうかを確認します。 「Hey, I have OOM」などの一般的な質問は避けられません。私は私の仕事をし、少なくとも何かを共有または再現できるはずです。

私はこれから2つのシナリオを得ます。

  • 実行プロセス:私はこの問題を処理できると思いました。コードをよく見て、他の人もこの問題に遭遇したことを願っています。
  • 終了したプロセス:この問題をどのように処理するのかわかりません。 MySQLとMemcacheに関する限り、誰が何らかの理由でこれらを殺しましたか?コードを追跡できますか?これを監視するには、いくつかのツールが必要ですか?何が起こっているのか、どうすればわかりますか?一部のデバイスロックまたはI / Oを調べる必要がありますか?

この問題をどのように処理しますか?

関連情報