現場で役立つRuby on Railsパターン(RubyKaigi2009)を聴いたまとめ - LukeSilvia’s diary
今年はRubyKaigi に行ってきました。今回聴いたセッションの内、いくつかのメモを残します。全てを1エントリーにまとめるのは量的にも厳しいし、エントリの切り方としても微妙なので小分けにして書いていきます。 あくまでメモなので間違いがあるかもしれません。特にコードについては詳細はメモしていなかったので必要な部分は自分で補完したりしました。 というわけで、最初は「株式会社万葉 大場さん」のセッションです。 Pragmatic Patterns of Ruby on Rails - 現場で役立つRuby on Railsパターン(大場 さん) 学生時代はAPI 仕様書を読むのが好きだった大場さんは、周りに同じような趣味を持つ人がいなくて孤独だった。Ruby コミュニティの人達に出会い感動し、自分も何かしたいと思ったと最初におっしゃっていました。 概要 今回のセッションの要点は次のようなことで
swatch でログを監視しよう - LukeSilvia’s diary
swatch とはログの監視に使用できるツールで、perl で書かれています。ログをリアルタイムで監視し、特定の文字列が書き込まれたらメールで管理者に通知することができます。 メールで通知をする以外にも、コンソールにメッセージを出したり、特定のコマンドを実行したりすることができます。 以下のページが参考になります。 ＠IT：サーバのログ監視ツールを使いこなそう（2/3） なお、今回Swatch を試した環境は以下のようになります。 CentOS 4.4 perl 5.8.5 cpan 1.03/CPAN.pm 1.7601 インストール swatch はいくつかのモジュールに依存しているので、まずはそれらをインストールする必要があります。ソースからインストールする方法もありますが、今回はCPAN からインストールします。ソースからインストールする場合は、直前に紹介した参考ページを参考にして
データベースを用いたセッションデータ管理について - LukeSilvia’s diary
Web アプリケーションとは切っても切れないセッション機構。DB ベースでセッション管理を行なって得られた知見と、それを元に考察した結果をまとめてみます。 セッションデータの特性 DB で管理される他のデータに比べ、セッションデータはかなり特殊です。主な特徴は次のような感じ。 データが増加するのが速い 定期的な削除が必要 頻繁に更新される リクエスト毎に読みに行く必要がある このデータを読めないとアプリケーション全体にアクセスできない アクセス頻度が高いということです。あと、1つ目の特徴からセッションデータについては意識的に管理してやる必要があります。 現在の環境 アプリケーションの領域が少し特殊で、セッションデータがやたらたまります(ユーザ数何百万のサービスとかそういうのではないです)。 RDBMS MySQL 4.0.22 ストレージエンジン InnoDB レコード数 6千万 テータサ
git 環境のセットアップと簡単なチュートリアル - LukeSilvia’s diary
ソーシャル化するOSS開発者たち − ＠ITとGitHub Issue Tracker! - GitHubを見て、github がとても楽しそうなので、git を使い始めました。 http://github.com/lukesilvia/ 良く使いそうなコマンドとかを調べたのでメモ。 git インストール インストール Mac なので、macports 使う $ sudo port install git-core +svn +gitweb $ git --version git version 1.6.2.1 今までsvn 使っていて連携したので「+svn」 gitweb あると、ブラウザからリポジトリをブラウズできるので入れる PATH を通す 以下をPATH に追加 /opt/local/libexec/git-core git の場合、git rm とかの後にファイル名の補完が効か
大きめのテーブルにカラムやインデックスを追加する際の注意 - LukeSilvia’s diary
先日大きめ(といっても500万行くらい)のテーブルにインデックス付きのカラムを追加しようとして痛い目にあったので調査。 大きめのテーブルにカラムやインデックスを追加するとどうなるか 今回は単純に、「ALTER TABLE 〜 」で追加しようとしました。追加するカラムは3つで、 varchar(255) インデックスなし varchar(255) ↓のdate 型カラムとマルチカラムインデックスの形式のユニークインデックスあり date インデックスあり SQL を実行し、状況を「SHOW PROCESSLIST」で監視していたら、1つ目のカラム追加で次のような状態に… 最初にState が「copy to tmp table」状態になり、次の状態に遷移するまで1時間かかる 次にState が「Repair with keycache」状態になり、完了までに1時間かかる 次のカラム追加に対す
MySQL とメモリに関するまとめ - LukeSilvia’s diary
前回のエントリーデータベースを用いたセッションデータ管理についてで、MySQL とメモリの関係について良く分からない部分があると書きました。 実はここに関する理解はかなり曖昧な部分があって、調査して追記します。とくにメモリ利用量について。mysqld のプロセスが利用できるメモリの上限が、32bit OS の場合は3G 程度ということは、innodb_buffer_pool_size もこの制限を受け、これについての警告が、先に紹介したリファレンスマニュアルのものという理解だけどいいのだろうかというのが1つ。 2 つ目は、この理解があっているとすると、4G 以上のクラスのメモリをつんだサーバをDB サーバとして利用する場合、64 bit OS でないとリソースの有効活用ができないか。それとも、先に書いたとおり、OS レベルのキャッシュとして利用できるから、結果としてデータファイルを読み込む
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
