MySQL/最適化/サーバパラメタ - Linux Tips
ここでは、サーバパラメタの最適化によるMySQLのチューンについて紹介する。 _ パラメタのチェック 現在の設定値を確認するには、 # mysqld --help とする。 MySQL-5.xでは、 # mysqld --verbose --help としないと、確認できなかった。 あるいは、クライアントから、 mysql> SHOW VARIABLES; でもOK。 ↑ key_buffer_size † MyISAM テーブルのインデックスを保存しておくバッファの大きさ。サーバ全体で共有される。メモリに余裕があれば、MyISAMのみのMySQL専用サーバなら、RAMの1/2、Apache などと共用なら、RAM の1/4程度とする。ただし、サイズを大きくすると、OSのページングのために、逆に遅くなることもあるので注意。 set-variable = key_buffer=256M M
DSAS開発者の部屋:5分でできる、MySQLのメモリ関係のチューニング！
MySQLのチューニングにおいて非常に重要となるメモリ(バッファ)関連のパラメータについて、 チューニングのポイント DSASのとあるDBサーバ(実メモリ4GB)の実際の設定値 をまとめてみます。 また、必要メモリの総量の計算や限界値を越えてないかチェックしてくれるスクリプトも紹介します。 是非、参考にしてみてください！ まず最初に注意点を。 バッファには2つのタイプがあります。 グローバルバッファ スレッドバッファ グローバルバッファはmysqld全体でそのバッファが1つだけ確保されるもので、 これに対し、 スレッドバッファはスレッド(コネクション)ごとに確保されるものです。 チューニングの際にはグローバル/スレッドの違いを意識するようにしましょう。 なぜなら、スレッドバッファに多くのメモリを割り当てると、コネクションが増えたとたんにアッという間にメモリ不足になってしまうからです。 in
Kazuho@Cybozu Labs: MySQL のボトルネックを統計的に監視・解析する方法
MySQL のチューニング、と言った場合には、サーバーパラメータの調整や EXPLAIN コマンドを利用したクエリ実行計画の最適化が話題に上ることが多いです。しかし、発行する全ての SQL について、いちいち EXPLAIN コマンドを使って確認していては、いくら時間があってもたりません。チューニングを効率的に進めるには、まず、ボトルネックとなっている SQL クエリを特定し、次にその最適化を行うべきです。 ではどのようにして、ボトルネックを特定するのか。MySQL Conference & Expo 2009 のキーノートにおいて Mark Callaghan 氏は、Google では SHOW PROCESSLIST コマンドを使った統計的アプローチを使っていると述べていらっしゃいます (参照: MySQLConf 09: Mark Callaghan, "This is Not a
MySQL Performance Blog � Cache Performance Comparison
Jay Pipes continues cache experiements and has compared performance of MySQL Query Cache and File Cache. Jay uses Apache Benchmark to compare full full stack, cached or not which is realistic but could draw missleading picture as contribution of different components may be different depending on your unique applications. For example for application containing a lot of clode but having only couple
MySQL
HeatWave Use automated and integrated generative AI and machine learning (ML) in one cloud service for transactions and lakehouse scale analytics. Get faster insights from all your data with unmatched performance and deploy apps in your choice of cloud providers. Learn More » MySQL Enterprise Edition The most comprehensive set of advanced features, management tools and technical support to achieve
１人で稼ぐ日記 | MySQL：１台しかない環境でエセ負荷分散
MySQLのネタ。 １台しかない環境でエセ負荷分散を行う。 MySQLで負荷分散を考えたとき、 １台目にマスターのＤＢサーバー、 ２台目以降をスレーブのＤＢサーバーとして用いる。 マスターは更新系のみのＳＱＬ文を、 スレーブは参照系のみのＳＱＬ文を投げる。 こんな負荷分散を１台のサーバーで行う必要が出てきた。 現在１台でやっていて、ディスクＩＯが追いつかずに捜し求めた結果、下の形で落ち着いた。 １つのテーブルでインデックスを含めたサイズが 30MB〜100MBほどで安定している、という条件があるのですが かなり負荷下がります。 ※上記サイズは搭載メモリサイズによって変わります -------------------------- ■やりかた 負荷が高いテーブルをＡとする １：Ａと同じテーブル構成で、エンジンをMEMORY(he
Kazuho@Cybozu Labs: MySQL (InnoDB) に直接アクセスしてタイムライン処理を高速化する話
« フレンド・タイムライン処理の原理と実践 | メイン | MySQL の ORDER BY を高速化 » 2008年06月12日 MySQL (InnoDB) に直接アクセスしてタイムライン処理を高速化する話 フレンド・タイムライン処理の原理と実践 の続きです。 先のエントリでは、プルモデルの速度が当初予測していたよりも遅かった (というより SQL レイヤでのオーバーヘッドが大きそうだった) ので、MySQL Internals メーリングリストで質問したりしながら、C++ で直接 InnoDB にアクセスするようなコードを書いてみました。 タイムライン構築速度 タイムライン/秒 SQL そしたら、10倍以上高速に！ ベンチマークを perl ベースのものから mysqlslap に変えたのですが、プッシュモデルの 2/3 の速度が出ています。これなら、データサイズが約 1/10 にな
Kazuho@Cybozu Labs: フレンド・タイムライン処理の原理と実践
« MySQL のクエリ最適化における、もうひとつの検証方法 | メイン | MySQL (InnoDB) に直接アクセスしてタイムライン処理を高速化する話 » 2008年06月09日 フレンド・タイムライン処理の原理と実践 MySQL (InnoDB) に直接アクセスしてタイムライン処理を高速化する話に続きます。 Twitter が注目されるようになって久しい今日この頃ですが、友人の投稿を時系列に並べて表示する、というのは、Twitter に限らず Mixi の「マイミクシィ最新日記」やはてなブックマークの「お気に入り」等、ソーシャルなウェブサービスにおいては一般的な手法です。ですが、この処理 (以下「フレンド・タイムライン」と呼ぶ) は、一見簡単そうに見えて、実装には様々な困難が伴います。本記事では、「フレンド・タイムライン」を実現する、プッシュ型とプル型の二種類の手法について、その原
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.mysql.gr.jp/Manual/mysql-3.21.31/manual_Performance.html