MySQL5.6と5.7のちょっとした違いとinnodb_thread_concurrencyの影響 - hiroi10のブログ
この記事はMySQL Casual Advent Calendar 2016の22日目です。 innodb_thread_concurrencyを最近のデフォルトである0と論理CPUコア数の2倍の48に設定した場合に観測出来た小ネタです。ベンチマークのtpsを載せていますが、1回しか取得してないので、割と誤差があると考えられるため、目安程度に見てください。 環境 CentOS 6.6(2.6.32-504.12.2.el6.x86_64) Xeon E5-2643 v2 3.5GHz x 2(2P12C24T) Memory 64GB (8GB x 8, DDR3 1866MHz) HDD SAS 300GB x 2 10k rpm(RAID1 BBU付き) FileSystem ext4 ベンチマークのデータ量はinnodb_buffer_pool_sizeに収まる量 メモリで殴るような
MySQL5.7でInnoDBのTransparent Page Compressionを試してみる Part2 - hiroi10のブログ
これはMySQL Casual Advent Calendar 2015の21日目のエントリです。 Part1に続いての内容となります。 今回の計測パターン Part1ではデータ・INDEXが全てinnodb_buffer_pool_sizeに収まる量でしたが、今回は収まらない量、実サイズで141GBのデータで計測。 LinkBenchの実行オプションは前回と同じです # ./bin/linkbench -c config/MyConfig.properties -D maxtime=3600 -D requests=10000000 -D requesters=64 -r パラメータについて 最後にまとめますが、結構変更しました。無圧縮であれば変える事なく安定した性能を出せたのですが、やはりreadの展開負荷が増えるとパラメータ変更しないとどうにもならない感じでした。まだ改善出来そうな気
MySQL関連のパラメータ(主にInnoDB)について - hiroi10のブログ
このエントリはMySQL Casual Advent Calendar 2015の10日目のエントリです。 先日のMySQL Casual Talks Vol8で@karupaneruraさんがパラメータの振り返りのような発表をされていたので、昨今あまり書かれなくなったMySQLに絡む設定パラメータについて書きます。それなりのメモリ(32GBとか)やSSDとか使ってる事を前提にしたような内容となります。 依存して変更した方が良いパラメータもあるので内容が前後に飛びますがご容赦下さい。またソースコードをがっつり読んだわけではなく、ベンチマーク中の挙動から推測している箇所が多分にあります。MyISAMのテーブルがサービス用データベースに同居する事を考慮していません。 結構突貫で書いているので後から微妙に修正する可能性があります。 InnoDBのパラメータ innodb_buffer_pool_
MySQL5.7でInnoDBのTransparent Page Compressionを試してみる Part1 - hiroi10のブログ
このエントリはMySQL Casual Advent Calendar 2015の6日目のエントリです。 Part1としているのは12/21にPart2を公開予定のためです。 InnoDBのTransparent Page Compression MySQL 5.7からInnoDBにTransparent Page Compressionという圧縮機能が追加されました。InnoDBの圧縮機能はMySQL 5.1のInnoDB Pluginから使用可能でしたが、これまでのInnoDB圧縮と違い、Transparent Page Compressionは使用環境の制限があります。具体的にはFileSystemがhole punchingをサポートしている必要があります。 MySQL Server Blogからの抜粋ですが以下のようにKernelのバージョン制限があります。 ※InnoDB Tr
MySQL Casual Talks Vol.8 でMySQL 5.7とMariaDB 10.1の性能比較について発表しました - hiroi10のブログ
はじめに 遅くなりましたが11/20(金)に開催されたMySQL Casual Talks Vol.8で以下スライドで発表しました。その内容の補足とかを載せておきます。 MySQL5.7とMariaDB10.1の性能比較(簡易) from hiroi10 最近MariaDB 10.1がGAになり、MySQL 5.7がGAになり、MariaDBってどうなん？、とか聞かれる事が増えたためとりあえずベンチマークで性能比較してみよう、が発端でした。MariaDBの10系はMySQL 5.5をベースにしているということで正直あまり期待していなかったのですが、起動時のログを見るとInnoDBはPerconaのXtraDB5.6ベースだったのでPercona5.6と同じ傾向かなぁという想像で実施しましたが概ね同じ傾向となりました。 まず、私はMariaDB10系はまともに触ったことがなかったので変だなと
nginxのログに499(レスポンスコード)が記録される場合 - hiroi10のブログ
最近nginxのログに499とかいう見慣れないレスポンスコードが記録されていたのでどういう状況で記録されるのか試してみた。 499が定義されてる場所 ソースコードの以下ファイルに記載されています。 {ソース展開dir}/src/http/ngx_http_request.h 中身を抜粋したのは以下 /* * HTTP does not define the code for the case when a client closed * the connection while we are processing its request so we introduce * own code to log such situation when a client has closed the connection * before we even try to send the HTTP h
rowベースのレプリケーション時にステートメントもバイナリログに保存する - hiroi10のブログ
MySQL5.6からrowベースのレプリケーションを使用している場合でもステートメント(クエリ)をコメントとしてバイナリログに記録するオプション(binlog_rows_query_log_events)が追加されています。 このオプションを利用することでrowベースでレプリケーションされたクエリが確認し易くなります。 マニュアル binlog_rows_query_log_events 動作確認環境 CentOS 6.3 x86_64(KVMゲスト) MySQL 5.6.10 binlog_rows_query_log_eventsが無効な場合 mysqlbinlogコマンドに-vオプションを使う事である程度は把握が可能でした。以下例はbinlog_rows_query_log_eventsが無効な場合の表示例です。 テーブル定義と設定 mysql> show create table
performance_schemaによる秒間接続数の性能差 - hiroi10のブログ
前回はperformance_schema(以下p_s)の無効、有効、有効でsetup_instrumentsテーブルのENABLED列を全てNOにした場合の性能測定を行いました。こちらは結果としてsetup_instrumentsテーブルのENABLED列を全てNOにするとp_sをOFFにした場合とあまり性能が変わらない所まで改善する事が確認出来ました。 p_sが有効にすると性能が下がるというのは松信さんのブログでも書かれているのでご存知の方も多いかと思います。今回はsetup_instrumentsテーブルの設定のより秒間接続数に差が出るか確認を行いました。 ベンチマーク環境は基本前回と同じです。但し、リモートからTCPにより接続する一般的なWEB・DBサーバの環境となるようにしています。今回はNICの情報等も追記しました。 ベンチマーク環境・サーバ側(OS/HW) CentOS re
performance_schemaのsetup_instrumentsテーブルによる性能差 - hiroi10のブログ
先日のMyNA会(2013年7月)の際に@sheeriさんがperformance_schema(以下p_s)について発表されていた際に取得項目がsetup_instrumentsテーブルで制御出来るようなお話をしていました。 MySQL5.6ではp_sが有効だと性能が1割程度落ちたりするというのは最近では割と良く知られてきている話しだと思います。p_sが有効な状態でsetup_instrumentsテーブルで全部取得しないようにした場合にどの程度の性能差が出るか試してみました。 ベンチマーク環境(OS/HW) CentOS release 6.4 (Final) 2.6.32-358.14.1.el6.x86_64 Intel(R) Xeon(R) CPU E5-2630 0 @ 2.30GHz x 2(HT有効) DDR3 1333 MHz ECC 8GB x 8 SSD / Inte
gtidを使用した環境でのmysqldump - hiroi10のブログ
以前の日記Global Transaction IDを使ってレプリケーション構成とした際の制限でmysqldumpから新規にスレーブを作ろうとするとgtidが記録されなくてバイナリログ使わないとダメ、と書いたんだけど、5.6.10で試したら普通にスレーブを作成可能だったので訂正も含めて書きます。 環境 CentOS6.3 x86_64(KVM guest) MySQL 5.6.10 よくあるmysqldump MySQL5.5系まででgtidが存在しない環境では良く以下のようにmysqldumpを実行しているかと思います(InnoDBのみ利用の場合)。 # mysqldump --all-databases --single-transaction --master-data=2 > /path/to/dir/dump または # mysqldump --all-databases --s
Global Transaction IDを使ってレプリケーション構成とした際の制限 - hiroi10のブログ
2012/11/08に一部追記しました。 Global Transaction IDを有効にしてレプリケーション構成とした際の制限について簡単にまとめてみる。微妙な訳になっている部分もあるだろうし、勘違いしてる箇所もあるかもしれないのでご注意下さい。 よって、アレ？、というのがありましたら基本的には公式ドキュメントを参照して下さい。 むしろ誤りあったら突っ込んでもらえると助かります。 前提 MySQL5.6 RC版(5.6.7-rc)でgtidを使ったレプリケーション環境で確認 トランザクションが使えないストレージエンジンは使用出来ない(MyISAM等) 前の日記でも書いていますが、以下のようにエラーとなります。 ERROR 1785 (HY000): Updates to non-transactional tables are forbidden when DISABLE_GTID_U
MySQL5.6で増えたexplicit_defaults_for_timestamp - hiroi10のブログ
あまりぐぐっても出てこなかったので簡単に書いてみる。 MySQL5.5のmy.cnfをそのまま流用してMySQL5.6を起動すると以下のようなメッセージがエラーログファイルに出力される。長いので改行していますが実際は一行。 121104 22:29:57 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for more details).こちらはMySQL 5.6.6から追加されたexplicit_defaults_for_timestampによるもの。 booleanでデフォルトはFALSE(0)。動的変更は不可となります。公式Doc とりあえずFALSEの
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
