web-dev-qa-db-ja.com

mysql 5.5のmy.cnfは以下のハードウェア仕様に適しており、適切に調整されていますか？

私のハードウェア仕様

Technology: Ivy Bridge
CPU: Intel Xeon E3 1245v2 
Intel Smart Cache: 8MB
Cores / Threads: 4 / 8
Frequency: 3.4GHz+ / 3.8GHz Turbo Boost
RAM: 32 GB DDR3
Hard disk: 2x 2TB SATA3
Raid 1 by software
Bandwidth: 100 Mbps guaranteed

[〜＃〜] os [〜＃〜]

ubuntu 12.04.2 LTS 64ビットサーバーエディション

Mysql

バージョン5.5.29、64ビット

私のアプリケーションアーキテクチャ

https://stackoverflow.com/questions/11272776/using-phusion-passenger-nginx-running-same-Rails-app-with-multiple-instance

したがって、私のサーバーには100のmysqlデータベースを持つ100Railsアプリが含まれ、各データベースには約100のテーブルがあります

サーバーへのトラフィック

1秒あたり10〜200（最大）リクエスト

1日あたり3000〜10,000（最大）リクエスト

MysqlとRails間の接続

ソケットを使用しますsocket = /var/lib/mysql/data/mysql.sock

上記のハードウェア仕様に対して https://tools.percona.com/wizardによって生成されたmy.cnf

[mysql]

# CLIENT #
port                           = 3306
socket                         = /var/lib/mysql/data/mysql.sock

[mysqld]

# GENERAL #
user                           = mysql
default_storage_engine         = InnoDB
socket                         = /var/lib/mysql/data/mysql.sock
pid_file                       = /var/lib/mysql/data/mysql.pid

# MyISAM #
key_buffer_size                = 32M
myisam_recover                 = FORCE,BACKUP

# SAFETY #
max_allowed_packet             = 16M
max_connect_errors             = 1000000
skip_name_resolve
innodb                         = FORCE
innodb_strict_mode             = 1

# DATA STORAGE #
datadir                        = /var/lib/mysql/data/

# BINARY LOGGING #
log_bin                        = /var/lib/mysql/data/mysql-bin
expire_logs_days               = 14
sync_binlog                    = 1

# CACHES AND LIMITS #
tmp_table_size                 = 32M
max_heap_table_size            = 32M
query_cache_type               = 0
query_cache_size               = 0
max_connections                = 500
thread_cache_size              = 50
open_files_limit               = 65535
table_definition_cache         = 4096
table_open_cache               = 10240

# INNODB #
innodb_flush_method            = O_DIRECT
innodb_log_files_in_group      = 2
innodb_log_file_size           = 512M
innodb_flush_log_at_trx_commit = 1
innodb_file_per_table          = 1
innodb_buffer_pool_size        = 26G

# LOGGING #
log_error                      = /var/lib/mysql/data/mysql-error.log
log_queries_not_using_indexes  = 1
slow_query_log                 = 1
slow_query_log_file            = /var/lib/mysql/data/mysql-slow.log

innodb_buffer_pool_size = 26Gなので、32 GBでRAMmysqlは少なくとも27〜28 GBを使用するため、100を実行するためのスペースは少なくなりますRailsアプリ、なので、誰かが私のmysql設定を編集して最適化してくださいmy.cnfPastebin に投稿されました、mysqlとRailsアプリケーションの両方を実行するための十分なスペースと速度を取得します。

1つのマシンで100Railsアプリケーションで接続する100個のデータベースを使用することを計画していたため、接続にmysqlソケットを使用します。

更新

アプリケーションの詳細情報

私のアプリケーションはミッションクリティカルなアプリケーションではなく、学校向けの学生情報システムにすぎません。 1日2回webminを介してスケジュールされたリモートFTPへのMySQLのバックアップなので、1つのサーバーに100の学校を配置することを計画したので、100Railsアプリ+対応する100のmysqlデータベース

現在、アプリケーションは実行されていません。現在、本番環境のセットアップ段階にあるので、Railsとmysqlの同等のリソース処理を検討する my.cnf についていくつかの提案が必要です。

mysqlinnodbmysql-5.5database-tuningmy.cnf
4
Sam

検討する必要があるいくつかのオプションがあります

InnoDBバッファープール

26Gが選択された理由は、32GBのRAMがあり、その80％が25.6 Gであることです。これを100のデータベースと100のアプリケーションがあり、これをマルチテナントDBサーバーにすると言ったので、 InnoDBバッファープールを適切に取得する必要があります。

このクエリを実行してください：

