MySQL InnoDBストレージエンジンのチューニング（後編）
チューニングの基礎 それでは、具体的にInnoDBでどこをチューニングするべきかを見ていこう。 バッファプール 最も基本となるのがバッファサイズの調整だ。ワーキングセットが全てバッファに収まらない限り、バッファプールは大きければ大きいほど良い。その分ディスクアクセスが減るからだ。バッファサイズが小さいと、キャッシュミス時にディスクからReadするのに時間がかかり、I/Oがボトルネックになってしまう。予算のある限りメモリを目いっぱい搭載し、バッファプールに割り当てよう。InnoDBのバッファプールは、innodb_buffer_pool_sizeオプションで設定する。利用可能なメモリは、他の処理に必要な分を除いたすべてをInnoDBのバッファプールに割り当てよう。 innodb_buffer_pool=32G ここで一つ注意がある。innodb_buffer_pool_sizeはバッファプー
MySQL InnoDBストレージエンジンのチューニング（前編）
本連載では、３回にわたってチューニングの要であるオプティマイザについて説明してきた。オプティマイザは論理的な表現であるクエリを物理的にどう処理するかということを決めるRDBMSの心臓部であると言える。しかしながら、人体が心臓だけで機能しないのと同じように、RDBMSもオプティマイザだけで成り立つわけではない。実際に手足となりデータを操作するのはストレージエンジンだ。今回は、MySQLの代表的な（実質的にはデファクトスタンダードの）ストレージエンジンであるInnoDBの基本的なチューニングについて解説しようと思う。クエリのチューニングとは全くストラテジーが異なるので、これまで連載を読んで頂いている方は、ここで頭を切り替えて欲しい。 InnoDBを使おう！ もし本稿を読まれている方で、特に明確な意味もなくまだMyISAMストレージエンジンを使ってらっしゃるという方には、全力でInnoDBをオス
HDDのアクセスが妙に遅く感じるときは
最近のHDDはDMAをサポートしているので、DMAに対応したマザーボードと組み合わせればCPUを介さずに直接デバイス－メモリ間のデータ転送が可能だ。しかし、DMAがオフになっているとI/Oによるアクセスになってしまうので、HDDのアクセスが遅くなってしまう。 HDDのアクセスが遅く感じられるときは、DMAがオンになっているかどうか確認しよう。DMAのオン／オフは、hdparmコマンドで確認できる。rootでログインし、調べたいデバイス名を指定してhdparmコマンドを実行する。 # hdparm /dev/hda ←/dev/hdaを調べる /dev/hda: multcount = 16 (on) I/O support = 0 (default 16-bit) ←I/Oが16bitsになっている unmaskirq = 0 (off) using_dma =
hdparm でハードディスクを高速化する
hdparm でハードディスクを高速化する 2006.04.08 Linux もしハードディスクが PIOモードで動いていたらDMAモードに変更するだけで、14倍の速度アップ！ ■ハードディスクの読み出し速度を測定する まずは、HDDの読み出し速度を測る。 # hdparm -Tt /dev/hda /dev/hda: Timing cached reads: 1856 MB in 2.00 seconds = 929.07 MB/sec Timing buffered disk reads: 10 MB in 3.48 seconds = 2.87 MB/sec -Tスイッチは、キャッシュシステム、つまりメモリ、CPU、バッファキャッシュをテストするという意味。 -tスイッチは、キャッシュ上に無いデータを読み出して、ハードディスクのパフォーマンスをテストする。 読み出し速度が2.87MB
過負荷をかわす Apache の設定 : DSAS開発者の部屋
KLab Advent Calendar 2011 「DSAS for Social を支える技術」の9日目です。 前回は php を動かしている Apache の手前にリバースプロキシを 置く必要性を解説しました。 今日は、 その前の php のプロセス数を絞る設定と合わせて、実際に Apache で 設定する方法を紹介します。 以降、 php を動かしている Apache の事をアプリサーバー、リバースプロキシ＋ 静的ファイル配信を行っている Apache の事をプロキシサーバーと呼びます。 基本設定 まずは基本的な設定のおさらいです。 アプリサーバー 並列数を絞るには MaxClients を設定します。アプリがどれくらいの時間を CPUの処理で使って、どのくらいの時間を外部リソース待ちに使っているかにも よりますが、だいたいCPU数の1.5倍〜2倍くらいが適当だと思います。 Hyp
IO Accounting 機能で I/O 負荷の高いプロセスを特定
随分久々の Linux ネタです。以前にロードアベレージに関する考察などの記事も書きましたが、多くのサーバーサイドエンジニアはサーバ負荷と日々戦っていることかと思います。過去多くの場合、負荷の原因特定はおおよそ下記のような手順で分析をしていたことかと思います。※詳しい手順は別エントリとして記載予定。 top をみて上位に張り付いているプロセスを確認しつつ CPU or I/O のどちらが原因か判別 ps を使ってプロセスの状態を確認して(T),(D)の状態から CPU or I/O のどちらが原因か判別 vmstat で procs の r, b の数、swap の si, so の状態、I/O の bi, bo の状態を確認 iostat を使って disk の read/write の状態をさらに詳しく確認 sar を使って os の状態をさらに詳しく確認 おおよその原因特定から設定を
さくらVPSのWordPressをチューニングして30倍高速化した方法 - 原宿・表参道.jp
今日はさくらVPSに載せているWordPressのパフォーマンスをチューニングして高速化に成功したので安心して眠れるという話をします。 2.5ページ/秒だったのが70ページ/秒と30倍高速化。 以前はDaily数千PVで重くなっていたサイトがDaily3.6万PVを余裕で捌けるようになりました。 #ちなみにproxy cacheという手法はwordpressでなくても動的コンテンツ全般に有効です。 ▼サーバ気にしなくて良くなったので今週末新宿御苑に花見に行けました☆。枝ぶりがいいさくらが多くてほんといいところだと思うの。 WordPressチューニング高速化結果http://hara19.jp/のサーバ環境と測定結果は以下のとおり。 WordPress稼働環境さくらVPS 1GB/CentOS5.5/PHP5.3/MySQL5.5/WordPress3.1。 WEBサーバはチューニングにあ
モバイルウェブ環境のHTTPSのチューニング « NAVER Engineers' Blog
こんにちは検索サービス開発４チームの崔珉秀と申します。 インフラやシステムとの連携や統計のバックエンドを担当しております。 モバイルのウェブ環境はPCのウェブ使用環境とは色々な違いが有ります。 ネットワークの速度だけではなくバッテリーの効率を考えた仕組みなど、PCに比べリソースが十分ではないためモバイルブラウザの動作が異なっていることも有ります。 今回はモバイルのウェブApplicationにおけるSSL関係の性能に関する工夫の内容をQ&A形式で解説していきます。 Q. 何が問題でしたか？ A. モバイルクライアント(iPhone, Android)のアプリケーションからのHTTPリクエストの応答時間に遅延の問題が有ります。 最初はweb access logからのslow response(１秒以上)のHTTPリクエストが結構ありました。 そのHTTPリクエストをprotoc
ISUCONに参加してきました | へぼい日記
なんでもありのWebアプリケーション高速化バトル、#isuconに山形組として参加してきました。 結果はみなさんご存知の通り、藤原組さんの圧勝という感じになりました。 自分はというと、DBボトルネックの解消までは藤原組さんとほぼ同じ手法で解決して、4700req/minあたりのbest scoreを出した後には有効なチューニングが行えずにnginx導入の罠にひっかかって200req/minとかになってしまって泣きながらapacheに戻したりしつつ、最後はサイドバーのcacheをmmapにいれる作業をしていたらバグでfailするようになってしまってぎりぎりでDBのボトルネック解消直後にロールバックして、10000req/3minくらいがたしか最終スコアだったと思います。failしたチームを除けば下から数えたほうが早い感じになってかなり悔しい結果でした。 DBボトルネック解消直後にappサーバ
#isucon ではどんなことを考えながら作業していたか - 酒日記 はてな支店
前のエントリ #isucon で優勝してきました は当日夜に酔っ払った頭で勢いで書き上げたので、少し冷静に振り返ってまとめてみます。 最初のボトルネック発見 DB が CPU 4コアをフルに使って回っているのですぐに Query が重いのは分かった 重いクエリはキャッシュすれば、という発想は自然 (実際 MySQL のクエリキャッシュだけでスコアは 1.5倍程度上がる)、とはいえ このクエリは実行に 300〜400 ms 程度かかる アプリケーションの要件上、毎秒更新する必要がある 1秒ごとに更新に 0.3〜0.4秒かかる処理をするのは悪手だろう cache が消えてから生成、とすると生成処理が複数同時に走って無駄が大きい (実際ベンチマーク中の slow query を見ると 600〜700 ms 程度の時間が掛かっていた) ということで、DB のテーブル構成を変更して高速化できないか、
#isucon で優勝してきました - 酒日記 はてな支店
なんでもありのWebアプリケーション高速化バトル、#isucon に会社の同僚 @Songmu @sugyan と3人で、fujiwara組として参戦してきました。結果、幸いにも優勝を勝ち取ることが出来ました。 こんなに楽しいイベントを企画、運営していただいた Livedoor の皆様、本当にありがとうございます！！ さて、ざっとチューニングした経過などを記録しておきます。 [追記] もっと詳しいレポートを @Songmu が上げているのでそちらもご覧ください おそらくはそれさえも平凡な日々: #isucon で優勝させてもらってきました [さらに追記] #isucon ではどんなことを考えながら作業していたか - 酒日記 はてな支店 自分でももう少し詳しく振り返りエントリ書きました。 まず説明を聞いて、環境を作るところから。IPアドレスでは作業がしにくいし事故も起こりそうなので、host
tune
■1プロセスが同時に開けるファイル数を増やす 以前LinuxがOSとして同時に開けるファイル数を増やす手段は紹介したが、今回は１プロセスが同時に開くことができるファイル数を増やす方法のメモ。ユーザ単位の設定になるので注意。 Linuxサーバチューニングメモ http://blog.isnext.net/issy/archives/190 とあるパフォーマンステストを行っていたところ、プロセスが開けるファイル数を超えたというエラーが頻発したため、以下の手法で対応した。CentOSでは標準で１プロセスが同時に開けるファイル数は1024。OSのfile-maxは最近のバージョンではかなり大きな数字になっているのに、こちらの値は結構前から1024のままらしい。そこでこの値を修正する。 ■現在の状態を確認する（確認したいユーザでログインすること） [code]# ulimit -Sa core fi
プロのサーバ管理者がApacheのStartServers, (Min|Max)SpareServers, MaxClientsを同じにする理由 - blog.nomadscafe.jp
kazuhoさんが「プロのサーバ管理者の間では存在価値が疑問視されて久しい (Min|Max)SpareServers だと思う」と書いたり、hirose31さんが去年のYAPC::Asiaで{Start,{Min,Max}Spare}Servers,MaxClientsは同じにしているよと発表したり、実際前職のサーバはそのように設定されていたのですが、自分でうまく説明ができてなかったので、調べながら書いてみた。 本当はイントラブログ用に書いていたものですが、がんばったので転載。 前提として、CPUの使用率におけるsystemとfork Re: クラウドがネットワークゲーム開発者にもたらしてくれたもの - blog.nomadscafe.jpでも書いている通りforkってのはサーバにとって重い部類の処理になります。つまり負荷の高いときにforkを大量に行うのはしてはならないことの１つです。
ウノウラボ Unoh Labs: MySQLのチューニングのためのデータの集め方
いつの間にか会社で古株になったyamaokaです。 webアプリケーションのバックエンドにMySQLを使っている場合、 クエリ（SQL）のチューニングをする必要がありますよね。 皆さんはチューニングの計画をどのように立てていますか。 もちろん、既に明らかに重いことが想定されているページがあれば、 その処理で使われているクエリを中心にEXPLAINなどを使って解析していけばいいと思います。 でもそうではなく、全体的にクエリの見直しやチューニングを行いたい場合は 実際に実行されているクエリを確認していくという作業が必要です。 そこで使うことができる3つの方法について書きたいと思います。 遅いクエリを記録する MySQLにはスロークエリログといって、 実行に時間がかかったクエリを記録する機能が最初から付いています。 /etc/my.cnfに次のように設定を書けば実行時間が1秒を超えたクエリが出力
Gree Fast Processor: PHPを3倍(くらい)速く | GREE Engineering
ごあいさつエントリだけというのもなんなので、引き続きfujimotoです。実質上1つめのような気がするこのエントリでは、PHPが3倍くらい(少なくとも2倍くらいは...)速くなるGree Fast Processorというのを先月作ってみたのでご紹介です。 すぐわかるまとめ Gree Fast Processorというのを使ってみると、シンプルなsymfonyのプロジェクト(xav.ccで試しました)でも2倍弱、結構複雑なアプリケーションだと7倍くらい速くなったりします。いくつかの制約がありますが、パフォーマンスに飢えているかたはお試しください。 こちらはなんかすごい速くなっている感じのグラフ(一番上が速くなった版のRequests per Second、赤が通常版のRequests per Second): これはさすがにbest caseすぎる気がしますが、普通にやっても2倍弱くらいは
たった3秒でInnoDBのデータローディングが快適になるライフハック
MySQLに限った話ではないが、データベース管理システムに大量のデータを投入するのは時間が掛かり大変苦痛を伴う作業である。劇的に効能があるわけではないが、MySQLを利用しているとき、特にInnoDBを使っている場合にはデータの投入を高速化するためにいくつかテクニックがあるので紹介しよう。皆さんの作業時間が短縮され、少しでも早く帰路に着いたりサービスインさせたりという形でお役に立てれば幸いである。ちなみに、タイトルはネタであるのだが、もし本当に3秒で以下の全ての設定を行えた人が居たら教えて頂きたい！ ログファイルサイズの調整データ投入時に限った話ではないが、ログファイルサイズを調整するのは更新性能にとって非常に重要なファクターである。バッファプールのサイズが重要なことに代わりはないが、同じぐらいログファイルのサイズも重要である。InnoDBはログファイルを使い切ってしまうと、バッファプール
漢(オトコ)のコンピュータ道: InnoDBでCOUNT()を扱う際の注意事項あれこれ。
InnoDBを使うとき、MyISAMと比較して度々やり玉に挙げられるポイントとして「COUNT()が遅い」というものがある。確かにInnoDBにおいて行数を弾き出すのにはテーブルスキャンが必要なのだが、そもそもMyISAMのCOUNT()が速い（テーブルの行数を保持してる）のが特殊なのであって、InnoDBが遅いわけではないのである。とはいえ、高速なCOUNT()については需要が多く、この問題には多くの人取り組んでおられるようだ。しかしながら、COUNT()のチューニングについては未だ語られていない点があるように見受けられるので、今日はCOUNT()のチューニングについて解説しようと思う。 COUNT(*)、COUNT(col)、COUNT(1)の違い基本的なことではあるが、COUNT(*)とCOUNT(col)では意味が異なるため、異なる結果が返される場合がある。COUNT(*)はフェッ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ソーシャルゲームスケールアウトの歴史
Good night, Posterous
認証がかかっています