2016-07-21 7 views
0

私たちは、テストレベルのサーバではほとんど毎日、テーブルレベルのロックの問題に直面しています。innodbテーブルレベルのロック

TRANSACTION 0, not started 
mysql tables in use 97, locked 97 
MySQL thread id 429, OS thread handle 0x2aff6ff59700, query id 24900 ec2-*-*-*-*.compute-1.amazonaws.com *.*.*.* sminq cleaning up 
---TRANSACTION 10631403, not started 
MySQL thread id 321, OS thread handle 0x2aff7b359700, query id 24901 115.112.140.139 sminq init 
show engine innodb status 
---TRANSACTION 10632661, not started 
MySQL thread id 13, OS thread handle 0x2aff4e39a700, query id 24817 localhost 127.0.0.1 rdsadmin cleaning up 
---TRANSACTION 10632664, not started 
MySQL thread id 6, OS thread handle 0x2aff396c5700, query id 24873 ec2-*-*-*-*.ap-southeast-1.compute.amazonaws.com *.*.*.* sminq cleaning up 
---TRANSACTION 10632655, not started 
MySQL thread id 7, OS thread handle 0x2aff39706700, query id 24783 ec2-*-*-*-*.ap-southeast-1.compute.amazonaws.com *.*.*.* sminq cleaning up 
---TRANSACTION 10632652, not started 
MySQL thread id 3, OS thread handle 0x2aff37d28700, query id 24745 ec2-*-*-*-*.ap-southeast-1.compute.amazonaws.com *.*.*.* sminq cleaning up 
---TRANSACTION 10627075, not started 
MySQL thread id 1, OS thread handle 0x2aff37ca6700, query id 0 Waiting for background binlog tasks 
---TRANSACTION 10632663, ACTIVE 7 sec 
mysql tables in use 1, locked 1 
MySQL thread id 431, OS thread handle 0x2aff37daa700, query id 24863 172.31.3.120 sminq Waiting for table level lock 
insert into `sminq`.`Queue_token` (`token_queue_id`, `total_process_time`, `token_user`, `created_on`, `join_date`, `join_time`, `app_type`, `token_user_group`, `uuid`) values (13, 10, 87, '2016-07-21 04:47:04.157000', '2016-07-21 10:17:04', '10:10:00', 1, NULL, 'D<??BY??7?gk?Uo') 
Trx #rec lock waits 0 #table lock waits 0 
Trx total rec lock wait time 0 SEC 
Trx total table lock wait time 0 SEC 
---TRANSACTION 10632646, ACTIVE 45 sec 

これらは挿入物でのみ発生します。私たちは更新または削除の問題に直面しませんでした。

これは我々がT2でテストを実行しているテスト・サーバであるので、私は、分離レベルREAD-COMMITTED、同じサーバ

[--] Up for: 2h 11m 55s (25K q [3.230 qps], 478 conn, TX: 3M, RX: 1M) 
[--] Reads/Writes: 82%/18% 
[--] Binary logging is enabled (GTID MODE: OFF) 
[--] Total buffers: 1.5G global + 17.0M per thread (100 max threads) 
[!!] Maximum reached memory usage: 3.0G (152.35% of installed RAM) 
[!!] Maximum possible memory usage: 3.1G (156.50% of installed RAM) 
[OK] Slow queries: 0% (0/25K) 
[!!] Highest connection usage: 95% (95/100) 
[OK] Aborted connections: 0.00% (0/478) 
[!!] Query cache is disabled 
[OK] Sorts requiring temporary tables: 0% (0 temp sorts/1K sorts) 
[OK] Temporary tables created on disk: 24% (424 on disk/1K total) 
[OK] Thread cache hit rate: 80% (95 created/478 connections) 
[OK] Table cache hit rate: 129% (291 open/224 opened) 
[OK] Open file limit used: 0% (64/65K) 
[OK] Table locks acquired immediately: 99% (6K immediate/6K locks) 
[OK] Binlog cache memory access: 100.00% (1618 Memory/1618 Total) 

-------- MyISAM Metrics ----------------------------------------------------- 
[!!] Key buffer used: 18.5% (1M used/8M cache) 
[OK] Key buffer size/total MyISAM indexes: 8.0M/2.4M 
[!!] Read Key buffer hit rate: 82.2% (90 cached/16 reads) 

