タグ

チューニングに関するfaibouのブックマーク (24)

  • なぜ、SQLは重たくなるのか?──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策|ハイクラス転職・求人情報サイト AMBI(アンビ)

    なぜ、SQLは重たくなるのか?──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策 『SQLパフォーマンス詳解』の翻訳者の松浦隼人さんに、8つの「SQLが重たくなる原因とその対策」を聞きました。システムのボトルネックになるような「問題のあるSQL」を回避するノウハウを学びましょう。 データの操作や定義をする言語「SQL」は、どのような領域を担うエンジニアにとっても必修科目です。しかし、その仕様をきちんと理解し、パフォーマンスに優れたSQLを書ける方はそれほど多くありません。問題のあるSQLを書いてしまい、知らぬ間にそれがシステムのボトルネックになってしまう事態はよく発生します。 では、どうすればそうした事態を回避できるのでしょうか? そのノウハウを学ぶため、今回は『SQLパフォーマンス詳解』の翻訳者であり、自身もエンジニアでもある松浦隼人(まつうら・はやと/@dblmkt)さんに8つ

    なぜ、SQLは重たくなるのか?──『SQLパフォーマンス詳解』の翻訳者が教える原因と対策|ハイクラス転職・求人情報サイト AMBI(アンビ)
  • nginx最大パフォーマンスを出すための基本設定 | Node.js技術

    解説 worker_processes auto; - Nginx体のプロセス数、autoにしてnginx内部判定に任せるのは賢明 worker_rlimit_nofile 100000; - workerプロセスが最大に開けるファイル数の制限。このように設定したら、ulimit -a以上のファイル数を処理できるようになり、too many open files問題を回避できる worker_connections 2048; - 一つのworkerプロセグが開ける最大コネクション数 multi_accept on; - できるだけクライアントからのリクエストを受け取る use epoll; - Linuxカーネル2.6以上の場合はepoll、BSDの場合kqueue server_tokens off; - セキュリティ対策です、エラー画面のnginxバージョン番号を非表示 sendf

  • MySQL 5.5の秘伝のタレが5.6では腐っていたはなし | GMOメディア エンジニアブログ

    もう寒の入りを過ぎましたね。DBAのたなかです。 GAからもうすぐ1年、社内ではもう相当カジュアルにMySQL 5.6をインストールしています。今までは新規サービス(や、新規機能)での導入がほとんどだった5.6を、このたびトラフィックガンガンのサービスにアップグレードで導入しました(と、偉そうに言っていますが私でない別のDBA氏が主担当のサービスです) 主な理由はInnoDB Compressedを使っていたのでその性能アップに期待…というところだったんですが、弊社DBAが神代の時代より試行錯誤を重ねたどり着いた究極のmy.cnf(?)、いわゆる秘伝のタレが 残 念 な が ら 腐 っ て お り 夜を徹してアップグレード作業をしていた担当DBA氏が青い顔(推定。チャットだった)で ス ロ ー ク エ リ ー が 1 0 倍 く ら い に な っ た ん だ け ど … と訴え、彼はその

  • ScaleOut | Supership

    2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。件に関する詳細は、プレスリリースをご確認ください。 2024年4月1日より、Supership株式会社は親会社であるSupershipホールディングス株式会社に吸収合併されました。 合併に伴い、存続会社であるSupershipホールディングスは社名をSupershipに変更し、新たな経営体制を発足しました。 件に関する詳細は、プレスリリースをご確認ください。

    ScaleOut | Supership
  • MySQL 5.6 パラメータ検討会 - SH2の日記

    7月29日にMyNA(日MySQLユーザ会)会 2013年7月が行われ、Oracle ACE Directorの@sheeriさん、MyNA会長の@tmtmsさんに混ざって発表をしてきました。運営のみなさま、当日お越しいただいたみなさま、いつもありがとうございます。 Performance Schema - Sheeri Cabral (PDF) MyNA会2013年7月 に行って来ました - MySQLのプロトコル解説 - @tmtms のメモ 今回は@yoku0825さん、@yyamasaki1さんがライトニングトークをされました。@yoku0825さんアイスごちそうさまでした。 日々の覚書: MyNA会2013年7月に行ってきました 5分で作るMySQL Cluster環境 私は発表内容について懇親会でいろいろ宿題をもらってしまい、しばらく復習をしていました。ようやく修正が終わりま

    MySQL 5.6 パラメータ検討会 - SH2の日記
  • muninの表示がクソ重くなっていたのを劇的に改善した話 - 元RX-7乗りの適当な日々

    某所の"munin"がびっくりするくらい画面表示が重くなっていて、ひょんなことから改善することになった話。 前提条件として、このmuninが動いているサーバは数百台のノード(サーバ)を管理している状態で、muninのバージョンは2.0系でした。 当は、後学のためにも作ってくれた人に直してもらうべきと思いつつ、あまり悠長なことも言ってられない感じだったので、一人チューニンガソンを敢行。・・・要望があったのでログを残しておきます。(遅くなってごめんなさい) 最初の状態(before) まず、muninのトップページですが、開いてみると、、、 うほっ、19.61秒かかっておりました。これはなかなかのストレスです。 特にHTML部分の出力に19.4秒かかっている。ここをなんとかせねばなるまい。 次に4台分のサーバの各リソースの負荷状況が確認できるページを表示してみると ズラズラと出ております。各

    muninの表示がクソ重くなっていたのを劇的に改善した話 - 元RX-7乗りの適当な日々
  • MySQL/チューニング - がしまっくす

    統計情報を取る † 定量的な情報収集のススメ mysql> show global status; (5.0.2以上の場合) mysql> show status; (5.0.2未満の場合) ↑ ファイルオープン数の調整 † 高負荷なときに以下のコマンドを実行 $ mysqladmin -u root -p extended-status | grep Open Enter password: | Open_files | 515 | | Open_streams | 0 | | Open_tables | 256 | | Opened_tables | 45281 | Open_files, Open_tablesの数が多い場合は /etc/my.cnf の以下を調整。この値が大きすぎると「Error in accept: Too many open files」エラーが発生し、MyS

  • JavaScriptの顔認識ライブラリをチューニングしたら実用レベルになったという話 (Kanasansoft Web Lab.)

    ただ、WebRTCで顔認識させようとすると遅くてしかたがなかった。 最初は速いこともあるが、10回ぐらい認識をさせるとすぐに遅くなる。 とりあえず、デモ。 そこで、チューニングをしてみることにした。 まず、JavaScriptの定番の高速化を試してみた。 例えば、正の数で使える「Math.floor(x)」を「(x | 0)」に、整数で使える「x * Math.pow(2, y)」を「x << y」にする等。 これで、10~30%高速化できた。 次に、遅くなっている部分を調べたら、Web Workersで分散するための仕組みが遅くなる原因だとわかった。 これは、Web Workersを使わない場合にも影響が出ていた。 じゃあ、Web Workersを使えば速くなるのかといえばその逆で、20倍遅くなっていた。 詳しくは調べてないけど、多分Workerスレッドに処理データを渡す時にJSON化が

  • チューニンガソン第3弾で優勝しました!

    3/24日の第三弾チューニンガソンに参加したので、その詳細をまとめました。 ツッコミ大歓迎です!!! 今回福岡でもリモートで参加可能だと聞いて、これは参加せねばと思いエントリしました。 基ぼっちなんで一人で参加。 ~前日福岡のインフラ勉強会で一度、傾向と対策的なことをしてました。 ここでは、主にチューニング項目の洗い出しと、次のお題の予想してました。 私の予想では、webサーバーにnginx、appにredmineじゃないかと予想してました。。。 あとは、前回までがphpがお題だったので、php触った事無いのでapcインスコする手順とかを一応予習。 (結局、全く役に立たなかったのですが・・・・) その他にも、apacheやmysqlの設定を勉強してました。 msqlの勉強で最後の砦として読んだのが↓です。 オススメですよー あと、今回必ず使おうと思っていたのが、dstatでした。 dst

    チューニンガソン第3弾で優勝しました!
  • Who moved my SPAM? - なぜ私がTuningathon 2で4位に入ったか?

    なぜ私がTuningathon 2で4位に入ったか? 初参加のTuningathonで4位に入りました。これといった特別なことが出来なかったので、スコアが発表されたときは正直何が起こったのかよくわからずキョドってしまいましたが、一つ仮説が浮かんだので書いておきます。 今回の環境とレギュレーション 今回はAMIが2インスタンス提供され、それぞれにapache+mysql構成のWikipediaクローンがインストールされていました。レギュレーションは、 /var/www/html/mediawiki配下の編集と、 データベース内のデータの改ざんが不可。 それ以外は何してもよし、2フロントエンドも可。 そして計測は紆余曲折がありつつですが、 http_load -parallel 4 -fetches 100 urlsで、urlsは元のクローンが200を返すURLがランダムに1000件入ったもの

  • 第2回 Tuningathonへ行って来ました。 – Karakani

    1ヶ月に1回しかブログ書いてないカニです。先週の土曜日、第2回 Tuningathonが開催され行ってきました。結果、上位3位だったようですが未だに何が決定打になっているのかわからず悩んでいます。 アプリケーションはMediaWikiにWikipediaのコンテンツを導入してあるといういわばWikipediaのミラー的なものです。データ件数は数百万件オーダー。一方で、テストに使用されるURLは同時並列4アクセスで合計100回のアクセスです。URLは各単語に対する記事でランダムに抽出されます。コンテンツの更新はありません。 ルールと自分がとった戦略 戦略と書いたのですが、実は特に戦略と呼べるものもなく… 簡単に考えていたのはこんな事です。 フロントエンド側のキャッシュは多分できない。百万件のキャッシュとか無理だと思うので考えない。(Wikipediaが快適に表示されているのはキャッシュサーバ

  • http_loadでレスポンス測定 - うまいぼうぶろぐ

    http://www.acme.com/software/http_load/ いまさらながら使ってみた。abと違って複数のURLに対して同時にhttpアクセスできる。結果はシンプル。 $ http_load -parallel 10 -fetches 100 url.txt 接続数 parallelかrateで指定。 parallel: 同時接続数の指定 rate: 毎秒ごとの新しい接続数の指定 接続回数 secondsかfetchesで指定。 fetches: 接続する合計回数 seconds: 接続する秒数 ハイパフォーマンスWebサイト ―高速サイトを実現する14のルール 作者: Steve Souders,スティーブサウダーズ,武舎広幸,福地太郎,武舎るみ出版社/メーカー: オライリージャパン発売日: 2008/04/11メディア: 大型購入: 32人 クリック: 676回この

    http_loadでレスポンス測定 - うまいぼうぶろぐ
    faibou
    faibou 2011/12/14
    abと違って複数のURLに対して同時にhttpアクセスできる。
  • hamano's gist: 第2回 Tuningathon チューニングメモ

    tuningathon2_memo.txt Ђ�*V �,�*V # 第2回 Tuningathon チューニングメモ このメモは @hamano が [第2回 Tuningathon][1] に参加した際に行ったチュー ニングポイントと感想です。 [1]: http://www.zusaar.com/event/agZ6dXNhYXJyDQsSBUV2ZW50GLmFBgw "第2弾!いろいろチューニングしてパフォーマンスを競うバトルイベント開催!「Tuningathon」2!! #tuningathon" 今回のお題は MediaWiki への参照性能という事でまたPHPか! とは思いました が2台構成可、Web Serverの入れ替え可、という条件でしたのでチューニングの 範囲が大きく広がった様に感じました。 ただ、この程度の平行数ではapacheをその他実装に置き換えた所で大した差

    hamano's gist: 第2回 Tuningathon チューニングメモ
  • チューニンガソン2で2位でした : DSAS開発者の部屋

    10/1(土)にチューニンガソン2 というイベントに参加してきました。 もちろん前回に引き続き優勝を 目指していたのですが、今回は残念ながら2位でした。 今回もどんなチューニングをしていたのかの記録を公開します。 (ちなみに優勝したのは元KLabの濱野さんで、同じく メモを公開されています。) 今回のチューニンガソンのお題は、 Wikipedia の高速化で、 MediaWiki と Wikipedia の データが入った MySQL のデータには修正を加えずに、ランダムな100ページの表示速度を競いました。 マシンはメモリ1GBでデュアルコアのものが2台で、今回はWebサーバーの部分は自由に構成できます。 1. ボトルネックの確認 とりあえず AMI Linux の標準の php + apc で計測したところ、1ページの表示に1秒くらい使っています。 またphpか!ということで、やっぱり

    チューニンガソン2で2位でした : DSAS開発者の部屋
  • perfを使う

    概要 Linuxのパフォーマンス解析ツールであるperfの使いかたの紹介 前提知識 Linux系 perfについて カーネル内のイベントや、ハードウェアイベントの発生回数を計測できるツール。 インストール 2.6.31 からはカーネルに標準搭載されてるので、特に必要なものは無い。 やることは、 カーネルのCONFIG_PERF_COUNTERSを有効にする カーネルをビルド なんらかの手段でelfutilsのlibelfを入れる(libelf-0.8.12ではない) カーネルソース内にある tools/perf/ で make する できた'perf'コマンドをパスの通るところに置く debugfsを/sys/kernel/debugにマウントする で、$ perf list などとやって、イベントリストが表示されれば使える 使いかた マニュアルは tools/perf/Documenta

  • チューニンガソンで優勝してきました : DSAS開発者の部屋

    7/9(土)にチューニンガソン というイベントに参加して優勝してきたので、その報告と、何を考えてどんなチューニングをしたのかを 記憶の範囲で公開したいと思います。 今回のチューニンガソンのお題は、WordPress(ja) + php + Apache + MySQL で、 ab を使って wp-comment.php 経由でコメントのポストをすることで計測が行われました。 MySQLとApacheを立ち上げたらWordPressが動く環境が渡され、そのWordPress自体は設定ファイルを含めて 改造が一切禁止、WordPressの実行をショートカットするチートも禁止です。 0. 試合前日 環境がAWSとAMI Linuxということは事前に公開されていたため、前日にAWSに登録して少しだけAMI Linuxを 触ってみました。yumベースだけどCentOSと違って結構新しいバージョンが用

    チューニンガソンで優勝してきました : DSAS開発者の部屋
  • さくら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サーバはチューニングにあ

    さくらVPSのWordPressをチューニングして30倍高速化した方法 - 原宿・表参道.jp
  • HugeDomains.com

    Captcha security check matomematome.com is for sale Please prove you're not a robot View Price Processing

    HugeDomains.com
  • WordPressを100倍速くする! MySQLの調整やnginx proxy cache | KRAY Inc

    [追記1] 最後で説明しているproxy cacheの設定を修正しました。 [追記2] nginx proxy cacheでキャッシュしない場合の処理を変更しました。 [追記3] スマートフォンや携帯で閲覧した時にキャッシュしない設定を追加しました。 はじめに 大げさな題名ですが、今回はWordPress単体を速くするのではなく、データベースやWebサーバなどの調整、またnginxのproxy cache機能を使って速くする話になります。 サイトの構成によっては、proxy cacheは使えないかもしれませんが、使わなくても5倍程度速くすることはできましたので、参考にしていただければと思います。 今回行うチューニング一覧 DBを最適化するプラグインを導入する APCを導入してPHPを速くする MySQLを速くする 重いWordPressプラグインを外す nginx+FastCGIにする W

    WordPressを100倍速くする! MySQLの調整やnginx proxy cache | KRAY Inc
  • 大人のためのInnoDBテーブルとの正しい付き合い方。

    InnoDB関連でよくある質問のひとつに「テーブルのメンテナンスは何をすればいいんですか?」というものがある。InnoDBMySQL 5.5でデフォルトストレージエンジンとなるため、InnoDBのテーブルメンテナンス計画を立ようと思う機会も増えることだろう。そこで、今日はInnoDBのテーブルメンテナンスの各種方法となぜそうしなければいけないかという理由を解説しようと思う。 ANALYZE TABLEテーブルメンテナンスの代名詞といえば、インデックス統計情報の更新ではなかろうか。運用を続けるうちに、知らず知らずインデックス統計情報が狂ってしまい、思うような性能が出ない。RDBMSにはそのような問題がつきものであるが、InnoDBの場合、ANALYZE TABLEは不要である。なぜなら、InnoDBが自発的に統計情報を更新するからだ。InnoDBは以下の条件に適合すると、ANALYZE T

    大人のためのInnoDBテーブルとの正しい付き合い方。