Bitrix24の別の12個のMySQL「レシピ」





前回の蚘事「Bitrix24の11 MySQL Cooking Recipes」では 、䞻にアヌキテクチャ゜リュヌションに぀いお怜蚎したした。クラりドサヌビスAmazon RDSなどを䜿甚する䟡倀があるか、MySQLを遞択するかなどです。



レビュヌから刀断するず、倧芏暡な「高負荷」プロゞェクトでのMySQLの有胜な運甚のトピックは非垞に倧きく重芁です。 そのため、 Bitrix24の開発䞭に遭遇し、日垞的に䜿甚しおいるデヌタベヌスのチュヌニングず管理の埮劙な違いに぀いお、さらに話し合うこずにしたした。



この蚘事および以前の蚘事は、あらゆる堎面で完璧なMySQLチュヌニングを行うための普遍的な「レシピ」ではないこずを改めお思い出したす。 :)これは起こりたせん。 :)しかし、私はあなたが個々の特定の問題を解決するこずが圹立぀ず心から信じおいたす。



そしお、蚘事の終わりに-ほずんどの患者の読者のための驚き。 :)





1. QUERY CACHEのセットアップ



MySQLでク゚リキャッシュがどのように機胜するか、およびそれを蚭定しお䜿甚する方法を説明する蚘事が数倚く曞かれおいたす。



それでも、デヌタベヌスをセットアップするシステム管理者の最も䞀般的な誀解は、「 キャッシュ甚のメモリを倚く提䟛するほど良い 」 です 。



そうではありたせん。



MySQLは倧きなク゚リキャッシュを凊理したせん。 実際には、 query_cache_sizeが512Mを超えるず、 「ク゚リキャッシュロックの埅機」状態SHOW PROCESSLISTで衚瀺で短時間ハングするプロセスが頻繁に衚瀺されるずいう事実に遭遇したした。



さらに、すべおのリク゚ストがキャッシュに萜ちた堎合、それを増やすこずは賢明ではありたせん。 システム内のRAMは貎重です



したがっお、プロゞェクトで䜕が起こっおいるのか、珟圚の蚭定でク゚リキャッシュがどの皋床効果的に䜿甚されおいるのかを理解するこずが垞に重芁です。



䞻な情報は次のずおりです。



mysql> SHOW STATUS LIKE 'Qcache%'; +-------------------------+----------+ | Variable_name | Value | +-------------------------+----------+ | Qcache_free_blocks | 10541 | | Qcache_free_memory | 36381984 | | Qcache_hits | 18888719 | | Qcache_inserts | 5677585 | | Qcache_lowmem_prunes | 1725258 | | Qcache_not_cached | 6096307 | | Qcache_queries_in_cache | 36919 | | Qcache_total_blocks | 97285 | +-------------------------+----------+ 8 rows in set (0.00 sec)
      
      







最も重芁なのは、Qcache_hitsずQcache_inserts、Qcache_insertsずQcache_not_cached、およびQcache_lowmem_prunesキャッシュからキャッシュされた芁求の数ずQcache_free_memoryの比率です。



これらの統蚈をずきどき芋るのではなく、分析を手元に甚意するこずをお勧めしたす。 さたざたな監芖ツヌルを䜿甚しお収集できたす。 たずえば、Munin











ダむナミクスのグラフを芋るず、たずえば1日に1回、最終的に1぀のサヌバヌのこれらの蚭定で十分であるずいう結論に達したした。



 query_cache_size = 128M query_cache_limit = 2M
      
      







もちろん、おそらくあなたのプロゞェクトにずっおは状況は異なるでしょう。



2. innodb_buffer_pool_size



バッファヌプヌルのサむズは、InnoDBの最も重芁な蚭定の1぀です。 これは、デヌタキャッシュずテヌブルむンデックスの䜜業䞭にMySQLが䜿甚するメモリバッファヌのサむズですMySQLずオペレヌティングシステムによるダブルキャッシュを回避するために、蚭定でinnodb_flush_method = O_DIRECTを指定する䟡倀があるこずをすぐに思い出したす。



MySQL開発者の偎から芋た最倧の犯眪の1぀は、デフォルト倀を8Mに蚭定するこずです。 :)



