検索
ホームページデータベースmysql チュートリアルテーブルを開く際の MySQL スレッドの問題の解決 (例付き)

この記事の内容は、テーブルを開く際の MySQL スレッドの問題の解決に関するものです (例付き)。必要な方は参考にしていただければ幸いです。

問題の説明

最近 MySQL5.6.21 サーバーがあり、アプリケーションがリリースされた後、同時スレッド Threads_running が急速に増加し、約 2000 に達します。テーブルのオープンを待機しているスレッドの数、テーブルのクローズ状況、アプリケーション側関連の論理アクセス タイムアウト。

[分析プロセス]

1. アプリケーションが 16:10 にリリースされた後、次の図に示すように、Opened_tables は増加し続けます。 ##当時の障害を表示 期間中に取得したpt-stalkログファイルでは、2019-01-18 16:29:37の時点でOpen_tablesの値は3430、table_open_cacheの設定値は2000となっています。
Open_tables 値が table_open_cache 値より大きい場合、新しいセッションがテーブルを開くたびに、一部のテーブルはテーブル キャッシュにヒットできず、テーブルを再度開く必要があります。これに反映される現象は、開始テーブル状態にあるスレッドが多数存在することです。 テーブルを開く際の MySQL スレッドの問題の解決 (例付き)

2. このインスタンスとシステム データベースの合計は 851 ですが、これは table_open_cache の 2000 よりはるかに少ないのはなぜですか?

公式ドキュメントから説明を得ることができます。
https://dev.mysql.com/doc/refman/5.6/en/table-cache.html

table_open_cache is related to max_connections. For example, for 200 concurrent running connections, specify a table cache size of at least 200 * N, where N is the maximum number of tables per join in any of the queries which you execute.

その時点で、同時スレッド数は 1980 に達しました。これらの同時接続の 30% が 2 つのテーブルにアクセスし、その他はすべて単一テーブルである場合、キャッシュ サイズは (1980*30%*2 1980*70%*1) = 2574

3 に達します。リリース前もリリース後も比較的安定しています。 リクエストから判断すると、接続リクエストが急激に増加したわけではありませんが、リリース後、threads_running は 2,000 近くの高値まで上昇し、継続しています。推測では、特定のパブリッシュされた SQL ステートメントが問題を引き起こしたと考えられます。

4. そのときに取得された processlist 情報を確認します。SQL の同時アクセスが非常に多いという記述があります。SQL サンプルは次のとおりです。 ##5. テスト環境では、同じテーブルを 8 つ作成し、テーブル キャッシュをクリアし、1 つのセッションで SQL を実行する前と後で比較すると、Open_tables の値は 8 増加します。大幅に増加します。

問題の再現

テスト環境で大量の同時アクセスのシナリオをシミュレートし、上記の SQL ステートメントを 1000 スレッドで同時に実行し、実稼働環境でも同様の現象が発生し、Open_tables がすぐに 3800 に達し、多数のプロセスがテーブルを開く状態およびテーブルを閉じる状態になります。

最適化計画

1. 問題の原因を突き止めた後、開発同僚と連絡を取り、単一文の SQL の数を減らすために SQL を最適化することを提案しました。テーブルにクエリを実行するか、SQL の同時アクセス頻度を大幅に削減します。

しかし、開発同僚が最適化する前に、本番環境で障害が再び発生しました。当時、DBA がトラブルシューティングを行っていたときに、table_open_cache が 2000 から 4000 に増加しました。CPU 使用率は増加しましたが、その効果は明ら​​かではありませんでした。テーブルを開くのに待機するという問題は依然として存在していました。

2. 障害時に取得された pstack 情報を分析し、pt-pmp で集計したところ、open_table:

<code>select id,name,email from table1 left join table2<br/>union all<br/>select id,name,email from table3 left join table4<br/>union all<br/>select id,name,email from table5 left join table6<br/>union all<br/>select id,name,email from table7 left join table8<br/>where id in (&#39;aaa&#39;);</code>
At this 時に多数のスレッドがミューテックス リソースを待機していることがわかりました。当時、table_cache_manager でのミューテックスの競合は非常に深刻でした。

MySQL 5.6.21 における table_open_cache_instances パラメータのデフォルト値は 1 であるため、table_open_cache_instances パラメータを増やし、テーブル キャッシュ パーティションを追加すると競合が軽減されると思います。


3. テスト環境では、table_open_cache_instances=32、table_open_cache=6000 の 2 つのパラメータを調整し、問題のある SQL を 1000 スレッドで同時に実行しましたが、今度はテーブルのオープンとテーブルのクローズを待機しているスレッドが消えました。 、MySQL QPS も 12,000 から 55,000 に増加しました。

同じ状況と比較すると、table_open_cache=6000 を調整するだけで、テーブルのオープンを待機しているプロセスの数が 861 から 203 に減少しました。600 を超えるプロセスがテーブルのオープンを待機している状態から実行状態に変わりました。 QPSは約40,000に増加しましたが、治療法ではありません。

ソースコード分析

table_open_cache の関連ロジックのコードを確認しました。
1. 新しい接続時の Table_cache::add_used_table 関数は次のとおりです。テーブルを開きます。テーブルがキャッシュに存在しない場合は、テーブルを開いて使用済みテーブル リストに追加します:

#0  0x0000003f0900e334 in __lll_lock_wait () from /lib64/libpthread.so.0
#1  0x0000003f0900960e in _L_lock_995 () from /lib64/libpthread.so.0
#2  0x0000003f09009576 in pthread_mutex_lock () from /lib64/libpthread.so.0
#3  0x000000000069ce98 in open_table(THD*, TABLE_LIST*, Open_table_context*) ()
#4  0x000000000069f2ba in open_tables(THD*, TABLE_LIST**, unsigned int*, unsigned int, Prelocking_strategy*) ()
#5  0x000000000069f3df in open_normal_and_derived_tables(THD*, TABLE_LIST*, unsigned int) ()
#6  0x00000000006de821 in execute_sqlcom_select(THD*, TABLE_LIST*) ()
#7  0x00000000006e13cf in mysql_execute_command(THD*) ()
#8  0x00000000006e4d8f in mysql_parse(THD*, char*, unsigned int, Parser_state*) ()
#9  0x00000000006e62cb in dispatch_command(enum_server_command, THD*, char*, unsigned int) ()
#10 0x00000000006b304f in do_handle_one_connection(THD*) ()
#11 0x00000000006b3177 in handle_one_connection ()
#12 0x0000000000afe5ca in pfs_spawn_thread ()
#13 0x0000003f09007aa1 in start_thread () from /lib64/libpthread.so.0
#14 0x0000003f088e893d in clone () from /lib64/libc.so.6

2。 m_table_count > の場合、add_used_table は毎回 Table_cache::free_unused_tables_if_necessary 関数を呼び出します。 ; table_cache_size_per_instance &&m_unused_tables が満たされている場合、remove_table が実行され、m_unused_tables リストがクリアされます。このうち、table_cache_size_per_instance = table_cache_size / table_cache_instances です。m_table_count の値が 2000 より大きく、m_unused_tables が空でない場合、remove_table が実行され、m_unused_tables 内のテーブル キャッシュがクリアされます。このように、m_table_count は Open_tables の値であり、通常は 2000 程度のままになります。

bool Table_cache::add_used_table(THD *thd, TABLE *table)
{
  Table_cache_element *el;

  assert_owner();

  DBUG_ASSERT(table->in_use == thd);

  /*
    Try to get Table_cache_element representing this table in the cache
    from array in the TABLE_SHARE.
  */
  el= table->s->cache_element[table_cache_manager.cache_index(this)];

  if (!el)
  {
    /*
      If TABLE_SHARE doesn&#39;t have pointer to the element representing table
      in this cache, the element for the table must be absent from table the
      cache.

      Allocate new Table_cache_element object and add it to the cache
      and array in TABLE_SHARE.
    */
    DBUG_ASSERT(! my_hash_search(&m_cache,
                                 (uchar*)table->s->table_cache_key.str,
                                 table->s->table_cache_key.length));

    if (!(el= new Table_cache_element(table->s)))
      return true;

    if (my_hash_insert(&m_cache, (uchar*)el))
    {
      delete el;
      return true;
    }

    table->s->cache_element[table_cache_manager.cache_index(this)]= el;
  }

  /* Add table to the used tables list */  
  el->used_tables.push_front(table);

  m_table_count++;  free_unused_tables_if_necessary(thd);

  return false;
}
3. table_cache_instances を 32 に増やします。Open_tables が (2000/32=62) を超えると条件が満たされ、上記のロジックで m_unused_tables のクリーンアップが加速され、テーブル キャッシュ内の数がさらに減ります。これにより、Table_open_cache_overflows が発生します。

4、当table_open_cache_instances从1增大到32时,1个LOCK_open锁分散到32个m_lock的mutex上,大大降低了锁的争用。

/** Acquire lock on table cache instance. */
  void lock() { mysql_mutex_lock(&m_lock); }
  /** Release lock on table cache instance. */
  void unlock() { mysql_mutex_unlock(&m_lock); }

解决问题

我们生产环境同时采取下面优化措施,问题得以解决:
1、 读写分离,增加read节点,分散master库的压力;
2、 调整table_open_cache_instances=16;
3、 调整table_open_cache=6000;

总结

当出现Opening tables等待问题时,
1、建议找出打开表频繁的SQL语句,优化该SQL,降低单句SQL查询表的数量或大幅降低该SQL的并发访问频率。

2、设置合适的table cache,同时增大table_open_cache_instances和 table_open_cache参数的值。

以上がテーブルを開く際の MySQL スレッドの問題の解決 (例付き)の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

声明
この記事は博客园で複製されています。侵害がある場合は、admin@php.cn までご連絡ください。
Innodb Redoログの役割を説明し、ログを元に戻します。Innodb Redoログの役割を説明し、ログを元に戻します。Apr 15, 2025 am 12:16 AM

INNODBは、レドログと非論的なものを使用して、データの一貫性と信頼性を確保しています。 1.レドログは、クラッシュの回復とトランザクションの持続性を確保するために、データページの変更を記録します。 2.Undologsは、元のデータ値を記録し、トランザクションロールバックとMVCCをサポートします。

説明出力(タイプ、キー、行、追加)で探す重要なメトリックは何ですか?説明出力(タイプ、キー、行、追加)で探す重要なメトリックは何ですか?Apr 15, 2025 am 12:15 AM

説明コマンドのキーメトリックには、タイプ、キー、行、および追加が含まれます。 1)タイプは、クエリのアクセスタイプを反映しています。値が高いほど、constなどの効率が高くなります。 2)キーは使用されているインデックスを表示し、nullはインデックスがないことを示します。 3)行はスキャンされた行の数を推定し、クエリのパフォーマンスに影響します。 4)追加の情報を最適化する必要があるというFilesortプロンプトを使用するなど、追加情報を提供します。

