[時間割:サーバ]『コンピュータの構成と設計（上）』読了
2008/09/24 23:39 posted by kunkichi
ふぅ〜、ちょっとバタバタしててアウトプットが追いつきません、泣
でもちゃんと勉強はしてます。
水曜日は『サーバ』の時間、ということで、やっと読了しました、パタヘネ本上巻。
デイビッド・A. パターソン ジョン・L. ヘネシー
日経BP社
売り上げランキング: 9857
いやー、ちょっとさすがにこれは難しかった。
何が難しいかって、
- 上巻はCPUの実装についてがほとんど。ガチッと「わかった！」っていう感はほとんどなし。せいぜい「な〜んとなくイメージが見えてきたかなぁ〜、、、」っていうレベルが限界です、、、
- Cのプログラムがコンパイラでアセンブラになる過程、ってアセンブラの一つ一つの命令まで落とされるとさすがに未知の世界。しかもMIPS。２、３章はかなり苦しかった、、、
だもんな〜、くぅ〜、泣
でも、苦しいながらも、非常にためになった箇所もたくさんあって、
- 半導体が作られる過程って初めて知った！
- レジスタとかスタックとかヒープとか。CPUとかメモリとかがボトルネックになったような経験はないのだけど、OSの動作原理として、やっぱりこういうデータのやり取りの流れを知るのはほんと楽しい。
- コンパイラの変換ステップとか最適化の仕組みとか。最適化を進めることで捨てなきゃいけないものが出てくると。
- 性能評価については、パフォーマンスとか機器増設計画とか、いつも気になっていることに直接関連することなので、考え方はものすごく参考になった。
あたりは非常に面白かった。噂通りの良書でした。もっとスキルあげて、この本をもう一度読んだときに一緒に成長を感じ取れるようにがんばらないと。
引き続き、下巻に移りたいと思います。
デイビッド・A. パターソン ジョン・L. ヘネシー
日経BP社
売り上げランキング: 15038
Category: Server, Book | コメント＆トラックバック（0）
[時間割:サーバ]『Linuxカーネル徹底解析』読了
2008/09/11 00:33 posted by kunkichi
水曜日は『サーバ』の時間。ということで、カーネルの勉強をしようということで選んだ「Linuxカーネル徹底解析」を読み終わりました。
日経BP出版センター
売り上げランキング: 94500
とりあえず、一通り読んでみて、なんとなくOSの全体的な処理のイメージみたいなものが見えてきた感じです。個人的に特に面白かったのは以下あたり。
- ファイルシステム。これは一番面白かったし、過去ディスクI/Oには常に悩まされてきたので。inodeにファイル名が含まれないとか、ページキャッシュとの連携の仕組みとか、LVMのスナップショットの原理とか、なんか今まで悩んだり疑問に思ってたけどわからなかった、たくさんのことがやっとつながった気がして、すごい納得した。
- メモリのところは、上でも書いたけど、一番はページキャッシュかな。スワップ処理とかのほうがメモリ絡みだと悩んでる人多いと思うんだけど、DBサーバみたいにメモリどっぷり使うようなサーバ管理したことってそんなにないんだよね。でもスワップインの処理は面白かったです。
- あと、ブートシーケンスも外せない。でもここは他の記事に比べるとちょっと浅め。別の本でもうちょっと深く勉強して、ディスクレス＆オンメモリで動くFWとかLBとか作りたい！
- プロセスやらページキャッシュやらネットワークやら、全般的に「ステータスに応じた処理や状態遷移」ってのは日頃からもっと意識するようにしなきゃ。
- デバイス関連はさすがにちょっと難しかったです、、、、
まずは概要がつかむっていうのが当初の目的だったので、それについてはある程度果たせた気がするし、最初の書籍としてはとてもよかった気がします。それに現時点で「C言語の知識が絶対的に足りない」ってこともわかったので、今やっている「C言語」の勉強の正当性が証明されて、モチベーションが多いにあがりました。
さて、次はどうしようかな。Linuxカーネルについてさらに進めてもいいんだけど、そのためにはCをもう少し勉強したほうがいいかなという気もするので、もう少しマクロな視点、というかハードウェアな部分も含めてコンピュータそのものの理解を深めてみるということで、これを選んでみました。
デイビッド・A. パターソン ジョン・L. ヘネシー
日経BP社
売り上げランキング: 37621
トピック的にはマクロかもしれないけど、パラパラっと見た感じアセンブリやらマシン語やらかなり細かいところまで出てきて、既に若干くじけそうですが（爆）なんとかがんばりたいと思います
Category: UNIX, Server, Book | コメント＆トラックバック（0）
『日経Linux』でカーネル特集始まった
2008/09/08 20:58 posted by kunkichi
一時期はたくさんあったLinux関連雑誌だけど、今では冠にLinuxとあるのは『日経Linux』だけになってしまったなー。で唯一残ってる『日経Linux』なんだけど、あの大きさと値段がどうしても気に入らなくて、ほとんど買うことなかったんだよね。
ただし、今月からは別。
日経Linux - 2008年10月号
<<特別連載>> 図解 触って学ぶLinuxカーネル
各種のツールを駆使してカーネルの中を実際にのぞいて見ます。それにより，カーネルの仕組みを体で学びます。第１回は準備編として，メモリー管理とマルチタスクの仕組みを解説します。
第1回●メモリーとプロセスの管理
「触って学ぶ」っていうところは実際に体験することでより理解が深まりやすいと思うしなかなかよさげな感じ。ただし、やっぱり「ソース読んで」っていう部分とセットだからこそ、知識と体験が組合わさると思うので、ソースへの理解も深めていかないと。しばらくは買ってみようかなと思います、でもCD-ROM要らないからもちょっと安くなってほしいなぁというのは強い願い、、、
で、僕に取ってはそんな微妙な『日経Linux』だけど、ムックは悪くないのもありました。まあ初心者向けはちょっとおいといて、今読んでる『カーネル徹底解析』含めて↓の辺は、浅くもなく深くもなく、全体像をつかむにはなかなかよい内容だったので紹介しておきます。
日経BP出版センター
売り上げランキング: 25440
Category: UNIX, Server, Book | コメント＆トラックバック（1）
[時間割:OS]『Linuxカーネル徹底理解』
2008/08/27 23:41 posted by kunkichi
水曜は「OS(カーネル)」と「サーバ」の時間。まず、「OS(カーネル)」のテキストにはこれをチョイス。
日経BP出版センター
売り上げランキング: 100628
amazonの評価で星がついている割にはコメントはちょっと辛口。まあムック形式なのであまり細かいところまではカバーできないのもわかるので、とりあえずこの本で概要の部分をある程度理解のベース部分を固めようというところ。薄いので何度も読み返すにはちょうどいいし。
トピックが大きいのでなかなかアウトプットが難しいんだけど少しずつ出していきたいと思います。
ちなみに今は「シグナルと割り込み」のところ。今まで読んだところではメモリとファイルシステム、特にページキャッシュのところは、すごく面白かった。ちょっとsarを使う時の見方が変わった気がする。
「サーバ」のほうはまたちょっとcobblerの日本語訳を進めています。
Category: UNIX, Server, Book | コメント＆トラックバック（0）
[時間割:サーバ] ntpのログで”too many recvbufs allocated (40)”
2008/08/21 00:08 posted by kunkichi
ある時からntpサーバのntpログでちょっと気になる出力が。サーバ絡みなので勉強と称して調査。
too many recvbufs allocated (40)
これが延々、とは言わないまでも、バラバラっと出力されてしばら〜くしてからまたバラバラっと、っていうのが繰り返される。でいろいろ調べてみたところ、とあるMLにこんな投稿が。
[time] Increasing recv buffers on FreeBSD
・・・
My logs are routinely filled with things like
Apr 25 11:36:21 n118 ntpd[56093]: too many recvbufs allocated (40)
Apr 25 11:36:21 n118 last message repeated 3 times
Apr 25 14:17:03 n118 ntpd[56093]: too many recvbufs allocated (40)
Apr 25 14:17:03 n118 last message repeated 3 times
・・・
It appears that I am dropping requests that I could otherwise answer.
I’ve got the bandwidth, memory and CPU to handle more than I’m currently taking, so I’m wondering if anyone knows how to increase the udp receive buffers on FreeBSD (6.2-RELEASE p3)
うん、一緒一緒。Load Average、CPU使用率、メモリ、トラフィック、全部余裕あるところも一緒。
で、そのレスが以下。
[time] Increasing recv buffers on FreeBSD
It’s not the kernel; that message comes from /usr/src/contrib/ntp/libntp/recvbuff.c around lines 161 & 225:
・・・
/*
* Check to see if we're below the low water mark.
*/
if (free_recvbufs <= RECV_LOWAT)
{
if (total_recvbufs >= RECV_TOOMANY)
msyslog(LOG_ERR, "too many recvbufs allocated (%ld)",
total_recvbufs);
・・・
It appears that you can change this definition of RECV_TOOMANY here:
% grep -n RECV_TOOMANY */*
include/recvbuff.h:18:#define RECV_TOOMANY 40 /* this is way too many buffers */
As far as I can tell, this only happens if ntpd gets a whole slew of requests at once before it can generate some replies, and it simply results in ntpd dropping the requests…
ってことで、どうやらntpのソース内で受信バッファが定義されていて、瞬間的に大量のパケットを受信したため、バッファからあふれてしまったということの様子。バッファから溢れてしまったのはもちろん落ちちゃっているので、クライアントからのリクエストに対してレスポンスはなくなっちゃってるってことだよねぇ。
で実はここまでは既にわかっていて、パケットキャプチャすると確かにクライアントのリクエストに対してサーバのレスポンスが少ないんだよね、まあ頻度的にはそれほど多くはないのだけど。
ただ、上の理由は僕のシチュエーションだとちょっと納得できない。なんでかというと
- 突然起きたのなら、クライアントが急に増えたとかっていうような変化があったはず。でも調べてみたところ、そういうことはない。
- クライアントのリクエストに対してサーバのレスポンスが返らないのであれば、サーバ側のトラフィックとしては、INは変わらないけど、OUTが減る、っていうのが考えられるけど、トラフィック自体は両方とも同じぐらい減ってる。
からなんだよねぇ、、、不可解だ。
別の投稿がGoogle Groupsにも上がっててこっちは最新版にバージョンアップしろって書いてあるんだけど、最新版(4.2.4p5)のソース見ても上で指摘されている部分は全く変更ないしなぁ。まあバッファを増やしてビルドし直せばログは出なくなるんだろうけど、なんだかなー。
とりあえず今のところテストで再現できてないのでそれをなんとか、って感じ。NTPの負荷テストなんてやったことないしツールもないみたいだし、ちょっとPerlで書いてみることに。Net::NTPでクライアントからのアクセスをParallel::ForkManager使って並列で多量に実行する感じ。
#!/usr/bin/perl -w
use strict;
use warnings;
use Net::NTP;
use Parallel::ForkManager;
my $pm = new Parallel::ForkManager(1000);
foreach my $i (1..100000){
$pm->start and next;
my %response = get_ntp_response("XXX.XXX.XXX.XXX",123);
foreach my $key (keys %response)
{
print "$key --> $response{$keys}¥n";
}
$pm->finish;
}
$pm->wait_all_children;
うーん、どうかなぁ。とりあえず明日実機で試してみよう。
Category: Server | コメント＆トラックバック（0）
[24svr-TechMTG]感想
2008/08/09 00:34 posted by kunkichi
ということで感想。
この本を書いたわけ（ひろせさん＠KLab）
・こういう本を待ってました。
・情報発信することで横のつながりができる。やっぱりアウトプット重要。
Linuxカーネルの読み方（naoyaさん＠はてな）
・「根拠のない対処療法」ってところにグッときた。
・GNU Global、App::Ack あとで試す。
・『linuxカーネル解析入門』チェックする。
・Linux Kernel Hack Japan ブクマ
・『本を読む本』
・やっぱりC重要。gcc拡張とか遠いけどがんばる。
・CPUというかハードウェアも勉強しないと。
・『64ビットがわかる』『初めて読む〜』
・writing a simple file system ブクマ
・理論的に攻めたい。
DSASのこれから（安井さん＠KLab）
・tomcatなのか。
・悔しさオリエンテッド。なんとかしたいというモチベーション重要。
・たくさんの懸念はのためにやるべきことをすこしづつやっていく。
はてなのインフラ、いまむかし（田中さん＠はてな）
・やっぱり少しずつ改善・成長が重要。
・MySQLマルチマスタ化は気になる。
・ディスクレス・オンメモリで疎結合。やらなきゃ。
・Hadoopはまだちょっと難しすぎると思ってたけど、確かにログ解析で悩み中。
・capistrano、puppet、seleniumもやりたい！
・PXEとか独自RPMレポジトリならCobbleもいいよ、とか言ってみる
Xenならkoanもあるし。っとドキュメント翻訳がんばらないと。
・「体力勝負」っていう「根性論」はなしとはおもうけど、「気合い」とか「男気」とか
っていうモチベーションとかチームの結束という意味での「根性論」は必要な気がする。
naoyaさんも言っていたけど、先人の苦労や工夫がこういう形で公開されることはほんとうにありがたいことです。いつかそっちの立場になって少しでも貢献できるようになりたい。
ということで、今から読みます。しかし、本を買ってその勉強会でまた買わなきゃいけない本が増えるとは、笑。でも楽しい。
Category: 24svr-TechMTG, Server | コメント＆トラックバック（0）
[24svr-TechMTG]まとめ
2008/08/08 23:55 posted by kunkichi
ほぼリアルタイムで追っかけてみる→失敗、orz
この本を書いたわけ（ひろせさん＠KLab）
・見逃した。
→ustreamあとで見れるの知りませんでした。
・本を作った訳
※会社返りに買ってきた！今から読む。
・mod_cidr_lookup
Linuxカーネルの読み方（naoyaさん＠はてな）
過去の対応
・負荷が高いとき
・apacheアクセス過多
・IO高い
↓
・ググってみる
・変えてみる
→根拠のない対処療法
ソースを読んで根拠に基づいて統計から原因を特定
・『BINARY HACKS』とか『詳解Linuxカーネル』とか
・当初難しいと思っていた→ そうでもないよ
俺流読み方
・ツールで効率よく読む
・gnu global - ソースコードタグシステム
emacsで関数の定義場所と呼び出し場所を行き来できる
・app::ack
perlモジュール、grepよりも検索しやすい、コマンドでできる
・書籍
同じテーマで別の書籍を読む
『linuxカーネル解析入門』
・紙／ペン
コールスタックが深いと迷子になるので処理フローをメモ
・Linux Kernel Hack Japan（サイト）
コツ
・読む対象を絞る
隅々までよまない、テーマを決めて読む
・いきなり読まない
全体把握から。本の目次と同じ。
『本を読む本』
・概観を知った上で読む
本とかで概要をあらかじめ押さえてから読む。
・重要なデータ構造を把握しておく
プロセスとかよく出てくる構造体などのデータ構造は先にざっくり把握
しておくと楽。
・テストプログラムを活用
実際の動きを確認するために。
読んでわかった必要な知識
・C言語。gcc拡張部分とか。
・GNU開発ツール。libcとか。
・CPUの機能(x86)。CPUの細かい機能。01を計算してるだけじゃないよ。
『64ビットがわかる』『初めて読む〜』
・オブジェクト指向、template method とかかんたんなやつ
”writing a simple file system”（サイト）
・手を動かしてみる。カーネルモジュール開発。
まとめ
・読むコツをつかむ
・カーネルソース読むと負荷（分散）に強くなる
・OSの動作原理を知ることができる
その他
・知りたい動機が大切。
・次の興味は？→自然言語処理。
DSASのこれから（安井さん＠KLab）
・DSASの紹介
動的にサイトごとのサーバ台数の割当を変更できる
・工夫
- 全サーバの構成は同じ。
- tomcat。
- ファイルの更新は専用ツールで一括転送。rsyncはNW/IO負荷高。
そのうち公開予定。
・ダイナミック→自動的、自立的
自動で故障対応とか増設とかやってくれる→わけない、悔しい。
↓
なんとかしたい！
・自動で追加するには？I
サイトごとのトラフィック推移を記録しないといけない
追加時にtomcat再起動しないといけない
→PVSモジュールを作る
・でもたくさんの懸念
→やるべきことをすこしずつやっていく
→ そのためにカーネル読んだり、モジュール書いてみたり、
・DRBDとの出会い
・インフラ楽しー
はてなのインフラ、いまむかし（田中さん＠はてな）
・1000万UU/月、6000万PV/日
サーバ350台、仮想化して500台。14ラック。240Mbps。
・インフラ初期（2001〜2002年）
P3自作PC、apache+PostgreSQL、PerlCGI、オールインワン。
→ CGI重い→mod_perl入れる→mod_perl負荷高い→
→リバースプロキシ入れる→以下、略
こういうのの繰り返し
・インフラ拡大（2002年）
サーバケース自作、レプリケーション、mod_proxyでLB
・はてなダイアリー（2003年）
・東京移転（2004年2月）
mod_proxy_balancer
・サービスラッシュ（2005年）
はてなブックマーク、RSSとかマップとか。問題多し。
- SPOF多数、体力勝負
- 回線飽和
- 電力不足
・インフラ2.0（2006~2007年）
KLabとの出会い、LVSとの出会い
→SPOFの解消
→運用の効率化
・さくらiDCへ（2007年）
回線・電力の問題解決
インフラチーム発足
期間ネットワーク見直し→LVS+keepalived
OS更新、64Bit
・2007年半ば
- LVS三層構造
- 商用サーバ一部利用
- 64ビット→メモリ4GBの壁を突破
- キャッシュ→I/O負荷の低減
- MySQLマルチマスタ化
お互いにslave/slave、active／backup、keepalived
・2008/8現在
- インフラは足腰
- 仮想化(Xen)500台中150台
- 仮想→別ハードに移動可能、xenの移動機能は使わずddで。
- xenディスクレスサーバ、中央ファイルサーバ→オンメモリ上に展開して。
ファイルサーバに依存しない。
- Hadoopで分散ファイルシステム、並列クラスタ→ログ解析
- サーバ管理ツールは独自。他ツールと連携。Nagios、capistrano、IRC
- セットアップの簡略化、PXE、Puppet、独自RPMレポジトリ、Capistrano、
- selenium検討中
・課題
- 微妙に壊れるパターンはやっかい
- 日々のトレードオフを踏まえた上での適切な方策
・より強固なインフラを目指して
- インフラはクリエイティブ！
結論としては「インフラはクリエイティブで楽しい！」だな。
感想は別のエントリで。
Category: 24svr-TechMTG, Server | コメント＆トラックバック（0）
[24svr-TechMTG]Ustreamはじまった
2008/08/08 18:59 posted by kunkichi
大阪なのでUstreamで。
くっそ、仕事が遅くなったのでDSASひろせさんのセッション見逃した、、、orz
スケジュールはこんな感じ。
18:30～18:35 オープニング
18:35～18:40 （5分休憩）
18:40～19:00 この本を書いたわけ ……ひろせまさあき（KLab㈱）
19:00～19:05 （5分休憩）
今この辺。
19:05～19:35 Linuxカーネルの読み方 ……伊藤直也（㈱はてな）
19:35～19:40 （5分休憩）
19:40～20:10 DSASのこれから ……安井真伸（KLab㈱）
20:10～20:15 （5分休憩）
20:15～20:45 はてなのインフラ，いまむかし ……田中慎司（㈱はてな）
20:45～20:55 Q&A
20:55～21:00 クロージング
Category: 24svr-TechMTG, Server | コメント＆トラックバック（0）
今回のDNSキャッシュポイズニングの脆弱性対策について
2008/08/04 00:31 posted by kunkichi
騒ぎもちょっと落ち着いたようなので（というかある程度詳細がわかって、世の中の対応もそれなりに進んだみたいなので、という意味）、もし対応を迷っている管理者の方（今でもいるんだろうか、、、）向けに、既に対応した管理者としての感想。
- キャッシュサーバ使ってなければ全く気にする必要なし。
- 今回の場合「バージョンアップしない」っていう選択肢はないと思っていいと思う。例えば大手ISPの○○は対応してないからうちもやらない、っていうのはちょっと無理があるかと。大手は金も物も持ってるからね、実は見えない部分で台数かけて分散してたりして、台数ある分だけやられる確率低くなるていう意味ですぐに対応してない場合もありえる。
- bindの場合、対策版（P1）にバージョンアップするとLoad Average上がります。とある環境ではざっくり1.5倍程度。なんとなくレスポンスもちょっと遅くなった気が。
- 上記P1のパフォーマンス改善版（P2）が出たみたいなので、今からだったらこっちにすべし。まだ試せてないけどP1に比べてどの程度負荷が下がるんだろう？
- ってことで、もし日頃の負荷がある程度高い状態だったら、バージョンアップすると限界迎えるケースもありえる。その場合、スケールアウトはすぐにはできないだろうから、せめてスケールアップできるように準備しておいた方がいいと思う。
今回思ったんだけど、DNS のキャッシュサーバの性能測定って難しい。queryperf 使うにしても、再起問い合わせの部分をどうシミュレートすればよいのか。インターネットに実際に流す訳にはいかないし、やっぱり自前ネットワークでrootサーバから構築するとかしないといけないのだろうか。
Category: UNIX, Server | コメント＆トラックバック（3）
今、自宅サーバが熱い！
2008/07/28 23:10 posted by kunkichi
いや、そうじゃなくて、リアルに熱い（笑）
最近大阪も暑くなってきたので（昨日なんて38度、、、）、ディスクの温度を調べてみようと、hddtempをインストールしてみた。
CentOS5だと標準でパッケージがある。
# yum install hddtemp -y
# hddtemp /dev/sda
/dev/sda: WDC WD5000AACS-00ZUB0: 38°C
# hddtemp /dev/sdb
/dev/sdb: WDC WD5000AACS-00ZUB0: 35°C
サーバをおいている部屋はクーラーとかは入れてないのだけど、日が直接差さないこともあって閉め切ってなければそれなりに涼しかったりするんだけど、それでも結構あがってきた感じ。
Googleによると、ハードディスクは温度や使用頻度に関係なく故障する（GIGAZINE）らしいので、まあなんともではあるのだけど、そろそろ対策を検討しないと。
Category: Server | コメント＆トラックバック（0）
Page 3 of 8«12345»...Last »
![日経 Linux (リナックス) 2008年 10月号 [雑誌]](http://ecx.images-amazon.com/images/I/51wQqWEjMhL._SL160_.jpg)
2012/02/05/ 10:17
2012/01/04/ 07:43
2011/10/06/ 10:13
2011/10/06/ 07:03
2011/10/06/ 06:46