実際、理想的には、 innodb_buffer_pool_sizeの倀は、デヌタベヌス党䜓がメモリに収たるようにする必芁がありたす。 同時に、システムはメモリずバランスが取れおいるこずを芚えおおくこずが重芁ですこれに぀いおは前回の蚘事で説明したした  -innodb_buffer_pool_sizeの倀を「匕き裂いお」、システム党䜓がスワップするようになるず、䜕もうたくいきたせん。



適切なセットアップの良い指暙は、バッファプヌルのヒット率です。



 mysql> SHOW ENGINE InnoDB STATUS\G ... ---------------------- BUFFER POOL AND MEMORY ---------------------- ... Buffer pool hit rate 994 / 1000, young-making rate 6 / 1000 not 0 / 1000 ...
      
      







倀が「1000/1000」に近い堎合-すべおは順調です。 それ以倖の堎合は、 innodb_buffer_pool_sizeを増やす必芁がありたす。 十分なメモリがない堎合は、メモリを远加したす。



3. innodb_buffer_pool_instances



デフォルトでは、InnoDBはバッファヌプヌルに1぀のむンスタンスを䜿甚したす。



同時に、耇数のブロックを遞択するこずができたす。MySQLは、InnoDBでそれらのブロックをより効率的に䜿甚する堎合がありたす。



バッファヌプヌルは、2 GBを超える堎合、いく぀かのむンスタンスに分割する必芁がありたす。 各むンスタンスのサむズは1 GB以䞊の䟡倀がありたす。



ここに、倚くの人が混同しおいる重芁な質問がありたす innodb_buffer_pool_sizeはプヌルの合蚈サむズですか、それずも1぀のむンスタンスのサむズですか



答えはドキュメントにありたす-これは合蚈サむズです。 したがっお、たずえば、次のような構成がありたす。



 innodb_buffer_pool_size = 4096M innodb_buffer_pool_instances = 4
      
      







...各むンスタンスが1 GBを占有するず蚀いたす。



むンシデントがないこずに泚意しおくださいMySQL DBAにサブスクラむブしおいる友人の1人が、蚭定innodb_buffer_pool_size = 1024M、innodb_buffer_pool_instances = 64-64 GBの割り圓おを蚈画しおMySQLを操䜜した経隓を説明したした。



4. innodb_io_capacity



興味深いパラメヌタ公匏ドキュメントを信じおいる堎合:)、パフォヌマンスにはあたり圱響したせんが、実際には正しく蚭定されおいればある皋床の利益が埗られたす。



innodb_io_capacityは、バックグラりンドで実行されるInnoDB操䜜たずえば、バッファヌプヌルからディスクぞのペヌゞのダンプの入出力操䜜IOPSの制限を蚭定したす。



デフォルト倀は200です。



倀が小さすぎるず、これらの操䜜が「遅れ」たす。 倧きすぎるず、バッファプヌルからのデヌタがすぐにフラッシュされたす。



理想的には、ディスクシステムの実際のパフォヌマンスに察応する倀を蚭定する必芁がありたす再び、IOPSで。



5. innodb_file_per_table



デフォルトでは、InnoDBのMySQLはすべおのテヌブルのデヌタずむンデックスを1぀のテヌブルスペヌスibdata1ファむルに保存したす。



蚭定でinnodb_file_per_tableオプションが䜿甚されおいる堎合、この堎合、デヌタずむンデックスが保存されおいるテヌブルごずに個別のファむルtable_name.ibdが䜜成されたす。



これは理にかなっおいたすか



私個人の意芋では、暙準のMySQLを䜿甚する堎合、䜿甚する必芁はありたせん。 テヌブルを別々のファむルに保存するず、パフォヌマンスが䜎䞋する可胜性がありたす。これは、システム内でリ゜ヌスを倧量に消費する「高䟡な」操䜜が劇的に増えるためです。



私たちはPercona Serverを䜿甚しおいたす。 そしお、 innodb_file_per_tableを䜿甚したす 。





6. max_connect_errors



別の犯眪者:) MySQL開発者の陰謀。 max_connect_errorsのデフォルト倀は10です。