説明の一時的なステータスを使用し、それを回避する方法は何ですか?説明の一時的なステータスを使用し、それを回避する方法は何ですか?Apr 15, 2025 am 12:14 AM

Temporaryを使用すると、MySQLクエリに一時テーブルを作成する必要があることが示されています。これは、異なる列、またはインデックスされていない列を使用して順番に一般的に見られます。インデックスの発生を回避し、クエリを書き直し、クエリのパフォーマンスを改善できます。具体的には、expliect出力に使用を使用する場合、MySQLがクエリを処理するために一時テーブルを作成する必要があることを意味します。これは通常、次の場合に発生します。1)個別またはグループビーを使用する場合の重複排除またはグループ化。 2)Orderbyに非インデックス列が含まれているときに並べ替えます。 3)複雑なサブクエリを使用するか、操作に参加します。最適化方法には以下が含まれます。1)OrderbyとGroupB

さまざまなSQLトランザクションの分離レベル(読み取り、commited、繰り返し読み取り、シリアル化可能、シリアル化可能)とmysql/innodbの意味を説明してください。さまざまなSQLトランザクションの分離レベル(読み取り、commited、繰り返し読み取り、シリアル化可能、シリアル化可能)とmysql/innodbの意味を説明してください。Apr 15, 2025 am 12:11 AM

MySQL/INNODBは、4つのトランザクション分離レベルをサポートしています。 1.ReadunCommittedは、知らないデータを読み取ることができます。 2。読み込みは汚い読み取りを回避しますが、繰り返しのない読みが発生する可能性があります。 3. RepeatablerEadはデフォルトレベルであり、汚い読み取りと非回復不可能な読みを避けますが、幻の読み取りが発生する可能性があります。 4. Serializableはすべての並行性の問題を回避しますが、同時性を低下させます。適切な分離レベルを選択するには、データの一貫性とパフォーマンス要件のバランスをとる必要があります。

