sanonosa システム管理コラム集: サーバのボトルネックはどうやって調べるか
サーバのレスポンスが遅くなると経験のないサーバ管理者は無意味にメモリ増強を行ったりしますが、行き当たりばったりのシステム拡張は無駄な投資につながります。ボトルネック個所の調べ方は案外簡単なので、この際押さえるところをきちんと押さえて正しい方法論でシステム拡張をしていきましょう。 【一般論】 ボトルネックとなりうる要素は主に４つです。 ①CPU使用率 ②メモリ使用量 ③ディスクI/O ④TCPコネクション数 これらを押さえておけばボトルネック個所の把握とその解消は難しくありません。これを踏まえた一般論を述べてみたいと思います。 WEBサーバの場合は多くの場合、TCPコネクション数から先に限界が来ます。OSやApache等のWEBサーバのパフォーマンスチューニングを十分施すことが前提ですが、その場合TCPコネクション数1万くらいまではなんとか保てると思いますが、それ以上のTCPコネクショ
マルチコア時代のロードアベレージの見方 - naoyaのはてなダイアリー
ちょっと煽り気味のタイトルですが、CPU がマルチコアになり 2個、4個と増えていく中 Linux の負荷の指針になるロードアベレージをどう読むべきか、という話です。気になったところを少し調べたのでそのまとめを。 http://d.hatena.ne.jp/naoya/20070222/1172116665 でも書いたとおり、Linux のロードアベレージは「ロードアベレージは過去1分、5分、15分の間の実行待ちプロセス数の平均数 = 実行したくても他のプロセスが実行中で実行できないプロセスが平均で何個ぐらい存在してるか」を示す値です。ボトルネックが CPU、メモリ、ディスク等々どこにあるかは関係なく、仕事の実行までにどれぐらい待たされているかを示す値なので、システムのスループットを計測する指標の入り口になる値です。 このロードアベレージですが、実装を見るとランキュー(待ち行列)に溜まった
800万人の"食べたい"をHadoopで分散処理
Константин Макарычев (Sofware Engineer): ИСПОЛЬЗОВАНИЕ SPARK ДЛЯ МАШИННОГО ОБ...Provectus
DataMapper、バージョン1.0へ到達
原文(投稿日：2010/07/21)へのリンク DataMapperはRuby向けのオブジェクトリレーショナルマッパーであり、最近マイルストンが1.0へとたどり着いた。このリリースはRailsConf 2010の間にDirkjan Bussink氏のプレゼンテーションで発表された。 DataMapper(DM)はこの2年間、コミュニティプロジェクトによって育てられてきた。DMは高速でスレッドレーフで多機能なORMだ。InfoQは主要な開発者であるDan Kubb氏と話す機会を得た。 DataMapperはバージョン1.0がリリースされたが、これは前バージョンの0.10からの大きなそして重要なバージョンアップだ。氏はこのマイルストンの内実を教えてくれた。 1.0へバージョンアップするかどうか決めるのはちょっと難しかったです。1.0は完璧ですべての課題を解決していてほしいという考えがある一方で
Rails3 対応 MongoDB ORM、Mongoid 詳解―ドキュメント - ζ*’ワ’)ζ＜ちれすですの！
インストールに引き続き、ドキュメントを解説します。 ドキュメントは Mongoid のコアオブジェクトであり、データベースに永続化したい全てのオブジェクトは、Mongoid::Document をインクルードしてください。MongoDB でのドキュメントは、BSON オブジェクトとして表現されており、これは Ruby のハッシュや JSON によく似ています。Mongoid のドキュメントは、データベースのコレクションに格納されるか、他のドキュメントにエンベッドされ階層化された形で格納されます。Mongoid ではエンベッドされたオブジェクトもモデルとして表現できるという意味です。 ドキュメント定義 Person を表すシンプルなモデルを考えてみましょう。Person は、first name と last name と middle initial を持ちます。Person オブジェクト
Rails3 対応 MongoDB ORM、Mongoid 詳解―関連 - ζ*’ワ’)ζ＜ちれすですの！
Mongoid::Document は、embeds_one, embeds_many, embedded_in といった、ActiveRecord スタイルの3つのマクロを通して、他のドキュメントに対して関連を設定することができます。関連を設定すると、1つのドキュメントが他のすべてのドキュメントのルートになり、全ての関連付けられたオブジェクトはルートドキュメントに埋め込まれます。リレーショナルな関連はこれらのマクロでは設定できません。後述するリレーショナルな関連の項を見てください。 先の例の Person モデルが、他のドキュメントと関連する場合を考えてみましょう。 app/models/person.rb: class Person include Mongoid::Document field :first_name field :last_name embeds_one :addr
Rails(ActiveRecord)でデータベースへのコネクションプーリングをさせなくする - はまさき
ActiveRecordを使ったRailsアプリは，デフォルトでデータベースへの接続をプールするようになっています． ActiveRecordユーザとしては待ちわびたぜ！的な機能らしいのですが，設定等でこれをdisableすることが出来ず，LVS+keepalivedを介する場合にはロードバランシングが最初の接続時にしか為されずがなかなか厄介です． 対策として思いついたのは プールした接続を早い周期で捨てる LVS+keepalivedではなく，MySQL Proxyでバランシングする(Proxyへの接続はプール) そもそも接続をプールさせない くらいでした． どうするのがセオリーなのかと調べてみると コネクションプーリングの話 - naoyaのはてなダイアリー 2006-09-03 など4年近く前に議論されていて，"あー，高速道路あるなあ"と，コネクション確立のコストを調べる前に「プール
Passenger + monit でリリース作業をより簡単にする方法 - よかろうもん！
PassengerでRAILSアプリを運用しているなら、アプリのリリース時には、${RAILS_ROOT}/tmp/restart.txt を配置/更新することで、ほぼダウンタイム無し(httpdの再起動なしのため)にリリースしているかと思います。 ただ、アプリケーションのソースコードの影響範囲が、Railsアプリのみだけなら、restart.txtの仕組みだけでよいかもしれません。しかし、パフォーマンスを考慮し非同期処理を行うためにdelayed_jobを利用していたり、メール送信流量を制限するためにar_sendmailなどを利用している場合は、それぞれのデーモンの再起動を行う必要があります。 ＃delayed_jobについては、id:mat_aki(@mat_aki)が紹介している「Railsで非同期処理を行うには"Delayed_job"がおすすめ」がわかりやすいと思います。 その
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://www.func09.com/wordpress/archives/951