Railsのログからリクエスト時間ごとや閲覧回数ごとなどのランキングを生成してくれるツール: ぐうたら技術屋のTips
Rawk - Ruby on Rails Log Analyzer 時間のかかっている処理をログから抽出したいと思い検索し見つけたツールです。 ただのRubyのスクリプトで $> ruby [ダウンロードしたスクリプトファイルのパス] < [対象のログファイルのパス(production.log等) で解析し、コンソールに結果を出力してくれます。 ただ、現時点の最新(1.2)が私の環境(Rails 1.2.5)のログだとうまく動いてくれず(ZeroDivisionErrorが発生)、スクリプトを修正する必要がありました。 修正は、スクリプトの181行目に対し以下のように行いました。 修正前) next unless $_.index("Completed in") == 0 修正後) next unless $_.index("Completed in") 同じ現象が発生するなら試してみて
MySQLノウハウ
いろいろな本からメモってきたメモのメモ。出典を書いておくのを忘れた。思い出し次第補完するかも。 deleteのコストは高いので、無効化を示すフィールドを作ってupdateすべき slow query logに要注意 多くのエントリでほとんどのフィールドが同じ値を持つ場合はインデックスの効果が小さい →複合インデックスの効果が大きい 複合インデックスは指定の順番が大切。AとBという指定の場合、A単独でもインデックスの効果がある。逆は真でない。 インデックスが使われる場面は フィールド値を定数と比較するとき (where name = 'hogehoge') フィールド値でJOINするとき (where a.name = b.name) フィールド値の範囲を求めるとき (<,>,between) LIKE句が文字列から始まるとき (where name like 'hoge%') min(),
MySQLの状態がリアルタイムでわかるMySQL用topコマンド「mytop」と「innotop」
サーバのチューニングをする上でかなりやっかいなのがデータベース系。特にログファイルの量が膨大になると後から中身を見て問題を分析するのも一苦労という場合が。そんなときにこのMySQL用topコマンド「mytop」を使えば一体何が起きているのかがすぐにわかるので問題点の把握が容易になります。ベンチマークするときに併用すればかなり効率が良くなるのではないかと。 インストールと使い方は以下の通り。 まずは「mytop」から。以下が公式サイト。 mytop - a top clone for MySQL http://jeremy.zawodny.com/mysql/mytop/ マニュアルは以下にあります。 mytop - display MySQL server performance info like `top' インストールするにはSSHなどを使ってrootでログイン後、wgetでファイル
「ちょっと待て」 真・MySQLのクエリを最適化する10のTips：CodeZine
Jaslabs: High performance phpで紹介された「MySQLのクエリを最適化する10のTips」に対して、反論している人がいる。ブログ「20bits」のJesse氏だ。彼は「10 Tips for Optimizing MySQL Queries (That don’t suck)」というエントリーで、Jaslabs氏の記事は適切でないとしている。 Jesse氏の経験によれば、SQL最適化で最も重要なことはSQLやDBの基本をしっかりと理解することであり、60％がこれで解決するという。残り35％はDBやクエリの特殊な性質に対する対処であり、最後の5％で発想の転換などを求められる。Jaslabs氏はここにばかり力を入れており、それはまったくもって時間の無駄だと述べている（Jesse氏は「SQL_SMALL_RESULTなんて、生まれてこの方使ったことすらない」とまで言
naoyaのはてなダイアリー - 負荷とは何か
調べごとをしたので blog に書いて理解を深めようのコーナーです。長文です。 Linux でシステム負荷を見る場合にお世話になるのが top や sar (sysstat パッケージに同梱されてるコマンド) などのツールです。 top ではシステム統計のスナップショットを見ることができます。今システムがどういう状態かなーというときは top が便利。 top - 08:16:54 up 3 days, 14:43, 6 users, load average: 0.18, 0.07, 0.03 Tasks: 43 total, 2 running, 41 sleeping, 0 stopped, 0 zombie Cpu(s): 18.2% us, 0.0% sy, 0.0% ni, 81.8% id, 0.0% wa, 0.0% hi, 0.0% si一方の sar では10分ごとのシ
DBサーバ向けLinuxチューニングを考える 〜 メモリオーバーコミット編 : DSAS開発者の部屋
Cでプログラムを書いていて大量のメモリを確保したくなったとき、大抵は mallocを使うと思いますが、その際には戻り値がNULLかどうかを判断してエラー処理に飛ばすと思います。しかし、Linux のメモリ管理サブシステムには「メモリ・オーバーコミット」という機構があり、実装されているメモリ以上の領域を確保できてしまいます。 #include <stdio.h> #include <stdlib.h> int main() { int i; char *p; for(i=0;i<65536;i++){ p = (char *)malloc(65536); if(0 == (long)p){ break; } } printf("SIZE=%dMB\n",i*65536/1024/1024); return(0); } swapoff したメモリ 1G のマシンでこれを実行するとこんな感じにな
Open Tech Press | Linuxのスワップ処理を最適化するためのヒント
コンピュータのメモリ容量を超えるサイズのプログラムを実行する必要がある場合、最近のオペレーティングシステム（OS）のほとんどはスワップ処理と呼ばれる手法を用いる。これは、メモリ内データの大部分を一時的にハードディスクに格納しておき、必要なデータだけを物理メモリ空間に持ってくるというものだ。本稿では、Linuxシステムにおけるスワップ処理の効率化とスワップ処理サブシステムのパフォーマンス最適化につながるテクニックを紹介する。 Linuxは、物理メモリの領域をページという単位に分割して処理する。スワップ処理とは、ハードディスク上にあらかじめ設定した空間（これをスワップ空間と呼ぶ）にページ単位でメモリ上のデータをコピーし、そのページのメモリ領域を解放する処理をいう。物理メモリとスワップ空間を合わせた容量が、仮想メモリとして利用可能になる。 スワップ処理が必要になる主な理由は2つある。1つは、物理
大規模サイトのLinuxカーネルチューニング
大規模サイトの為のLinuxカーネルチューニング (Linux kernel tuning for large site) 文責: もりかわひろかず * ** 大規模なサービスを行うサーバOSとしておこなうべき チューニングの定石について記述します kernelのバージョンは2.4.31を対象にしています (もう2.6でしょう) (2.4版のメンテやめます) OSのデフォルト設定は一般的な規模を想定しています それを逸脱するような大規模な用途(大規模なwebサーバ、 web cache(squid)サーバ、バーチャルドメインサーバ[仮想サーバ])に使用するには、 やはりそれなりのチューニングが必要になってきます 以下で、そのチューニングの定石を列挙します (なぜチューニングが必要なのか) (個々の値については各サイトで調節してください) (以下のパラメータは I
Ruby on Railsのパフォーマンス向上に関する10のtips:
という記事があった、色々と面白かったので訳してみる。良いとこも悪いとこもあると思うけど参考までにメモとして 元記事：Top 10 Ruby on Rails performance tips Rubyの基本的なコードを見直してみる自分で作ったクラスよりもできるだけ組み込みのクラスライブラリを使うできるだけ正規表現を使用する、文字列処理にコストの高いループは避けるREXMLは遅いのでLibxmlライブラリを使用する （Cで書かれたXMLパーサらしい、環境に依存するのは嫌かもしれない）if文の多用は避ける、例えば||=を使う ( z||="none" で unless(z){ z = "none" })Hashはコストが高いので他のデータ構造を検討してみる （でも使いたいときあるよね？）キャッシュを有効活用する acts_as_cached でModelをキャッシュ化してみる(PDF資料
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
更新があるシステムにはInnoDBを選ぼう。MyISAMを選択するならそれなりの理由が必要。それにInnoDBのパフォーマンスはそんなに悪くないよ。 || パフォーマンスチューニングBlog: インターオフ