Linux I/O のお話 write 編 - naoyaのはてなダイアリー
write はページに dirty フラグを立てるだけなので決してユーザープロセスを待たせない って、本当にそうなんでしょうか？（否定しているわけではなく、純粋な疑問です。） と質問をもらったので、最近追ったことをここでまとめます。かなり長文です、すいません。また、まだまだ不勉強なので間違っているところもあるかもしれません。ツッコミ大歓迎です。 まず、オライリーのカーネル本の 15章 ページキャッシュ 15.3 汚れたページのディスクへの書き込み から引用。 ご存知のように、カーネルは、ブロック型デバイスのデータを含むページをページキャッシュに蓄えています。プロセスが何らかのデータを更新した場合は、必ず対応するページに汚れている印をつけます。すなわち、PG_dirty フラグを設定します。 UNIX システムでは、汚れたページのブロック型デバイスへの書き込みを遅延することができます。この方
*NIX初心者だったあの頃 - naoyaのはてなダイアリー
ログインした。twm。ウィンドウを閉じようとしてもアイコンになる。途方に暮れる。 Emacs というのを使うと日本語が打てるらしいと聞いた。日本語入力への切り替え方法がわからない。立ち上げた Emacs を終了できない。 Cannna というのを使えば日本語が打てるらしい。apt-get install。他のパッケージのインストールが始まり混乱に陥る。 Emacs 使ってるって言ってたのに mule って書いてるよ? cat /var/log/messages | moer → command not found: moer apt-get install 中に Yes or No の質問をたくさんされる。よくわからないけど全部 yes にする。何が起こったかわからない。知らない振り。 X-Window のグレーバックの壁紙。解像度が適切に設定されてないせいでにじんでいる。設定方法がわから
Perl and UNIX Network Programming (YAPC::Asia 2007) - naoyaのはてなダイアリー
YAPC::Asia で Perl UNIX ネットワークプログラミングについての発表をしてきました。UNIX ネットワークプログラミングの基礎の概論、I/O多重化の話、Perl のモダンなネットワークライブラリの話です。資料を以下に置いておきます。 http://bloghackers.net/~naoya/ppt/070404Perl_and_UNIX_Network_Programming.ppt (ppt, 122k) なお、会場では口頭で触れましたが、資料中のソースは簡単のためエラー処理を飛ばしています。また、途中で出てくる図は例えば vfs のページキャッシュをはしょってあったりとこれも簡単のため省略事項がある点にご注意ください。 それからフォントが Consolas なので Consolas が入ってない環境だと変になる、かも。
naoyaのはてなダイアリー - さくらインターネット移行記#3 はてなブックマーク移転
さて、移行記も #3 となりました。今回は先日作業を終えたはてなブックマークの移転について。 旧サーバールームからさくらインターネットのiDCへのサーバー移転作業にもだいぶ慣れて来たこのごろ。これまでは比較的はてな内の他サービスとの連携が疎になっていたり、負荷がそこまで高くないものであったりと移行しやすいものから持っていってましたが、そろそろ難しいところ手を付ける時期に来まして、はてなブックマークの移転です。 以前に書いた はてなブックマークの裏側その後 - naoyaのはてなダイアリー では 2006年10月時点で ユーザー: 60,000 人 ブックマーク数: 787万件 サーバー: 30台 となっていました。移転したこのごろはというと ユーザー: 80,000 人 ブックマーク数: 1,182万件 サーバー: 移転前約45台 (移転後 約25台) という具合になっていました。順調に伸
さくらインターネット移行記#2 VPN越しのMySQLレプリケーション
前回さくらiDCに移転し始めた、ということを書いたのですが、あれから一ヶ月ちょっとが経過しましてその後も順調に iDC への移転が進んでいます。すでにラックもいくつか借りて、サーバーも数十台がさくら iDC で稼動しています。回線がこれまでよりも高速なバックボーンに接続されつつ、帯域幅も大きくなったことから、移転したサービスによってはこれまでよりもパフォーマンスが出ているサービスもあります。うち比較的大きなデータを扱うフォトライフも移転を完了していますが、おかげさまで画像の読み出しがかなり速くなったのが体感できるぐらいスループットが向上しました。 既存サービスを移転するにあたって、どういった構成でそれを行っているかをちょっと紹介してみようと思います。 移転当初は、既存のはてなのサービスとはあまり関係していないサーバー群から手を付けました。例えば広告のシステムといった、はてなのデータベースを
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分ごとのシ
naoyaのはてなダイアリー - さくらインターネット移行記#1
先日のライブドアのテクノロジーセミナー(http://d.hatena.ne.jp/naoya/20061214/1166063145)でも少し触れたのですが、はてなのサーバーは今後さくらインターネットのiDCでホストすることになりました。 複数の iDC を検討しましたが、最終的にさくらインターネットに決めた理由は回線品質の高さと回線が低価格である点でした。 はてなのようなコミュニティ中心のサービスは、お金の面では、どうしても回線コストと収益の間にアンバランスが生じがちです。ショッピングサイトや各種メディアのようなコンテンツに比べてマネタイズが難しい、というのがその主な理由です。 例えばはてなのトラフィックの多くははてなダイアリーの日記へのアクセスで占められていますが、基本的に個人の日記にははてな側からは広告を掲載しないポリシーでいます。そのためトラフィックを多数必要とされる箇所で収益を
Wii にするか PS3 にするか - naoyaのはてなダイアリー
次世代ゲーム機。Wii と PS3 どっちにするかなー、どうしようかなあと迷ってたんですが、これにしました。
MyMio 買いました - naoyaのはてなダイアリー
今まで自宅にはプリンタやFAXなどはなかったのですが、結構プリンタがなくて地図が印刷できないとか日常的に困ることもあったし、たまたま私用で FAX やスキャナが必要になったので複合機を買いにいきました。 で、買ったのは brother さんの MyMio。ビックカメラでランキングが一位だったのと、価格が 30,000 円を切ってて手ごろったし、あと以前から複合機は brother さんとこのが良いと聞いてたので即決。最新型が別にありましたが、お値段がまだ少し高めだったので一つ前のやつにしました。 そんで昨日家に帰って置いてみたんですが、プリンタとFAXとスキャナと電話とコピー機がこの大きさに納まってるってのはとてもいいですね。置き場にこまらない。電話の子機も一個ついてくる。これで 30,000 円切るってずいぶん安いなあ...。僕ぐらいローエンドな使い方のユーザーだったらスキャナとかプリン
eijiro.pl 改 - naoyaのはてなダイアリー
市販のソフトなども色々あるようですが、英辞郎そのものの辞書データが、1980円というリーズナブルなお値段でダウンロード可能なのですね。英辞郎のホームページから入手可能。 ただ、あくまでもデータだけなので、辞書として検索するためのビューワーが必要になります。 英辞郎のデータが 1,980円で手に入るとはなんということでしょう。Goodpic さんおいしい情報ありがとう。 そういえば英辞郎と言えば宮川さんが昔 Hack した eijiro.pl なんてのがあったなあと思い出しました。(http://bulknews.net/lib/columns/02_eijiro/column.html) これは alc のウェブページをスクレイピングしてコマンドライン用に整形するスクリプトです。短いスクリプトですが、英和/和英を自動判定したり、対話型でヒストリがあったり、less や lv などのページャ
naoyaのはてなダイアリー - Perl の話をまとめた
use strict がどうのこうのという話があって、そういえば昔自分もそんなこと書いたなあと思っていろいろ自分の書いた Perl の話を見返してて、せっかくだから拙作のまとめでも作っておくかと思いました。とりあえず文章量がそれなりにあって、まとまりのあるものだけを見繕ってみます。 今見ると、当時の理解が不十分で微妙なところもあったりしますが、そのあたりはご愛嬌。 いま読んでもまだ陳腐化はしてなさそうな話 お薦めの Perl 本をいくつか紹介 : NDO::Weblog Perlおすすめの書籍や情報。今ならここにPerl救命病棟とWEB+DB PRESS総集編を入れるかな。 Perlプログラマのレベル10 - Perlプログラミング救命病棟より - naoyaのはてなダイアリー Perlプログラマのレベル10。なんか他言語にも飛び火した。 Perl の変数に関するちょっとした誤解と、動的な
ゲームのインタフェース - naoyaのはてなダイアリー
そうそう、インタフェースの話でいつも思うのがロールプレイングゲームのユーザーインタフェースなんですよね。あまり意識することはないかもしれませんが、良くできたロールプレイングは大概のものが入力のインタフェースがよくできてる。(DS のタッチインタフェースがいいとかっていう話とはまた別で。) で、ドラクエとかファイナルファンタジーみたいなゲームのインタフェースは、昔のものをシリーズで追っていくと面白くて、徐々に徐々に改善されていってるのが分かって楽しいですよね。例えばファイナルファンタジーIIでは全体魔法を使うと、魔法エフェクトが各敵ごとに逐次で発生して完了するのに待たされるんですが、III では一度にエフェクトが起こるようになって待ち時間が無くなったとか。 ファイナルファンタジーI はドラクエの後発なのでおそらくドラクエのインタフェースを若干参考にしていると思われるものの、ドラクエとは異なり
Flickr の認証API - naoyaのはてなダイアリー
認証API をどうするか、ということで数名のスタッフであれこれ話ながらやってます。 まず、はてなの認証APIを使って何ができるといいのかというところですが、はてなラボをオープンしたときにいただいた意見などを見ると、「はてなのAPIで認証付きのをセキュアに利用するための API」というより「サードパーティのアプリケーションではてなIDでユーザーを識別できるためのAPI」の方が求められているという風に思いました。 具体的には、新規にユーザーを識別する必要のあるアプリケーション、例えば掲示板などを作るとして、その掲示板のユーザーを一意に識別する方法としてはてなIDを使いたい、そのIDが本当にその人のものであるかどうかをはてなが保証する、その保証を問い合わせるための API ですね。その掲示板でログインして何かを書き込むと id:naoya、と表示されると。 この手の認証APIを提供しているサービ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
naoyaのはてなダイアリー - ライブドアのテクノロジーセミナーでしゃべってきました。
