タグ

tuningに関するnuraiのブックマーク (23)

  • Devel::KYTProfのログをファイルに書き出して、I/Oのボトルネックを知る - ゆーすけべー日記

    Webアプリケーションが遅いとか感じる時って、僕の場合、I/Oがボトルネックなケースが多いのです。つまり、MySQLへクエリーを投げて返却を待つとか、memcachedにget/set等のメソッドを発行した時の待ち時間が長くかかってたり... とかです。そうすると計測して原因を突き止めたくなります。PerlのプロファイラはDevel::NYTProfとか色々ありますが、こうしたI/Oに関しての計測は「Devel::KYTProf」が便利です。適当な場所にて use Devel::KYTProf; するだけで標準エラー出力に「空気読んで」ウマいこと色付きで、I/O周りのかかった時間とどこの箇所か?を表示してくれます。 ただ、この「標準エラー出力に表示」ってのは開発時にターミナルで確認する分には便利なのですが、例えば番環境などで一時的にパフォーマンスを計測するためにはちょっと不便なことがあり

    Devel::KYTProfのログをファイルに書き出して、I/Oのボトルネックを知る - ゆーすけべー日記
    nurai
    nurai 2013/04/14
    [I/O]
  • CentOS6で制限されているプロセス最大数を制限解除する - 256bitの殺人メニュー

    ハマったのでメモ。 Linuxでリソース制限するための仕組みのulimitがありますが、その1項目に「nproc」があります。 これはそのユーザで実行できるプロセス(スレッド)数の制限となります。 これが、CentOS5までは、 $ ulimit -u unlimitedのように無制限だったのですが、CentOS6になって以下のように1024で制限がかかるようになりました。 $ ulimit -u 1024そのため、デーモンとかで高負荷な処理をさせてプロセス(スレッド)が増えると処理が落ちてしまうのです。 悲しいけどこれってデフォルト値なのよね。 設定箇所は? 実際の設定は、[/security/limits.d/90-nproc.conf]でされています。 # cat /security/limits.d/90-nproc.conf # Default limit for

    CentOS6で制限されているプロセス最大数を制限解除する - 256bitの殺人メニュー
  • postgresql パフォーマンスチューニング

    このサイトは、もともと作者の自分用メモとして書き始めたものです。書いてあることが全て正しいとは限りません。他の文献、オフィシャルなサイトも確認して、自己責任にて利用してください。 数十万レコードのデータを持つ大規模なテーブルを扱うようになると、クエリによっては回答が得られるまでに数秒かかるケースも出てくる。これは、より多くのメモリやディスクの使用を Po

  • CentOS 5用バイナリパッケージ

    暗号ファイルシステムの詳細 CFS dm-crypt ブロックデバイスなので、ディスクパーティション自体に暗号化を行います。(例:/dev/sda3) そこで、まず専用のパーティションを作成します。不良セクタチェック後、パーティションをランダムデータで埋めて(セキュリティ強度を向上するため)、cryptsetupコマンドでパーティションを暗号化します。 暗号化したパーティションを、Device sFdb1 WARNIN

  • 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スイッチは、キャッシュシステム、つまりメモリ、 hdparm でハードディスクを高速化する

  • フロント/バックのreverse proxy構成で、指定秒数以内に必ずレスポンスを返す方法 - (ひ)メモ

    目的 フロントがHTTPリクエストを受けて、バックエンドのアプリケーションサーバにreverse proxyするような構成において、指定秒数以内に何かしらのレスポンスを返したい。 200が返せない場合は、処理を打ち切って500を返したい。 背景 フロントでApacheやNginxをreverse proxyとして使っている場合、バックエンドが無応答になってしまうと、クライアントにレスポンスが返るのはデフォルトで数十〜数百秒後(ApacheのTimeoutのデフォルトは300秒、Nginxのproxy_read_timeoutのデフォルトは60秒)になってしまいます。 通常のWebサービスではこのオーダーのタイムアウトでもいいのかもしれませんが、数秒以内に(エラーでもいいので)レスポンスを返すことが求められる環境も存在します。(最近、特に多いのではないでしょうか:P) もちろんバックエンドが

    フロント/バックのreverse proxy構成で、指定秒数以内に必ずレスポンスを返す方法 - (ひ)メモ
  • Show Slow

    Show Slow & Make Fast

  • ページの読込み速度を改善するための視覚化データを出す「GTmetrix」

    プライオリティが最も高いわけではありませんが、ページの読み込み速度も検索順位に少なからず影響していると言われています。 しかし、改善するには様々な要素が絡んでいるため、すべての分野に精通していなければ、データを見ても、どこに注力すべきかはなかなか見えてきません。 そこで今回は、どの部分に問題があり、その問題のプライオリティがどの程度高いのかまでを視覚化してくれるオンラインツールをご紹介します。 組織のマインドマップツールをマインドマイスターにすべき理由 伸びてる産業、会社、事業を紹介しまくるStrainerのニュースレターに登録!! ページの読み込み速度改善に役立つ「GTmetrix」「GTmetrix」は、ページの読み込み速度計測を、詳細に解析し、なおかつ各項目にプライオリティを付けて最適化を助けてくれるオンラインツール。 YslowやFirebug、Google Page Speedな

    ページの読込み速度を改善するための視覚化データを出す「GTmetrix」
  • Kazuho@Cybozu Labs: MySQL のボトルネックを統計的に監視・解析する方法

    MySQL のチューニング、と言った場合には、サーバーパラメータの調整や EXPLAIN コマンドを利用したクエリ実行計画の最適化が話題に上ることが多いです。しかし、発行する全ての AIN コマンドを使って確認していては、いくら時間があってもたりません。チューニングを効率的に進めるには、まず、ボトルネックとなっている MySQL Conference & Expo 2009 のキーノートにおいて Mark Callaghan 氏は、Google では SHOW PROCESSLIST コマンドを使った統計的アプローチを使っていると述べていらっしゃいます (参照: MySQLConf 09: Mark Callaghan, "This is Not a

  • ゆーすけべー日記

    サキとは彼女の自宅近く、湘南台駅前のスーパーマーケットで待ち合わせをした。彼女は自転車で後から追いつくと言い、僕は大きなコインパーキングへ車を停めた。煙草を一吸ってからスーパーマーケットへ向かうと、ひっきりなしに主婦的な女性かおばあちゃんが入り口を出たり入ったりしていた。時刻は午後5時になる。時計から目を上げると、待たせちゃったわねと大して悪びれてない様子でサキが手ぶらでやってきた。 お礼に料理を作るとはいえ、サキの家には材が十分足りていないらしく、こうしてスーパーマーケットに寄ることになった。サキは野菜コーナーから精肉コーナーまで、まるで優秀なカーナビに導かれるように無駄なく点検していった。欲しい材があると、2秒間程度それらを凝視し、一度手に取ったじゃがいもやら豚肉やらを迷うことなく僕が持っているカゴに放り込んだ。最後にアルコール飲料が冷やされている棚の前へ行くと、私が飲むからとチ

    ゆーすけべー日記
  • Linux チューニング - Ext3 のパフォーマンスを最大化させる

    じつは自宅サーバのロードアベレージが上がり続けています。分析の結果、ボトルネックは I/O 処理でした。ITACHI Deskstar T7K250 SATA2 250GB を RAID1 構成にしたのですが、今思えば速度優先で RAID0 にしておけば良かったと少しだけ後悔。 I/O がボトルネックに成っている理由ですが、Drk7jp が公開しているサービスの全てがキャッシュファイルを利用した高速化手法を取っているのですが、単純にそれらファイルの write 処理が追いついていません。常に何らかのプロセスで I/O 待ち状態が発生しているような状況です。抜的な解決方法としては disk を高速なものに交換する以外ありません。 というわけで

  • NFSのチューニング - 元RX-7乗りの適当な日々

    何故か遅いNFSをチューニングするべく検証。 # 5MBの書き込みに27秒もかかるのはちょっと。。。 下記の検証結果が、全ての環境であてはまるわけではないため、ご参考程度までに。 検証時の構成 Linux(Xen domainU) ---NFS mount---> Linux(Xen domain0)Xenのバージョンは3.0.2(linux kernelは2.6.16)。 # NICのデバイスも所詮はXenによって仮想化されているので、それほど参考にならないかもなぁ・・・。 実験内容 設定をいじる server: / NFSのチューニング - 元RX-7乗りの適当な日々

  • Devel::NYTProf - モダンなPerl入門 - モダンなPerl入門

    開発がひととおりすんだが、なぜか速度がでない。そんなときにはプロファイラの出番です。 Devel::NYTProf をつかえば、プログラムのどこで時間がかかっているのかがまるわかりになります。 使い方は簡単です。 perl -d:NYTProf target.pl nytprofhtml とするだけ。 mod_perl にも対応しています。 なにより Devel::NYTProf の出力する HTML がカッコイイのがポイントですね。 目次へ Last modified: $Date: 2008-05-22T09:21:23.154313Z $

  • PerlとRubyで省メモリなハッシュを使おう - mixi engineer blog

    サボっていた早朝ジョギング@駒沢公園を再開して2週間たち、やっと抜かれる数より抜く数の方が増えてきたmikioです。今回は、PerlRubyのハッシュの代用としてTokyo CabiPerlRubyのバインディングをリリースしました。それを使うと、各種言語のハッシュとほぼ同じような共通したインターフェイスで、以下のデータ構造を利用することができます。 オンメモリハッシュ:各種言語に標準のハッシュと同じく、メモリ上でkey/valueの関係を表現する。 オンメモリツリー:メモリ上の二分探索木としてkey/valueの関係を表現する。 ファイルハッシュ:いわゆるDBMとして、ファイル上でkey/valueの関係を表現する。 ファ

    PerlとRubyで省メモリなハッシュを使おう - mixi engineer blog
  • MySQLのEXPLAINを徹底解説!!

    以前、MySQLを高速化する10の方法という投稿で「EXPLAINの見方についてはいずれ解説しようと思う」と書いてしまったので、今日はその公約?を果たそうと思う。 MySQLのチューニングで最も大切なのは、クエリとスキーマの最適化である。スキーマの設計は一度決めてしまうとそのテーブルを利用する全てのクエリに影響してしまうためなかなか変更することは出来ないが、クエリはそのクエリだけを書き直せば良いので変更の敷居は低い。そして遅いクエリをなくすことは、性能を大幅に向上させるための最も有効な手段である。従って、アプリケーションの性能を向上させたいなら、まず最初にクエリのチューニングを検討するべきなのである。 最適化するべきクエリはスロークエリログやクエリアナライザで見付けられるが、ではそのようなクエリが見つかった場合にはどのように最適化すればいいのか?そのためにはまず現在どのようにクエリが実行さ

    MySQLのEXPLAINを徹底解説!!
  • なぜMySQLのサブクエリは遅いのか。

    よくMySQLはサブクエリが弱いと言われるが、これは当だろうか?半分は当で半分は嘘である。MySQLのサブクエリだってなんでもかんでも遅いわけではない。落とし穴をしっかり避け、使いどころを間違えなければサブクエリも高速に実行できるのである。今日はMySQLがどんな風にサブクエリを実行し、どのような場合に遅いのかということについて説明しよう。 EXPLAINで実行計画を調べた際に、select_typeにはクエリの種類が表示されるのだが、代表的なサブクエリには次の3つのパターンがある。 SUBQUERY DEPENDENT SUBQUERY DERIVED 結論から言おう。遅いのは2番目、DEPENDENT SUBQUERYである。DEPENDENT SUBQUERYとはいわゆる相関サブクエリに相当するもので、サブクエリにおいて外部クエリのカラムを参照しているサブクエリのことである。そし

    なぜMySQLのサブクエリは遅いのか。
  • mod_cgidso - なんとなく◎

    普通の CGI は実行ファイルを fork(), exec() して呼び出しますが, このモジュールでは共有オブジェクトを dlopen(), dlsym() して呼び出します. 構造的には,Apache モジュールのうちコンテンツ出力部分を分離して別ファイルとし, httpd との接続部分をこのモジュールが受け持つ形になっています. 普通の CGI のようなプロセス生成のオーバヘッドが発生せず,サーバ負荷軽減につながる. CGI をそのまま Apache モジュールに置き換えた場合,プログラムの 追加や変更の度に httpd の再起動が必要となるが,このモジュールを用いれば httpd の再起動なしに手軽にプログラムの追加・変更が可能となる. といったメリットがあります. # 来の意味での CGI とは異なるので,モジュール名に "cgi" と入っているのは おかしいと言えばおかしいの

  • anney's room - frei - dprofpp -O。

    Devel::DProf は便利なんだけど なんか変な結果が出ている。 リファクタ後、User+System Time は減っているのに Total Elapsed Time は増えている。うーむ。 仕方ないので、DProf の結果で細かくボトルネックを見ていくかーと思いつつも いつもの使い方だと、時間のかかった上位15位までしか表示されないので 何かオプションないかなー…と朝からカチャカチャ。 ・表示件数を指定 dprofpp -O 上位○位まで表示 ・アルファベット順で表示 dprofpp -a ・呼ばれた回数の多い順 dprofpp -l ・Total Elapsed Timeで表示 dprofpp -q ・System Timeで表示 dprofpp -s ・User Timeで表示 dprofpp -u ・特定の文字列を含むルーチンを除外 dpr

  • Google Code Archive - Long-term storage for Google Code Project Hosting.

    Code Archive Skip to content Google About Google Privacy Terms

  • はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知

    はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28

    はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知