MySQL対その他のデータベース:オプションの比較MySQL対その他のデータベース:オプションの比較Apr 15, 2025 am 12:08 AM

MySQLは、Webアプリケーションやコンテンツ管理システムに適しており、オープンソース、高性能、使いやすさに人気があります。 1)PostgreSQLと比較して、MySQLは簡単なクエリと高い同時読み取り操作でパフォーマンスが向上します。 2)Oracleと比較して、MySQLは、オープンソースと低コストのため、中小企業の間でより一般的です。 3)Microsoft SQL Serverと比較して、MySQLはクロスプラットフォームアプリケーションにより適しています。 4)MongoDBとは異なり、MySQLは構造化されたデータおよびトランザクション処理により適しています。

MySQL Index Cardinalityはクエリパフォーマンスにどのように影響しますか?MySQL Index Cardinalityはクエリパフォーマンスにどのように影響しますか?Apr 14, 2025 am 12:18 AM

MySQLインデックスのカーディナリティは、クエリパフォーマンスに大きな影響を及ぼします。1。高いカーディナリティインデックスは、データ範囲をより効果的に狭め、クエリ効率を向上させることができます。 2。低カーディナリティインデックスは、完全なテーブルスキャンにつながり、クエリのパフォーマンスを削減する可能性があります。 3。ジョイントインデックスでは、クエリを最適化するために、高いカーディナリティシーケンスを前に配置する必要があります。

MySQL:新規ユーザー向けのリソースとチュートリアルMySQL:新規ユーザー向けのリソースとチュートリアルApr 14, 2025 am 12:16 AM

MySQL学習パスには、基本的な知識、コアの概念、使用例、最適化手法が含まれます。 1)テーブル、行、列、SQLクエリなどの基本概念を理解します。 2)MySQLの定義、作業原則、および利点を学びます。 3)インデックスやストアドプロシージャなどの基本的なCRUD操作と高度な使用法をマスターします。 4)インデックスの合理的な使用や最適化クエリなど、一般的なエラーのデバッグとパフォーマンス最適化の提案に精通しています。これらの手順を通じて、MySQLの使用と最適化を完全に把握できます。

実際のmysql:例とユースケース実際のmysql:例とユースケースApr 14, 2025 am 12:15 AM

MySQLの実際のアプリケーションには、基本的なデータベース設計と複雑なクエリの最適化が含まれます。 1)基本的な使用法:ユーザー情報の挿入、クエリ、更新、削除など、ユーザーデータの保存と管理に使用されます。 2)高度な使用法:eコマースプラットフォームの注文や在庫管理など、複雑なビジネスロジックを処理します。 3)パフォーマンスの最適化:インデックス、パーティションテーブル、クエリキャッシュを使用して合理的にパフォーマンスを向上させます。

See all articles

ホットAIツール

Undresser.AI Undress

Undresser.AI Undress

リアルなヌード写真を作成する AI 搭載アプリ

AI Clothes Remover

AI Clothes Remover

写真から衣服を削除するオンライン AI ツール。

Undress AI Tool

Undress AI Tool

脱衣画像を無料で

Clothoff.io

Clothoff.io

AI衣類リムーバー

AI Hentai Generator

AI Hentai Generator

AIヘンタイを無料で生成します。

ホットツール

VSCode Windows 64 ビットのダウンロード

VSCode Windows 64 ビットのダウンロード

Microsoft によって発売された無料で強力な IDE エディター

EditPlus 中国語クラック版

EditPlus 中国語クラック版

サイズが小さく、構文の強調表示、コード プロンプト機能はサポートされていません

SublimeText3 Linux 新バージョン

SublimeText3 Linux 新バージョン

SublimeText3 Linux 最新バージョン

ドリームウィーバー CS6

ドリームウィーバー CS6

ビジュアル Web 開発ツール

DVWA

DVWA

Damn Vulnerable Web App (DVWA) は、非常に脆弱な PHP/MySQL Web アプリケーションです。その主な目的は、セキュリティ専門家が法的環境でスキルとツールをテストするのに役立ち、Web 開発者が Web アプリケーションを保護するプロセスをより深く理解できるようにし、教師/生徒が教室環境で Web アプリケーションを教え/学習できるようにすることです。安全。 DVWA の目標は、シンプルでわかりやすいインターフェイスを通じて、さまざまな難易度で最も一般的な Web 脆弱性のいくつかを実践することです。このソフトウェアは、