タグ

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

  • ISUCON5の予選を徹底的に復習する - スペクトラム

    ISUCON5の予選に参加して、圧倒的な差で負けたので、 この悔しさをバネに復習して、自分の力にしたいと思う。 今回のファイトではアプリの修正が特に重要であったように思う。 そこでアプリの修正に焦点を当てて、「こうすればよかった」を追っていき、自分のものとして習得したい。 とはいえ、番とまったく同じ状況を作ることはできないので、ローカル環境でベンチマークを走らせて、簡易に得点を見ていくことにする。 ISUCON5の予選で使われたアプリのコードとベンチマークのコード、gce用のイメージはすでに公開されているのでこちらを使う。 isucon.net なお、極力アプリの修正に集中するため、nginx.confやmy.cnfはいじらない。unicornのworker数すらいじらない。 インフラはせいぜいテーブルにインデックスを貼る程度とする。 これは、ISUCON予選番で、やたらインフラに時間

    ISUCON5の予選を徹底的に復習する - スペクトラム
  • nginxのパフォーマンスチューニング

    @shibuya.pm#17

    nginxのパフォーマンスチューニング
  • MySQLインデックスの基礎 : ひとつのテーブルに対するクエリの最適化法 | Yakst

    MySQLのインデックスを効果的に使うにはどうしたらいいのかについての分かりやすい解説。そもそもインデックスの役割はとは何か、そしてどうすればその役割を果たしてくれるのかを説明する。 たとえ1つのテーブルだけに対して実行されるクエリでも、パフォーマンスが悪いというのはよくあることです。その理由は簡単で、インデックスの作り方がまずいため、実行計画がおかしくなってしまうのです。ここでは、1つのテーブルのみに対する色々なクエリを最適化するためのガイドラインを挙げてみたいと思います。 おことわり : あらゆる状況をカバーしようとはせず、一般的なガイドラインを提示するに留めるつもりです。ここで挙げたものがうまく適用できない例を簡単に見つけることができるのは間違いないでしょうが、ほとんどの場合はここに書いたことが十分なのも事実です。また、MySQL 5.6以上にあるIndex Condition Pu

    MySQLインデックスの基礎 : ひとつのテーブルに対するクエリの最適化法 | Yakst
  • nginxのパラメータチューニングとh2o - Qiita

    (追記:タイトルが少々煽り気味な気がしたので微妙に変更しました。) h2oとnginxの性能比較 nginxよりも速いとされるh2oですが、実際に自分でもローカルでベンチマークを取ってみました。環境は以下の通りです。 EC2のc4.8xlargeインスタンス gcc (GCC) 4.8.2 20140120 (Red Hat 4.8.2-16) Linux ip-172-31-13-40 3.14.35-28.38.amzn1.x86_64 #1 SMP Wed Mar 11 22:50:37 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux nginx-1.8.0 h2o-1.2.1-alpha1 wrk(ベンチマーク) ベンチマークコマンド 実行するベンチマークコマンドは以下になります。なお、オプションはできるだけRequest/secが大きくなるように調

    nginxのパラメータチューニングとh2o - Qiita
  • CLOSE_WAITのセッションを早く消す方法 - つれづれなる・・・

    原因はおそらくwebサーバ〜DBサーバ間のセッションがネットワーク的に不安定だったからだと思うけど、DBサーバで netstat -an すると 大量の CLOSE_WAIT のセッションが残ってしまって、MySQL の最大コネクション数にまで達してしまってwebの表示が出来なかった。CLOSE_WAIT をいきなり消すことは出来ないので、早めに消えるようにしたいときは tcp_keepalive_time TCPセッションが確立されて検査が実施されるまでの時間 時間になると tcp_keepalive_intvl と tcp_keepalive_probes の値にしたがって検査を実施する tcp_keepalive_intvl 次の検査を実行するときの待ち時間 tcp_keepalive_probes 検査の回数のそれぞれの値を小さくしてあげればよい。変更方法は vi で :wq する

  • naoyaのはてなダイアリー - Linuxのページキャッシュ

    世間では PHP が、Perl が、と盛り上がっているようですが空気を読まずまたカーネルの話です。今回はページキャッシュについて。 /dev/shm に参照系DBを持っていくと I/O 負荷が激減した件(当たり前だけど) - drk7jp で、ディスク上にあったファイルを /dev/shm (tmpfs) に移したら I/O 待ちがなくなって負荷がさがった、ということなんですがおそらくこれは tmpfs に置く必要はないかなと思います。Linux (に限らず他の OS もそうですが) にはディスクの内容を一度読んだらそれはカーネルがキャッシュして、二度目以降はメモリから読む機構 = ページキャッシュがあります。tmpfs にデータを載せることができた、ということは物理メモリの容量に収まるだけのデータサイズかと思うので、放っておけば該当のファイルの内容すべてがメモリ上にキャッシュされて io

    naoyaのはてなダイアリー - Linuxのページキャッシュ
  • 1