タグ

ブックマーク / labs.cybozu.co.jp (21)

  • TAKESAKO @ Yet another Cybozu Labs: [Debug Hacks] #66.手元のx86マシンが64bitモード対応かどうかを調べる

    日オライリージャパン様より「Debug Hacks――デバッグを極めるテクニック&ツール」の献をいただきました。著者の皆様、出版社の皆様ありがとうございます。 とりあえず、ざっくりと気になる章だけをかいつまんで読んでみたのですが、最後の章「#66.手元のx86マシンが64bitモード対応かどうかを調べる」では、/proc/cpuinfo で lm の文字列を探す方法と、以下のような CPUID 命令を発行して今自分が使っているマシンのCPUが64bitに対応しているかどうかを調べるハックが紹介されていました。 #include <stdio.h> void cpuid(int op, unsigned int *eax, unsigned int *ebx, unsigned int *ecx, unsigned int *edx) { __asm__("cpuid" : "=a" (

    yumatsumo
    yumatsumo 2009/04/21
    やってみよ
  • Kazuho@Cybozu Labs: ウェブサービスにおけるダメージコントロール (MySQL のスロークエリを自動的に kill する方法)

    « ウェブサービスにおける SSD 導入にむけて〜検索サービスの可能性 | メイン | ウェブアプリケーションのインストーラジェネレータ » 2008年11月04日 ウェブサービスにおけるダメージコントロール (MySQL のスロークエリを自動的に kill する方法) 適切な設計によって、信頼性の高いソフトウェアやサービスを構築することが重要なのは、言うまでもないことです。一方で、なんらかの原因で問題が発生した際に、障害を局所化し、損害を小さくい止める「ダメージコントロール」という概念もあります。ウェブサービスの場合も、特に検索や集計といった、計算量がクエリの種類によって大幅に異なるようなケースでは、次善の策として後者の手法が有効に働く場合もあるかと思います。 ともかくそういうわけで、MySQL のスロークエリを強制終了するようなタスクを書きやすくする Perl モジュール MySQL

  • Kazuho@Cybozu Labs: MySQL の order by 〜 limit を高速化する方法

    « なぜサイボウズ・ラボで働くのか | メイン | Text::MicroTemplate - テンプレートエンジンのセキュリティと利便性 » 2008年12月12日 MySQL の order by 〜 limit を高速化する方法 filesort が回避できない場合に、MySQL の order by 〜 limit を高速化する方法というのを書いてみました。半分は効果測定が目的の実装のため、UDF になっていたりと、利用にはある程度のスキルが必要だとは思いますが、興味のある方はどうぞ。

  • Kazuho@Cybozu Labs: 最適化された最適化手法について

    « Pathtraq の API を公開しました | メイン | 実行時間を抑制するモジュール Sub::Throttle を書いた » 2008年07月25日 最適化された最適化手法について 昨日ソフリットを会場に (壇上さん++) 開催された CodeRepos Conference #1 に参加してきました。お題は「自重しないで coderepos に貴様がいれているプロダクトについて語れ!」ということだったので、そのあたりを例に挙げながら、自分は最適化手法について (空気を読まずに) 話しました。 どちらかと言うとサーバの最適化設計を中心にした話です。いろいろ荒削りですが、そうだね、とか、そこは違うよ、とか指摘いただければ幸いです。発表の動画がニコニコ動画にアップロードされているので (coji さんありがとうございます) よろしければあわせてご覧ください。

  • Kazuho@Cybozu Labs: Q4M - MySQL 上で動作するメッセージキュー

    « ウェブアプリケーションにおけるHDDの正しい使い方 | メイン | Pathtraq リニューアルのおしらせ (リアルタイム検索機能の追加ほか) » 2008年01月15日 Q4M - MySQL 上で動作するメッセージキュー 数年来ずっと「RDBMSに統合されたメッセージキューがほしい」と言ってきたわけですが、昨年末にストレージエンジンをプラグインとして開発できる MySQL 5.1 が RC になっていることに気づき、自分で作ってみました。 Q4M (Queue for MySQL) は MySQL 5.1 のプラガブル・ストレージ・エンジンとして動作するメッセージキューであり、堅牢・高速・柔軟であるよう設計されています。昨年12月遅くに開発が開始され、まだ非常に原始的ですが、かなり高速に動作します。 q4m.31tools.com 自分の英語を日語訳するというのも変なものですが

  • Kazuho@Cybozu Labs: MySQL のクエリ最適化における、もうひとつの検証方法

    « メッセージキュー事始め with Q4M | メイン | フレンド・タイムライン処理の原理と実践 » 2008年06月09日 MySQL のクエリ最適化における、もうひとつの検証方法 EXPLAIN を使用して MySQLSQL を最適化するというのは、良く知られた手法だと思います。しかし、EXPLAIN の返す結果が、かならずしもアテになるわけではありません。たとえば、以下のような EXPLAIN を見て、このクエリが最適かどうか、判断ができるでしょうか。私には分かりません。 mysql> EXPLAIN SELECT message.id,message.user_id,message.body FROM message INNER JOIN mailbox ON message.id=mailbox.message_id WHERE mailbox.user_id=2 OR

  • log4ZIGOROu : Module-Starterのカスタマイズ

    date 2007-04-02 14:05:29 category CPAN permlink here comment 0 trackback 0 いずれ奇麗にまとめてやろうと思ってたんですが、いい機会なのでこの辺りでmodule-starterの詳細とカスタマイズについて書いてみます。 ところで以前Module::Starterのplugin機構が面白い件についてと言うエントリを書いた事があるのですが、こちらに関して頭に入っているとより理解しやすいかもしれません。 名前とメールアドレスの設定 毎回author, emailを指定するのも面倒なので下記のように設定してしまいましょう。 ~/.module-starter/configに記載します。 author: Toru Yamaguchi email: foo@example.com これで次回からこのパラメータを指定する必要は無くな

  • Kazuho@Cybozu Labs: 高速なCometサーバを書いてみた件

    « Pathtraq 最新ランキング ガジェットを公開しました | メイン | Q4M (Queue for MySQL) 0.3 リリース » 2008年03月10日 高速なCometサーバを書いてみた件 もう昨年の2月になりますが、Comet について調査を行いました。その際の成果をまとめたスライドは既に公開していた (Comet の正しい使い方) のですが、同時に実際に作ってみた実装についても、オープンソース化することとなりました。コードは CodeRepos に置いておきますので、どうぞご覧ください。 (Revision 7754: /lang/perl/fastr) 使い方は example ディレクトリ以下を見ていただくとして、ベンチマークの結果とチューニング手法について、記録と記憶に残っている範囲からまとめておきたいと思います。 パフォーマンスについて まず、パフォーマンスに

  • Kazuho@Cybozu Labs: Tritonn (MySQL+Senna) の join を高速化

    « setlock を使って cron をぶんまわす方法 | メイン | Range Coder の終了処理 » 2008年02月05日 Tritonn (MySQL+Senna) の join を高速化 自分の利用形態において、Tritonn の処理を最適化するパッチを書きました。具体的には、2種類の最適化を行いました。ひょっとするとバグがあるかもしれませんが、興味がある方は、以下のパッチ (tritonn-1.0.9用) とあわせてごらんください。 1. 全文索引内にプライマリキーを格納 SQL クエリを最適化する際、アクセスしたい全カラムを格納したインデックスを作成することで行データへのアクセスを抑止して速度を稼ぐ、というのは定石のひとつです。しかし、MySQL の全文索引 (フルテキストインデックス) では、他のカラムと組み合わせた複合キーを作成することができません。このことが、T

  • 秋元@サイボウズラボ・プログラマー・ブログ: Google Social Graph API登場 - 公開情報から人のつながりを探せるように

    Google Social Graph APIに戻って「Googleのウェブ検索」を説明するなら、ウェブにあるページとページのリンク関係を大量に集めて、単語を入れたら関連するページを返す、ということになるだろう。 今日新しく発表されたGoogle Social Graph APIは、リンクの中でも特に「サイトと人、人と人の関係」が書かれたリンクを収集して検索できるようにしたAPIだ。 APIを使ったサンプルがあるのでこれを使ってみる。My Connectionsというサンプルでは、ブログや自分のプロフィールが載ったページのURLを入れる(複数あれば改行で区切る)と、過去にブログやSNSなどで自分が登録した情報から、関係のあるウェブサイトのURLや、知人のページを取得して表示してくれる。 人間関係やサイト間の関係はどこから取っているのか、というと、これはXFNやFOAFといったmicr

    秋元@サイボウズラボ・プログラマー・ブログ: Google Social Graph API登場 - 公開情報から人のつながりを探せるように
  • Kazuho@Cybozu Labs: データベースをコピーするモジュール DBIx::Replicate

    « Pathtraq リニューアルのおしらせ (リアルタイム検索機能の追加ほか) | メイン | setlock を使って cron をぶんまわす方法 » 2008年01月29日 データベースをコピーするモジュール DBIx::Replicate データベースをオンデマンドでコピーするモジュール DBIx::Replicate を書いて、CodeRepos にアップロードしました。こんな感じで使います。 use DBIx::Replicate qw/dbix_replicate/; # 20才以下の人だけを young_table にコピー (1000行毎, 最大負荷 0.5) dbix_replicate({ src_conn => $dbh, src_table => 'all_people', dst_conn => $dbh, dest_table => 'young_people

  • 秋元@サイボウズラボ・プログラマー・ブログ: Google AdSenseで大儲けしている個人のリスト

    アドセンスで稼いでる個人のリストを作った人がいるので紹介。ネット上でソースが明らかになっている情報から集めて高い順に並べたそうだ。 いったいアドセンスで「すごく稼ぐ」というのはいくらぐらいなのか。 サイト 月の収入(円) […]

    秋元@サイボウズラボ・プログラマー・ブログ: Google AdSenseで大儲けしている個人のリスト
  • キーワード抽出モジュール Lingua::JA::Summarize を使うコツ (nakatani @ cybozu labs)

    いわゆる「Web2.0」っぽい要素である「タグ」。 一般にはタグ付けは手動で行うわけですが、自然言語テキストへのタグ付け(キーワード抽出)を自動で行うことができれば、あれこれと可能性が広がって楽しそう……しかし、それは実現が難しかったり高コストだったりして、簡単に手を出せる解はあまりありません。 ラボの奥さんの作成したキーワード抽出モジュール Lingua::JA::Summarize は次の特徴を持っています。 動作要件の敷居が低い 辞書のメンテナンスをしなくても、未知語や熟語もある程度抽出してくれる 希望の結果に近づけるためのチューニングが可能 モジュールを使って、サイボウズ・ラボ内での情報交換を行っている社内掲示板をスレッド単位で解析しているのですが、辞書を一切チューニングしていない状態でも「しょこたん☆ぶろぐ」や「かぶり隊隊員ニャンコ達」などの特徴的なキーワードが抽出されます(

  • TAKESAKO @ Yet another Cybozu Labs: ニコニコ動画勉強会に行ってきました

    日ドワンゴさんの会議室にてこっそり開催されたニコニコ動画勉強会に参加してきました。 日の動画コメントサービス「ニコニコ動画」の裏側をドワンゴの開発者の方から 直接お話しを聞いて、参加者も一緒に意見交換ができる非常に面白い勉強会でした。 ドワンゴさんとしては会社で行なう技術者向けの勉強会初めての試みということもあり、 まずは開発者の知り合いベースで声をかけあって少人数で開催することにしたそうです。 六木のクラブの人や、バイナリカンファレンスでご一緒した人とこんなところで お会いできるとは思っていませんで、さまに想定の範囲外でした。 その甲斐あって密度の濃い話ができたと思います。 以下、自分用のメモを公開できる範囲で書きます。間違っていたらすみません。(ご指摘いただければすぐに訂正します) ■ニコニコ動画の苦労話 (Sさん) ニコニコ動画の歴史 2006年10月 一人でプロトタイプを開発

  • Kazuho@Cybozu Labs: 負荷に応じてキャッシュを自動調節する Perl モジュール

    « Re: PoCo::Client::HTTP が勝手に文字コードを変えてしまう件 | メイン | Cache::Adaptive の使い方 » 2007年05月09日 負荷に応じてキャッシュを自動調節する Perl モジュール Cache::Adaptive の使い方に続く 最近かりかりとサーバサイドの実装をしています。修行の成果、だいぶ複雑な SQL も書けるようになってきました。DBMS の気持ちを考えながら SQL 最適化するのは楽しいですね。しかし、いくら SQL を工夫したところでパフォーマンスの限界はあるわけです。 となると、採りうる選択肢はスケールアウト・スケールアップ・キャッシングの3つになります (もちろん組み合わせも可)。ただ、需要予測の最大値に基づいて機材を確保するのもあまり効率的とは言えませんし、リリース直後に徹夜でパフォーマンスのチューニングをするのもイヤです

  • Kazuho@Cybozu Labs: Cache::Adaptive の使い方

    « 負荷に応じてキャッシュを自動調節する Perl モジュール | メイン | FizzBuzz - Perl 使って50バイト » 2007年05月10日 Cache::Adaptive の使い方 昨日のエントリが好評のようだったので、いろいろ問題を修正したバージョンを CPAN にアップロードしました (Cache-Adaptive-0.02 - search.cpan.org) 。ついでに、開発中のウェブサービスに仕込んで、トップページでベンチマークを取ってみました。こんな感じです。 キャッシュが効いていない状態で、0.1 秒強かかっているページについて、同時アクセスを増やしていっても問題ないのがおわかりいただけると思います。同時接続数が増えるにつれキャッシュヒットする率が上がり、平均レスポンスタイムが小さくなるのはご愛嬌。ちなみに、使った設定は以下のようなものでした。ログ出力のコー

  • 秋元@サイボウズラボ・プログラマー・ブログ: reCAPTCHA - キャプチャを利用した人力高性能OCR

    reCAPTCHA という新サービスはすごい。その構想力には感動させられた。 念のためにCAPTCHA(キャプチャ)について説明しておくと、スパムプログラム(bot)と人間のユーザを見分けるための簡単な(しかし機械にとっ […] reCAPTCHA という新サービスはすごい。その構想力には感動させられた。 念のためにCAPTCHA(キャプチャ)について説明しておくと、スパムプログラム(bot)と人間のユーザを見分けるための簡単な(しかし機械にとっては難しい)クイズのことだ。ある程度ウェブを使っている人なら、ネットサービスの登録時やコメントの書き込み時などに、読みにくく加工されたアルファベットを読まされたりした経験があるだろうと思う。 それらのサイトでは、あなたが人間にしかできないクイズを解いたのを見て、ユーザ登録やコメントの投稿を受け付けたりする仕組みになっているわけだ。文字を読む以外のC

  • Kazuho@Cybozu Labs: MySQL の高速化プチBK

    « システムコールの最適化 | メイン | キャッシュシステムの Thundering Herd 問題 » 2007年09月20日 MySQL の高速化プチBK 鴨志田さんに教えていただいたのですが、MySQL のクエリは数値をクォートしない方が高速になるらしいです。たとえば以下の例では、160万件の整数から4の倍数を数えていますが、数値をクォートしないほうが約50%も高速になっています。 mysql> show create table numbers; +---------+----------------------------------------------------------------------------------------+ | Table | Create Table | +---------+--------------------------------

  • Kazuho@Cybozu Labs: システムコールの最適化

    « Swifty 0.03 を公開しました | メイン | MySQL の高速化プチBK » 2007年09月19日 システムコールの最適化 今朝、会社で「最速のファイルコピー」についての話題が出ていました。そこで、ちょっと気になって、read(2) の呼出のオーバーヘッドがどの程度あるのか、ベンチマークをとってみました。 グラフは、それぞれの環境で、10MBのファイルを1,024回読み込むのにかかった時間を示しています。ファイルの内容は当然メインメモリにキャッシュされているので、実際は、カーネル内のバッファキャッシュからユーザープロセスのバッファへのメモリコピーの速度を測定していることになります。このグラフから、以下のような傾向を読み取ることができます。 (言うまでもないことですが)システムコールのオーバーヘッドは大きい Mac OS X のシステムコールのオーバーヘッドは Linux

  • Kazuho@Cybozu Labs: DBI::Printf - A Yet Another Prepared Statement

    « ウェブサービスのためのMutex - KeyedMutex | メイン | Perl で並列処理 (using マルチプロセス) » 2007年09月28日 DBI::Printf - A Yet Another Prepared Statement JavaC++ のような関数のオーバーロードができる言語では、プリペアードステートメントのプレースホルダが型をもつ必要はありません。しかし、Perl のように数値型と文字列型の区別がない言語で最善を期そうとすると、変数をバインドするタイミングで型を意識してコードを書かなければならず面倒です。 (参考: MySQL の高速化プチBK) だったら、printf のように、プリペアードステートメントのプレースホルダで型を指定できればいいのに、と、もともとは Twitter でつぶやいたネタなのですが、SQLステートメントをキーとしてキャッ