naoyaのはてなダイアリー - Linuxのページキャッシュ
世間では PHP が、Perl が、と盛り上がっているようですが空気を読まずまたカーネルの話です。今回はページキャッシュについて。 /dev/shm に参照系ＤＢを持っていくと I/O 負荷が激減した件（当たり前だけど） - drk7jp で、ディスク上にあったファイルを /dev/shm (tmpfs) に移したら I/O 待ちがなくなって負荷がさがった、ということなんですがおそらくこれは tmpfs に置く必要はないかなと思います。Linux (に限らず他の OS もそうですが) にはディスクの内容を一度読んだらそれはカーネルがキャッシュして、二度目以降はメモリから読む機構 = ページキャッシュがあります。tmpfs にデータを載せることができた、ということは物理メモリの容量に収まるだけのデータサイズかと思うので、放っておけば該当のファイルの内容すべてがメモリ上にキャッシュされて io
naoyaのはてなダイアリー - さくらインターネット移行記#3 はてなブックマーク移転
さて、移行記も #3 となりました。今回は先日作業を終えたはてなブックマークの移転について。 旧サーバールームからさくらインターネットのiDCへのサーバー移転作業にもだいぶ慣れて来たこのごろ。これまでは比較的はてな内の他サービスとの連携が疎になっていたり、負荷がそこまで高くないものであったりと移行しやすいものから持っていってましたが、そろそろ難しいところ手を付ける時期に来まして、はてなブックマークの移転です。 以前に書いた はてなブックマークの裏側その後 - naoyaのはてなダイアリー では 2006年10月時点で ユーザー: 60,000 人 ブックマーク数: 787万件 サーバー: 30台 となっていました。移転したこのごろはというと ユーザー: 80,000 人 ブックマーク数: 1,182万件 サーバー: 移転前約45台 (移転後 約25台) という具合になっていました。順調に伸
はてなブックマークの裏側その後 - naoyaのはてなダイアリー
まるごとPerl! Vol.1 で執筆させていただいたはてなブックマークのシステムに関する記事が ThinkIT で読めるようになりました。記事全体を何回かにわけて掲載していただいています。まるごとPerlの記事なのですが、実は Perl のことはあまり触れていなくてはてなのサーバー運用概論みたいは話が主なところです。 http://www.thinkit.co.jp/free/article/0610/1/1/ http://www.thinkit.co.jp/free/article/0610/1/2/ せっかくなので現状報告も含めて少し補足をしてみようかなと思います。 現在の数字 記事の中での数字は6月のもので ユーザー：45,000人 ブックマーク数：535万件 ページビュー：5,000万/月 サーバー：17台 となってますが、現在 10 月の方はというと ユーザー: 60,000
ETech 2006 レポート
ETech も今日が最終日です。午前中のセッションを終えて、聞きたいものはだいたい全部終わったし、ここらで全体を通してのレポートを書いてみます。一つ一つのセッションについて全部レポートは難しいので、個人的に面白いと思ったトピックやセッションだけ振り返ってみたいと思います。 Attention Economy 今回の ETech のテーマは Attention Economy。ETech は 5 回目ですが、毎年このようにテーマがあるらしく、そういえば去年の ETech は "Remix" がテーマでした。この辺がきっかけて Web 2.0 がどうこうという話が盛り上がりはじめたんだっけ。 Attention Economy というのは 今回のテーマは"Attention Economy"ということで、Attentionをキーワードに色々な話が繰り広げられています。 パソコンはどんどん安くな
naoyaのはてなダイアリー - 疎結合のための Web API
RSS みたいな公開フォーマット(?)はパースしやすいし、手軽に使えるってのはいい。ただ、せっかく内部の情報を使えるのに、あえて公開 API を使う利点ってのはどこにあるのか、と。 以前の失敗を考えると、DB を使えるなら DB から直接データを取り出して、プログラム的に使いやすい形に整形する方が手間がないと思う。 on HTTP で流す情報も大本は DB な訳だし、DB ボトルネックもそれほど関係ないんじゃないのかな？ 違うよー、DB 直接叩かないのはサービス間の密結合を避けるためなんです。疎結合。 二つ以上のアプリケーションからある一つのデータベースを直接叩くっていうことは、各アプリケーションがデータベースの場所を知ってる必要があります。もちろんデータベース周りの実装は抽象化したライブラリを使って共有するよ。でも、その二つのアプリケーションが同じサーバーに搭載されている保証はどこにもな
naoyaのはてなダイアリー - 似たようなことをやってるけど実は違うことをやってる人たち
梅田さんより10歳前後若いブロガーたちが急激な変化を予想する一方、44歳の梅田さんは一貫して、「変化は起きるが、みんなが思っているほど急激ではないだろう」という立場で語った。 僕もこのイベントにはちょこっと顔を出してみました。 なんかパネラーの人たちがはてなブックマークの話をたくさんしてて、開発者がここにいるって言うのに開発者そっちのけで色々話してて、まあ最後に開発者から一言とかで呼ばれるだろうと思ったらそんなこともなくって。おまえらいい加減にしろと憤慨しました。いや、冗談です。 個人的には第二部の SNS の話で id:umedamochio にいじられる山岸さんが面白くてしょうがなかったんですが、ここは敢えて第一部の話に触れてみよう。 この ITmedia の記事の冒頭の一文にあるように、「ネットがマスメディアを飲み込むんだ」という見方に対して梅田さんが「いやいや、そんなに簡単にはいか
naoyaのはてなダイアリー - サーバーを増やせばいいんじゃない、サーバーを増やすだけで解決できるように努力するのだ
ライブドアの技術の話について書いた、その記事のコメント欄。最初は感情的な批判などがあって話題とは別の方向で炎上し気味だったんでうーんと思ってたんですが、後半になってきて少し面白い議論が出てきました。 こんな反応があった。 アクセス数が増加している段階で、ApachやAppServerのスレッド数をいじろうが、ヒープサイズを増やそうが、DBのパラメータをいじろうが、はてまたアプリを書き直そうが、性能要求にミートするには相当のワークが発生しますし、どう最適化、チューニングしても追いつきません。そのようなチューニングにお金をかけるならサーバーを追加したほうが安く上がるのではないかと思うのですが、如何でしょう? それに対する僕の返信は、 確かに何千万もするファイルサーバーとか、ロードバランサーとかで問題が解決できる機会っていうのは存在すると思います。なので ”負荷が高ければ、結局サーバーを単純に増
Hacking Apache HTTP Server at Yahoo! - naoyaのはてなダイアリー
遅ればせながら Hacking Apache HTTP Server at Yahoo! を一通り読みました。これは Yahoo! のエンジニアである Michael J. Radwin 氏が昨年末の ApacheCon で喋ったときのスライド。 http://public.yahoo.com/~radwin/talks/yapache-apachecon2005.htm Yahoo! が Apache に独自に手を入れた "yapache" なる Apache を使ってるというのはときどき聞いてたんですが、具体的にどういう変更が入ってるかとかは謎のままでした。このスライドにはその辺りの話が惜しげもなく書いてあって、とても面白い。 シグナルを使わないでログをローテーションするとか、ログフォーマットを工夫してるとか、出力の HTML にホスト名などを記載しておいてサポートに役立てるとか、いろ
naoyaのはてなダイアリー - 大規模サービスを展開する企業が陥るジレンマ
このところ大きなサービスを持ってる大きな企業が運用するウェブサイトについて考えることが多かったので、ちょっと書き殴ってみるとします。 一見すると大企業ってのは人もたくさんいるし資金もたくさんあるし、小さな企業と競争になっても、簡単にそれを踏みつぶしてしまえるような印象を受けます。いやいや、そんなに簡単じゃないんだよっていうのがイノベーションのジレンマであり、大企業病のジレンマであり。で、ウェブの企業にもう一つ当てはまるジレンマがあるなあと最近思います。 はてなダイアリーのキーワードページに、Yahoo! ニュースのトピックページからリンクされることがあります。そのニュースが Yahoo! Japan のトップページに載ってたりするものだと、キーワードページへの瞬間最大トラフィックが恐ろしいことになります。最近は対策を練ったので問題ないのですが、一時期は Yahoo! トップに載ってるニュー
Amazon の強さの秘密について考える - naoyaのはてなダイアリー
昨日 Amazon がなぜ強いかという話にちょっと触れたところ結構ブックマークされたようで、その反応がいろいろあって面白かった。言葉足らずだった部分も含めて、僕が Amazon がなぜ強いかについて考えるロジックをここにまとめてみたいと思います。 まず、実感を持ってもらうために以下のリンク(すべてサーチの検索結果です。) を実際にみてみて、Amazon.com なり Amazon.co.jp なりがどの辺りの位置につけているかを確認してみてください。 Google で「ワンダと巨像」 Google で「Agile Web Development with Rails」 Yahoo! Japanで「アドベントチルドレン」 Yahoo! Japanで「いま、会いにゆきます」 おそらく、楽天やほかのどのショッピングサイトよりも先に Amazon のリンクを目にすることかと思います。ここで羅列した
Googleの組織マネジメントを前例に。 - naoyaのはてなダイアリー
「日本版Googleを目指す」と回答したのは近藤氏。今では世界企業となったGoogleだが、はてなの目指すGoogleとは何だろう。 id:jkondo が出てるこの記事。「日本版Google」 なんていうキャッチーなフレーズばかりが先行してますが、本来僕ら言いたかったのはそういうことじゃなくて。 組織のマネジメントという点でみたときに、Google というのは非常に優秀な企業で、いまや 3,000 人もの社員を抱えている大企業にもかかわらず、大企業病のジレンマには陥っていないと言われます。僕らが着目している点はその点です。 はてなはよく小さな企業だからいまのやり方ができるんだろう、とか、大企業病からは逃れられないという風に言われます。そのカウンターとして実際に同業者で 3,000 人になっても現場プログラマが満足しながら働ける企業というのが世の中に前例としてある、だったら僕らにできないは
naoyaのはてなダイアリー - テクノロジーを隠蔽して誰もが使えるようにするのがインタフェースの役目だ
今年度のウェブ・デザインの間違いトップ10は、基本に忠実なウェブ・デザインに立ち返る必要性を明らかにするものとなった。メーリングリストやウェブサイト、カンファレンスに至るまで、インターネット業界では、新しく、魅力的な“Web2.0”機能に関する話題が尽きない。しかし、ユーザはテクノロジーなど気にしておらず、新しい機能など望んでもいない。 この文書、おおむね同意なんだけどどうしてもこのフレーズだけには納得がいかない。そこでブックマークに「この断定が好きじゃない」ということを書いたのだけど、これだけだとコメントの意思が正しく意図が伝わらないかもしれないのでここに記しておく。 見出しにあるとおり、"テクノロジーを隠蔽して誰もが使えるようにするのがインタフェースの役目"と常々思っている。Google の検索窓ひとつの、究極にシンプルな UI の奥にはご存知の検索テクノロジーが隠れている。iPod
Reverse Proxy と mod_perl の MaxClients - naoyaのはてなダイアリー
NDOメソッドっぽく質問されてたので答えてみる。 あと聞きたいのは(←ずうずうしい…)、アプリケーションサーバとかリバースプロキシサーバとかのapacheなどのMaxClientsをどのくらいにしているのかですね。カリカリにチューニングしているのか、ハイパフォーマンスMySQLでJeremyさんがYahoo! comのことを書いてた様に1台当り MaxClients 30 ぐらいしか立ち上げてないのか。 リバースプロキシはメモリの許すギリギリのラインまで MaxClients を上げて設定してます。スタティックな一定のコンテンツを返すあるいは Rewrite するのが仕事のほとんどなので、CPU パワーや I/O もほとんどかからず、最近のスペックのマシンであればリバースプロキシの性能はメモリ量に完全に依存してる感じです。 ので、MaxClients の数がなるべく稼げるように子プロセスの
naoyaのはてなダイアリー - microformats って一体何だ?
にわかに盛り上がりを見せている microformats。Technorati が最近注力しているので有名で、Web 2.0 のディスカッションの中でもときおり出てくる重要な要素らしい。アルファギークな人たちも、近頃は microformats について触れることが多くなってきました。 が、僕は頭が悪いんだろうか、いまいち何のことだかよくわからなくって困ってたので、ここで少し腰を据えて、色々見て回り勉強中です。まだ細かいところがもやもやしてはいるものの、ようやくその実体が掴めて来た感じです。 「microformats とは何か?」と言われると、その答えはズバリ About microformats というエントリーに書かれているのですが、これを理解するよりまず具体例から入った方が分かりやすい。現在 microformats と呼ばれているもののうち、すでに実用段階に入っているものがありま
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