-------- InnoDB Metrics ----------------------------------------------------- 
[--] InnoDB is enabled. 
[OK] InnoDB buffer pool/data size: 1.3G/29.0M 
[!!] InnoDB buffer pool instances: 8 
[!!] InnoDB Used buffer: 1.32% (1139 used/ 86584 total) 
[OK] InnoDB Read buffer efficiency: 99.86% (713109 hits/ 714137 total) 
[!!] InnoDB Write buffer efficiency: 0.00% (0 hits/ 1 total) 
[OK] InnoDB log waits: 0.00% (0 waits/4915 writes) 

ためinnodb_autoinc_lock_mode = 2

mysqltuner出力と共にを有します。 small

+0

'--- TRANSACTION 10632646、ACTIVE 45 sec' - この取引は何ですか?なぜ45秒間開いているのですか? – akuzminsky

+0

PROCESS_LISTから詳細を取得できますか? – user160108

+0

いいえ、プロセスリストの過去のステートメントは表示されません。 – akuzminsky

答えて

1

1.3G buffer_pool in 2GB RAM?これはおそらく多くのスワッピングにつながりますが、実際にはパフォーマンスが悪いです。

2GBのRAMと29Mのデータの場合は、innodb_buffer_pool_size = 100Mに設定してください。それは今のところ十分であり、後で(データが大きくなるにつれて)安全です。

(70%または80%の推薦のみRAMの少なくとも4ギガバイトのマシンに適用される。)

がそれを修正します。問題が解決しない場合は、質問を新しい値で更新し、関連するテーブルのSHOW CREATE TABLEを更新してください。

+0

は、これらの値を更新し、さらにテストします、当社の生産は約3.75ギガバイトのメモリを持っているm3.mediumです。このdbのデータは665MBなので、あなたの推奨事項では、私たちの生産innodb_buffer_pool_size = 2Gは問題ありません。 – user160108

+0

いいえ1400Mにしましょう。 (2G _might_ okでもよいが、特に安全にプレイしよう。すぐには665MB以上を使用しないでください。) –

+0

変更を加えてもスムーズに動作しているように見えますが、引き続き監視します。ヒントをありがとう。 – user160108

0

AUTO-INCロックは、AUTO_INCREMENT列を持つテーブルに挿入するトランザクションによって行われる特殊なテーブルレベルのロックです。最も単純な場合、あるトランザクションがテーブルに値を挿入している場合、他のトランザクションはそのテーブルへの挿入を待つ必要があるため、最初のトランザクションによって挿入された行は連続する主キー値を受け取ります。

設定オプションinnodb_autoinc_lock_modeは、自動インクリメントロックに使用されるアルゴリズムを制御します。自動インクリメント値の予測可能シーケンスと挿入操作の最大並行性の間でトレードオフを行う方法を選択できます。

許容値はこれは、「伝統的な」、「連続」、または「インターリーブ」ロックモード

innodb_autoinc_lock_mode = 2(「インターリーブ」ロックモード)

ため、0、1、又は2でありますロックモードでは、「INSERT-like」ステートメントはテーブルレベルのAUTO-INCロックを使用せず、複数のステートメントを同時に実行できます。これは最も高速で拡張性の高いロック・モードですが、SQL文がバイナリ・ログから再生されるときに文ベースのレプリケーションまたはリカバリ・シナリオを使用する場合は安全ではありません。

このロックモードでは、自動インクリメント値は一意になり、同時に実行されるすべての "INSERT-like"ステートメントで単調に増加することが保証されます。ただし、複数の文が同時に数値を生成する可能性があるため(つまり、数値の割当ては文間でインターリーブされます)、指定された文によって挿入された行に対して生成された値は連続しないことがあります。

挿入される行の数が事前にわかっている "単純な挿入"のみが実行されている場合、 "混合モードの挿入"を除いて、単一の文で生成される番号にはギャップはありません。ただし、「一括挿入」を実行すると、任意のステートメントによって割り当てられた自動インクリメント値にギャップが存在する可能性があります。

ソースLockingを参照し、要件に基づいて設定を変更してください。

関連する問題