これは、倚かれ少なかれアクティブなプロゞェクトで、予期しない障害が発生した堎合-短期的なものたずえば、スクリプトに誀ったパスワヌドが入力された、たたはネットワヌクの問題が発生した堎合-ブロックされたす。 MySQLサヌバヌが再起動されるか、FLUSH HOSTSコマンドが実行されるたで。



これは、手動介入の前FLUSH HOSTSを数分ごずに実行するスクリプトを事前にcronに投皿しなかった堎合のみ:)プロゞェクトが機胜しないこずを意味したす。 これが倜間に発生し、24時間監芖されおいない堎合は䞍快です。



事前に自分自身を保護し、 max_connect_errorsの倀を倧きく蚭定するこずをお勧めしたす。 䟋



 max-connect-errors = 10000
      
      







7.䞀時テヌブル



システム内のRAMの容量が蚱す堎合は、垞にメモリ内の䞀時テヌブルを操䜜するこずをお勧めしたす。



これを敎理するのは簡単です。 MySQLの蚭定



 tmpdir = /dev/shm
      
      







ファむルシステムずパヌティションの蚭定Linuxの堎合-/ etc / fstabファむル



 # <file system> <mount point> <type> <options> <dump> <pass> tmpfs /dev/shm tmpfs defaults 0 0
      
      







8.䞀時テヌブルのサむズ



メモリ内のテヌブルのサむズを担圓する同様のパラメヌタヌが2぀ありたす。



 max_heap_table_size = 64M tmp_table_size = 64M
      
      







max_heap_table_size-ナヌザヌが䜜成できるMEMORYタむプのテヌブルの最倧サむズ。

tmp_table_size-メモリ内に䜜成される䞀時テヌブルの最倧サむズディスク䞊。



ディスクアクティビティが少ないほど優れおいたす。 したがっお、システム内のRAMの量が蚱容する堎合メモリバランスを芚えおおいおください、メモリ内のすべおの䞀時テヌブルを操䜜するこずをお勧めしたす。



9. table_cacheおよびtable_definition_cache



 table_cache = 4096 table_definition_cache = 4096
      
      







これらの2぀のオプションは、開いおいるテヌブルのキャッシュに保存されるテヌブルの最倧数を決定したす。



table_cacheの倀は、システム内のテヌブルの数、ク゚リで開くテヌブルの数たずえば、JOINを介しおリンクされる、およびデヌタベヌスぞの開いおいる接続の数に盎接䟝存したす。



table_definition_cacheは、テヌブル構造.frmファむルのキャッシュサむズを定矩したす。 システム内にあるほど、 table_definition_cacheの倀を倧きく蚭定する必芁がありたす。



10.長いリク゚ストの闘争



前回の蚘事では、Percona Serverがシステム党䜓のパフォヌマンスを刀断するための優れたツヌル SELECT * FROM INFORMATION_SCHEMA.QUERY_RESPONSE_TIME を持っおいるこずを既に述べたした。



さらに、どのMySQLでも、すべおの「遅い」ク゚リをログに蚘録し、個別に解析するこずができたす。



Percona Serverを䜿甚するず、遅いク゚リのログがより有益になりたす。



 log_output = FILE slow_query_log = 1 slow_query_log_file = mysql_slow.log long_query_time = 1 #percona log_slow_verbosity = microtime,query_plan,innodb
      
      







1秒より長く実行されるすべおのク゚リは、mysql_slow.logに曞き蟌たれたす。 暙準ログずは異なり、次のようになりたす。



 # Time: 120712 9:43:47 # User@Host: user[user] @ [10.206.66.207] # Thread_id: 3513565 Schema: user Last_errno: 0 Killed: 0 # Query_time: 1.279800 Lock_time: 0.000053 Rows_sent: 0 Rows_examined: 1 Rows_affected: 0 Rows_read: 0 # Bytes_sent: 52 Tmp_tables: 0 Tmp_disk_tables: 0 Tmp_table_sizes: 0 # InnoDB_trx_id: 33E7689B # QC_Hit: No Full_scan: No Full_join: No Tmp_table: No Tmp_table_on_disk: No # Filesort: No Filesort_on_disk: No Merge_passes: 0 # InnoDB_IO_r_ops: 0 InnoDB_IO_r_bytes: 0 InnoDB_IO_r_wait: 0.000000 # InnoDB_rec_lock_wait: 0.000000 InnoDB_queue_wait: 0.000000 # InnoDB_pages_distinct: 4 UPDATE b_user_option SET 'COMMON' = 'N', 'VALUE' = 'a:19', 'NAME' = 'openTab', 'CATEGORY' = 'IM' WHERE ID=1719;
      
      







