マルチコア時代のロードアベレージの見方 - naoyaのはてなダイアリー
ちょっと煽り気味のタイトルですが、CPU がマルチコアになり 2個、4個と増えていく中 Linux の負荷の指針になるロードアベレージをどう読むべきか、という話です。気になったところを少し調べたのでそのまとめを。 http://d.hatena.ne.jp/naoya/20070222/1172116665 でも書いたとおり、Linux のロードアベレージは「ロードアベレージは過去1分、5分、15分の間の実行待ちプロセス数の平均数 = 実行したくても他のプロセスが実行中で実行できないプロセスが平均で何個ぐらい存在してるか」を示す値です。ボトルネックが CPU、メモリ、ディスク等々どこにあるかは関係なく、仕事の実行までにどれぐらい待たされているかを示す値なので、システムのスループットを計測する指標の入り口になる値です。 このロードアベレージですが、実装を見るとランキュー(待ち行列)に溜まった
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分ごとのシ
「Web開発者のための大規模サービス技術入門」という本を書きました - naoyaのはてなダイアリー
自分が作ったWebサービス、将来大きくなってもシステムは大丈夫なんだろうか? そんな不安を抱きながらWebサービス開発に携わっている方も多いでしょう。あるいは、毎日毎日システムが悲鳴を上げる、どうしたらこの状況を看破できるんだろう? 成長したWebサービスを前に、困っている技術者の方もいるかもしれません。 筆者も、まったく同じ経験をしてきました。 月間1,500万人が訪れる、はてなというサイト。その大規模システムの開発と運用に、筆者らは取り組んでいます。1,000台のホストが、その負荷を捌きます。100万人以上のユーザによってブログやソーシャルブックマークに投稿され続けるデータは日々大きくなっていき、サーバリソースを逼迫させます。ギガバイト、テラバイト単位のデータ量が技術者たちを悩ませます。それでもトラフィックの波は収まることを知りません。 (中略) どうしたらこの怪物、大規模サービスを抑
CodeZine にて KOF 2008 の記事と補足 - naoyaのはてなダイアリー
大阪南港ATCで開催された「関西オープンソース2008」の2日目（11月8日）午前中のセッションで、株式会社はてなCTOの伊藤直也氏が「はてな流大規模データ処理」と題した発表を行った。 CodeZine で先日の KOF 2008 (あらかじめ言っておきますが King of Fighters ではないですよ、関西オープンフォーラムです) の発表を記事にしていただきました。ありがとうございます。 発表資料は以下のエントリーにありますので一緒にご覧いただければと思います。 http://d.hatena.ne.jp/naoya/20081111/1226395400 さて、記事内容について少し補足をしておきたいと思います。 メモリとディスクの速度比較について 「メモリはディスクの 150 倍」という話ですが、その後知人と話して検索のインデックスをシークする場合などは ms 対 ns くらい違
KOF 2008 の発表資料 - naoyaのはてなダイアリー
KOF 2008 での発表資料「はてな流大規模データ処理」を以下にアップロードしました。 http://bloghackers.net/~naoya/ppt/081108huge_data.ppt 一部参考文献からの引用 (Introduction to Information Retrieval から Vector space model の図、たつをの ChangeLog から転置インデックスの図) があります。この場を借りて感謝。 環境によってはおそらくフォントの表示がいまいちだと思いますが、ご了承ください。 追記 SlideShare にアップロードしました。 081108huge_data.pptView SlideShare presentation or Upload your own. (tags: linux mysql) 追記: メモリはディスクの 150 倍について
あるプロセスが利用しているメモリサイズを procfs 経由で調べる - naoyaのはてなダイアリー
お題は「あるプロセスがどの程度の物理メモリを利用したかを知りたい」です。 手っとりばやく知りたいときは top や ps などで調べると良いでしょうか。例えば手元の coLinux で top して M キーでソートすると emacs のプロセスが最もメモリを使っているようです。 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1923 naoya 18 0 23120 19m 3096 S 0.0 2.0 0:55.40 emacsメモリサイズは VIRT と RES がありますが、VIRT は Virtual の略で仮想メモリ領域のサイズ、RES が Resident の略で、実際に使用している物理メモリ領域のサイズ。19MB ほど使っているようです。この emacs のプロセスが利用するメモリ領域はざっくり 20MB 程度と
naoyaのはてなダイアリー - ライブドアの技術の話
今回のライブドアの件で、「ライブドアは虚業」、とか「日本のネット企業は心を改めて技術を磨け」みたいな論調を良く見かけるわけですが。 いずれ誰かが書くだろうと思っていて、やっと出てきたライブドアの技術の話。 ライブドアが意外と技術系っぽいことについて - 圏外からのひとこと ライブドアが普通に技術系であることについて - 圏外からのひとこと ライブドアの直近の財務諸表なんかを見ると確かに証券周りなどの売り上げの占める割合が多かったりもしますが、その企業の設立当初から今に至るまでその屋台骨を支えてきたのは間違いなくライブドアが持っている確かな技術で、日本のウェブ関連企業の中でもその技術レベルの高さは、その辺でなんとか 2.0 だとか声高に言ってる企業なんかよりも遙かに高いと思ったほうが良いでしょう。 圏外からのひとことの中で示されていたポインタ以外にも、最近の取り組みは以下のリンクが参考になる
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
