IBM Developer is your one-stop location for getting hands-on training and learning in-demand skills on relevant technologies such as generative AI, data science, AI, and open source.
KLab Advent Calendar 2011 「DSAS for Social を支える技術」の5日目です。 @methane による MySQL を骨までしゃぶるチューニングシリーズ (シリーズ名は今考えました)のまとめとして、現在の DSAS for Social の MySQL のリアルな性能値や直面しているボトルネックを赤裸々に公開 してしまいます。 innodb_io_capacity を増やそう 本題に入る前に、まだ紹介してないけど1記事にするほどではなかった パラメータを紹介しておきます。 innodb_io_capacity は、 InnoDB に教えるヒントで、 Disk の IO/sec を指定します。 デフォルトでは、通常のHDDでも使えるように中途半端な値(バージョンによって100か200) になっているのですが、BBU付きバッファがあるRAIDカードを使うな
“MySQL Casual Advent Calendar 2011” 7 日目を担当させていただく、hatak (@hisashi) です。 普段はモバイルゲームのインフラをメインにみているのですが、今回はそんな業務で経験したことを基に記事を書かせていただきます。 カジュアルすぎる内容かもしれませんが、お付き合いいただければと思います。 MySQL のレプリケーション MySQL のレプリケーションは、安定稼働やバックアップ、負荷分散などの目的に利用できる優れた機能です。 bin-log (バイナリログ) を利用して Master サーバから Slave サーバに更新を伝播させ、データの複製を行います。Slave サーバでは、2 つのスレッドが動作しています。 IO_THREAD – Master から送られてきたデータを受け取り、relay-log (リレーログ) として書き出す SQ
KLab Advent Calendar 2011 「DSAS for Social を支える技術」の3日目は、 引き続き MySQL 周りのチューニングノウハウとして、すぐに役立つ プロファイリング方法を紹介します。 DBサーバーの負荷が高い時、 slow_log を見て問題になっている重いクエリを 発見するのが一般的かもしれませんが、 slow_log に一切ログが残らないのに 負荷が高い状況や、むしろ負荷が高すぎてごく一般的でどう考えても遅いはずが ないクエリ ("SET NAMES utf8" や "BEGIN") すら slow_log に大量に乗ってしまう場合が あります。 slow_log 以外で問題になっているクエリを見つける方法として、 "SHOW FULL PROCESSLIST" コマンドがあります。これを数回〜数十回叩いてみて、 よく出ているクエリは、遅かったり量が
KLab Advent Calendar 2011 「DSAS for Social を支える技術」の2日目は、昨日に引き続き、MySQLを骨までしゃぶるためのテクニックです。 ソーシャルゲームは一般サイトよりもDBへの更新クエリの割合が多くなりがちです。更新クエリが多いMySQLでは、通常は有益なクエリキャッシュが無益どころか有害になります。 そもそもキャッシュヒット率が低い。20%以下なんてこともザラにある しかもクエリキャッシュの更新はグローバルなロックを取得する からです。特に後者は問題です。ただの参照クエリもクエリキャッシュを更新する上に、更新クエリはクエリキャッシュの全エントリをチェックして、更新したテーブルに影響がありそうな全キャッシュをdiscardしていくためです。たとえばユーザーの行動力のようなパラメータを格納した参照も更新も多いテーブルでクエリキャッシュが有効になって
「DSAS for Social を支える技術」 というネタでadvent calendar に挑戦します。 methane です。 PDOで MySQL を使うときは、みなさん $stmt = $con->prepare("..."); して $stmt->execute($values); とかしてプリペアドステートメントを利用されていると思います。 実は、このプリペアドステートメント、パフォーマンス的にはあまり良くありません。1つのクエリを実行するために、プレースホルダ付きのクエリを投げた後に、それに値をバインドして実行するコマンドを投げるので、1回のクエリを実行するのに2往復の通信が必要になるのです。 プリペアドステートメントにはパフォーマンスの利点(同じクエリを何度も発行するときにDBサーバーがクエリの解析を繰り返さないでもすむ)というものと、SQLインジェクション対策になる(正
グーグルは同社のクラウドでリレーショナルデータベース機能を利用できるサービス「Google Cloud SQL」を公開しました。Google Labsの扱いで、限定プレビューとなっています。 グーグルはGoogle Cloud SQLを次のように紹介しています。 By offering the capabilities of a MySQL database, the service enables you to easily move your data, applications, and services into and out of the cloud. (略) To ensure that your critical applications and services are always running, Google Cloud SQL replicates data to
写真●左から米Calpont CEO Jeff Vogel氏、アシスト 代表取締役 ビル・トッテン氏、SkySQL CEO Ulf Sandberg氏、アシスト 取締役 勝田誠氏 アシストは2011年11月8日、フィンランドSkySQLとMySQLおよびMariaDBのサポートに関する独占的業務提携を結んだと発表した。SkySQLはMySQLの元社員らが設立した企業で、MariaDBはMySQLをベースにした互換DBMS(データベース管理システム)。また米Calpontとカラム指向DB「Calpont InfiniDB」に関する総代理店契約を結んだことも明らかにした。 SkySQLは、Sun Microsystemsが米Oracleに買収された後、MySQLの元社員らが設立した。CEOであるUlf Sandberg氏は、元MySQLの副社長。「SkySQL社員のMySQLでの経験年数を合計
Report a Bug Before you report a bug, please make sure to do the following: Use the search form or the advanced search page to make sure nobody has reported the bug already. Make sure you are using the latest production version if similar bugs have recently been fixed. Read our tips on how to report a bug. Once you've double-checked that the bug you've found hasn't already been reported, and that
MySQL 5 からテーブルごとに文字列のエンコーディングを指定できるようになった (「そんなことは知ってるYO!」という人も多いと思うので、 そういう人は「これからが本題」 の部分まで読み飛ばして欲しい)。 例えばテーブルを作るときに、 mysql> CREATE DATABASE test; Query OK, 1 row affected (0.05 sec) mysql> USE test Database changed mysql> CREATE TABLE user ( name VARCHAR(255) ) CHARSET=utf8; Query OK, 0 rows affected (0.05 sec) などと 「CHARSET=utf8」 を指定すれば、 文字列を UTF-8 エンコーディングで格納する。 「CHARSET」 すなわち 「文字集合」 と、 エンコーディ
レプリケーション元の設定 † my.cnfでバイナリログを有効化する log-bin=mysql-bin サーバIDをmy.cnfで確認しておく server-id = 1 レプリケーション専用ユーザーの作成 # mysql -u root -p mysql> GRANT REPLICATION SLAVE ON *.* TO [email protected]'%' IDENTIFIED BY '******'; MASTER STATUSを確認(テーブルをロックして実行) mysql> FLUSH TABLES WITH READ LOCK; mysql> SHOW MASTER STATUS; +------------------+----------+--------------+------------------+ | File | Position | Binlog_Do_
MySQLをベースに互換性を保ちつつ、独自のクラウド対応ストレージエンジンを搭載することで、スケーラブルなクラウド対応データベースサービスを実現する「Xeround」(ゼラウンドと発音するようです)が、ベータ期間を終了し、正式サービスを開始したと発表しました。 自動的なスケールアウト、ゼロダウンタイム XeroundはAmazonクラウド上で提供されるデータベースサービス。特徴は、自動的なスケールアウト機能、ゼロダウンタイム、MySQLと互換性があるためアプリケーションを変更せずに移行可能な点などです。 Amazonクラウド上では、Amazon自身がMySQLの運用サービスであ「Amazon Relational Database Service」(Amazon RDS)を提供しています。Amazon RDSはスケーラビリティも通常のMySQLに準じ、パッチ当てのための計画停止なども存在し
MySQLがダウンしたときに自動的に別のMySQLへ処理を引き継ぐことで、高可用性を実現するフェイルオーバーツール「MySQL-MHA: MySQL Master High Availability manager and tools」がオープンソースとして公開されたことを、作者の松信嘉範(まつのぶよしのり)氏がブログで伝えています。 Yoshinori Matsunobu's blog: Announcing MySQL-MHA: "MySQL Master High Availability manager and tools" 松信氏はモバゲーなどで知られるDeNAに勤務しており、MySQL-MHAによる自動フェイルオーバー機能はDeNAのインフラ運用を支えているとのこと。同氏のブログから引用します。 Difficulties of master failover is one of
2011-07-28 InnoDB純正の全文検索エンジンInnoDB FTS つい先日、MySQL-5.6.3-labs版がリリースがされました。この中にはInnoDBで動作する全文検索エンジン"InnoDB FTS"が含まれています。これまでは、MySQLとInnoDBの組み合わせで全文検索を行うためにはサードパーティの製品(mroonga 等..)が必要でしたが、これでズバっと選択肢が広がることになります。しかもInnoDBの開発チームが自ら開発した"純正の"エンジンということですから、これは大きな期待が持てます。 いったいどのような製品に仕上がっているのか、ざっくり記事やソースを読んで得た感触を述べてみたいと思います。 written by daijiro.mori どんなエンジンか? エンジンの概要については、 Overview and Getting Started with I
MySQLはGPLv2で頒布されているフリー(自由な)ソフトウェアだ。誰でも自由に改造、改善、機能追加して、GPLv2のもと再頒布することが出来る。 そうは言っても改造なんて敷居が高くて出来ないよ・・・という人に朗報なのが本書「MySQL 5.1 Plugin Development」だ!MySQLはストレージエンジンによってデータを管理するレイヤーが独立しているのはよく知られているが、MySQL 5.1ではさらに一歩進んで、ストレージエンジンを含む様々なプラグインを作成できるようになった。プラグインAPIを使ってMySQLを拡張すれば、無造作に改造してしまうよりもずっと楽にMySQLをハック*1することが出来るだろう。 MySQL 5.1で利用可能なプラグインPlugin APIは、MySQL 5.1で新たに追加された機能である。これにより、共有ライブラリ形式で後から機能を追加することが
[追記1] 最後で説明しているproxy cacheの設定を修正しました。 [追記2] nginx proxy cacheでキャッシュしない場合の処理を変更しました。 [追記3] スマートフォンや携帯で閲覧した時にキャッシュしない設定を追加しました。 はじめに 大げさな題名ですが、今回はWordPress単体を速くするのではなく、データベースやWebサーバなどの調整、またnginxのproxy cache機能を使って速くする話になります。 サイトの構成によっては、proxy cacheは使えないかもしれませんが、使わなくても5倍程度速くすることはできましたので、参考にしていただければと思います。 今回行うチューニング一覧 DBを最適化するプラグインを導入する APCを導入してPHPを速くする MySQLを速くする 重いWordPressプラグインを外す nginx+FastCGIにする W
べっ・・・別にソースコードなんて自分でコンパイルしないんだからねッ!!などと言わずにまず聞いていただきたい。30秒でMySQLのコンパイルが出来るというこの事実を。最近、細々とビルド時間の短縮に取り組んでいたのだが、正直ここまで爆速になるとは思わなかった。今日はビルド時間短縮のためのテクニックを紹介するので、是非皆さんも参考にして、快適ビルド生活を送って頂きたい!! 自己ベストは26.262秒マシンの状態や負荷の状況によって多少ビルドにかかる時間は前後してしまうのだが、これまでの自己ベストはなんと26.262秒。平均すると30秒ぐらい。以前は1分を切ることがなかったのだが、今ではなんとその半分でビルドが出来てしまう。これは純粋にmakeをするのにかかった時間であり、cmake(MySQL 5.5以降)やconfigure(MySQL 5.1以前)にかかる時間は除いてある。だがそれでも速い。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く