ク゚リの実行時間、「スキャンされた」行の数などだけでなく、より詳现な情報-フルスキャン、䞀時テヌブルの䜿甚、InnoDBのステヌタスも確認できたす。



これはすべお、遅いク゚リずそのデバッグの分析に倧いに圹立ちたす。



11. Perconaを䜿甚しない詳现な統蚈



暙準のMySQLを䜿甚しおいる堎合でも、優れたク゚リデバッグツヌルもありたすもちろん、既に「キャッチ」しお識別しおいる堎合:)。たずえば、スロヌク゚リの同じログを䜿甚したす。



プロファむルのようなものがありたす。 それらを䜿甚したすか いや 無駄だ



 mysql> SHOW PROFILES; Empty set (0.02 sec) mysql> SHOW PROFILE; Empty set (0.00 sec)
      
      







プロファむリングをオンにしお、リク゚ストを確認したす。



 mysql> SET PROFILING=1; Query OK, 0 rows affected (0.00 sec) mysql> SELECT COUNT(*) FROM mysql.user; +----------+ | COUNT(*) | +----------+ | 3024 | +----------+ 1 row in set (0.09 sec) mysql> SHOW PROFILES; +----------+------------+---------------------------------+ | Query_ID | Duration | Query | +----------+------------+---------------------------------+ | 1 | 0.09104400 | SELECT COUNT(*) FROM mysql.user | +----------+------------+---------------------------------+ 1 row in set (0.00 sec) mysql> SHOW PROFILE; +--------------------------------+----------+ | Status | Duration | +--------------------------------+----------+ | starting | 0.000018 | | Waiting for query cache lock | 0.000004 | | Waiting on query cache mutex | 0.000004 | | checking query cache for query | 0.000041 | | checking permissions | 0.000007 | | Opening tables | 0.090854 | | System lock | 0.000013 | | init | 0.000012 | | optimizing | 0.000007 | | executing | 0.000010 | | end | 0.000005 | | query end | 0.000004 | | closing tables | 0.000031 | | freeing items | 0.000029 | | logging slow query | 0.000003 | | cleaning up | 0.000004 | +--------------------------------+----------+ 16 rows in set (0.00 sec)
      
      







ネットワヌク、ディスクの操䜜、キャッシュの䜿甚など、ボトルネックが䜕であるかがすぐにわかりたす。



12.プロファむルの情報を䜿甚する方法は



単䞀の長いク゚リを芋぀けるこずを孊んだ堎合それほど難しくない-遅いク゚リのログずSHOW PROCESSLISTが圹立぀、システム党䜓の状態を正しく評䟡する堎合 SELECT * FROM INFORMATION_SCHEMA.QUERY_RESPONSE_TIME 、システムの倖郚監芖、たずえばnagios- munin-分析、システムのパフォヌマンスに圱響を䞎えるものを理解するこずは非垞に重芁です







これを理解し、プロファむルたたは䜎速ク゚リの拡匵ログなどのデヌタを分析するず、デヌタベヌスを操䜜するさらなる戊略を垞に正しく評䟡できたす-その堎合、ハヌドりェアをアップグレヌドする必芁がありたす-これらたたは他の蚭定を倉曎し、おそらく-再線成デヌタおよびク゚リ構造。



* * *



あらゆるボリュヌムのあらゆる負荷でのデヌタベヌスの正垞なデバッグず正垞な操䜜 :)



* * *



この堎所を読んでくれおありがずう :)







MySQLのヒントがお圹に立おば幞いです



そしお、 Bitrix24プロゞェクトでMySQLを操䜜した経隓に぀いお話しおいるので、 Habréのブログのすべおの読者にささやかな莈り物をしたいず思いたす。



指定されたリンクでBitrix24に登録するず、2倍のディスク10 GBが無料で入手できたす



突然Bitrix24が䜕であるかわからない堎合は、 詳现な説明がWebサむトにありたす。 :)



All Articles