SELECT IFNULL(B.engine,'Total') "Storage Engine",
CONCAT(LPAD(REPLACE(FORMAT(B.DSize/POWER(1024,pw),3),',',''),17,' '),' ',
SUBSTR(' KMGTP',pw+1,1),'B') "Data Size", CONCAT(LPAD(REPLACE(
FORMAT(B.ISize/POWER(1024,pw),3),',',''),17,' '),' ',
SUBSTR(' KMGTP',pw+1,1),'B') "Index Size", CONCAT(LPAD(REPLACE(
FORMAT(B.TSize/POWER(1024,pw),3),',',''),17,' '),' ',
SUBSTR(' KMGTP',pw+1,1),'B') "Table Size" FROM
(SELECT engine,SUM(data_length) DSize,SUM(index_length) ISize,
SUM(data_length+index_length) TSize FROM
information_schema.tables WHERE table_schema NOT IN
('mysql','information_schema','performance_schema') AND
engine IS NOT NULL GROUP BY engine WITH ROLLUP) B,
(SELECT 3 pw) A ORDER BY TSize;

これにより、MySQLインスタンスによって現在占有されている容量がわかります。 InnoDBデータサイズとインデックスサイズの合計が何であれ、それを使用します。その合計が80％の制限を超えている場合は、80％にする必要があります（26Gで innodb_buffer_pool_size を残します）。

クアッドコアサーバーを使用しているため、 innodb_buffer_pool_instances を4に設定します。

InnoDBトランザクションログファイル

26Gが innodb_buffer_pool_size として選択されているため、可能な限り最大のトランザクションログが必要になります。 innodb_log_file_size には、おそらく512Mの値が選択されています。トランザクションデータの量（バイト単位）を示唆するものがないためです。実際に処理されます。

トランザクションログのサイズを変更するには

mysql -u... -p... -e"SET GLOBAL innodb_fast_shutdown = 0;"
service mysql stop

次の編集my.cnf、置換

innodb_log_file_size           = 512M

これとともに

innodb_log_file_size           = 2047M

次に、このようにトランザクションログを置き換えます

mv /var/lib/mysql/ib_logfile0 /var/lib/mysql/ib_logfile0.bak
mv /var/lib/mysql/ib_logfile1 /var/lib/mysql/ib_logfile1.bak
service mysql start

数か月間のピークアクティビティの後、ピーク時にこのクエリを実行できます。

SET @TimeInterval = 300;
SELECT variable_value INTO @num1 FROM information_schema.global_status
WHERE variable_name = 'Innodb_os_log_written';
SELECT SLEEP(@TimeInterval);
SELECT variable_value INTO @num2 FROM information_schema.global_status
WHERE variable_name = 'Innodb_os_log_written';
SET @ByteWrittenToLog = @num2 - @num1;
SET @KB_WL = @ByteWrittenToLog / POWER(1024,1) * 3600 / @TimeInterval;
SET @MB_WL = @ByteWrittenToLog / POWER(1024,2) * 3600 / @TimeInterval;
SET @GB_WL = @ByteWrittenToLog / POWER(1024,3) * 3600 / @TimeInterval;
SELECT @KB_WL,@MB_WL,@GB_WL;

戻ってきたことに基づいて、トランザクションログのサイズを再度変更する必要があります。

これを行うことに関する私の以前の投稿を参照してください：

マルチコアエンゲージメント

MySQL 5.1.38でInnoDBプラグインが導入されたとき、それはMySQLの世界に火をつけました。どうして？ InnoDBがシングルスレッドだったからです。 InnoDBが複数のコアを使用できるようにする新しい設定を行うには、プラグインをインストールする必要がありました。

長いものを書くのではなく、MySQL 5.5を微調整してInnoDBに複数のコアを利用させる私の以前の投稿を読んでください。

2
RolandoMySQLDBA
# BINARY LOGGING #
log_bin                        = /var/lib/mysql/data/mysql-bin
expire_logs_days               = 14
sync_binlog                    = 1

# LOGGING #
log_error                      = /var/lib/mysql/data/mysql-error.log
log_queries_not_using_indexes  = 1
slow_query_log                 = 1
slow_query_log_file            = /var/lib/mysql/data/mysql-slow.log

データディレクトリにログを保存したくない。 mysqlを起動すると、「mysql-bin」データベースが表示されます。起動時にエラーログに不要なエラーが表示される可能性があります。できるだけクリーンな状態にしておくと、何かが表示されたときに注意を払うことができます。

とにかく/ var/logにログを置くことは一般的な慣習です。さらに、可能な場合は、ログファイルシステムをデータディレクトリとは別のスピンドルセットに配置することをお勧めします。それが可能であるようには思えませんが、たとえ同じ基礎となるディスク上にある場合でも、データディレクトリを保持し、異なるファイルシステムにログを記録することで、いくつかの利益が得られる可能性があります。

Expire_logs_daysは、スレーブが最新であるかどうかに関係なく、バイナリログを消去することに注意してください。 14日以上使用されていない壊れたスレーブがある場合は、大きな問題が発生します。一般に、バックアップスケジュールに基づいて新しいスレーブを簡単に起動できるように、十分なbinlogバッファーを保持する必要があります。

Binlogをより永続的なアーカイブサーバーにオフロードし、パージを管理するアーカイブスクリプトを用意することを検討してください。

1
atxdba