Solr って、書き込みの Disk I/O が多くて、リアルタイム検索は不可能なのかしら - kazuhoのメモ置き場
を読んでいて、pp.266-267 に、以下のような記載があった。 ・Optimize の重要性 コマンドは Solr のインデックスを物理的に最適化するコマンドです。具体的には、Solr では commit のたびに一群 11 個のファイルを作成します。 つまり、細かく commit を繰り返す形で文書の投入や更新を繰り返すと、その分だけインデックスとして多くのファイルを使うようになり、ひいてはファイルディスクリプタが枯渇する事態に陥ります。 仮に枯渇しなくても、多くのファイルを開いて検索に利用することになるため、パフォーマンスに甚大な影響を与えてしまいます。 この事態を回避するため、目安として 5 回程度 commit を行ったら最低 1 回は optimize コマンドを発行するようにしてください。 optimize を行うことで、複数回分に分かれてしまっていたインデックスファイル群
彼氏が LIKE 検索使ってた。別れたい… (もしくは Solr 入門とか Tritonn のインクリメンタルバックアップとか) - kazuhoのメモ置き場
LIKE 検索だとデータ増えてきた時なんか恥ずかしいwww 下向いちゃうしww 男にはせめて全文検索エンジン使ってほしい・・・ 検索が遅すぎてユーザー帰っちゃったら・・・・もう最悪www せめて普通 Tritonn や Solr くらいは使って欲しい。 常識的に考えて欲しいだけなんです！ 「%」検索されて全件マッチしちゃった時の恥ずかしさとか分かる？ あのね？たとえば１年間で10万件とか文書がたまるでしょ？ それを格納して検索するわけじゃない？ みんな普通に形態素解析とかn-gramとか期待してるわけでしょ？ LIKE検索でタイムアウトしてたら大恥かくでしょうがww とまあ、検索するなら全文検索エンジン使うしかないわけですが。じゃあ何を使うべきか。 自分は、ながらく Senna をベースにした MySQL の全文検索拡張 Tritonn のユーザーで、自分で機能追加のパッチも書いたりしてい
Cosmic っていうネットワークストレージを作り始めた - kazuhoのメモ置き場
GitHub - kazuho/cosmic: fail-safe management tools for network-based software RAID, using mdadm + iSCSI 概要 (というか近場の目標) は、以下のとおり。 fail-safe な network RAID 多重マウントが発生しないプロトコルを実装 RAID だから DRBD や MySQL の async replication のような lost updates 問題がない software RAID + NBD を使用 (NBD は遅いから iSCSI 対応するかも) RDBMS レベルのレプリケーションや DRBD と異なり、高可用性のあるブロックデバイスを提供するソフトウェアレイヤとして機能 様々なストレージミドルウェアを統一的に管理可能なので、管理コストが低い バックアップとかも
死んだプロセスのスタックトレースを自動収集するデーモンを書いた (そして、その出力を開発者に送ってあげると喜ばれるよという話) - kazuhoのメモ置き場
死んだプロセス (あるいは kill したプロセス) の core イメージから自動的にスタックトレースを収集するデーモンを書いたので、これをセットアップしてサーバにインストールしとくといいかもです (kaztools/bt_cores at master · kazuho/kaztools · GitHub)。Linux のみ対応*1。使い方は bt_cores --help とするか、perl Makefile.PL && make install して man bt_cores。 具体的にいうと、Q4M とか Incline とか kazuho product が落ちたり固まったりしたらスタックトレース送ってくれると、私がうれしいです (古いバージョンのスタックトレースだととても悲しいです)。コアファイルは内部データがいろいろ入ってるから外部の人には見せられないけど、スタックトレース
nopan っていうレポジトリから直接ソフトウェアをインストールするインストーラを作り始めた件 - kazuhoのメモ置き場
perl の場合、CPAN モジュールは sudo cpan -i Module の１コマンドでインストールできる。でも、svn や git レポジトリのコードは、チェックアウトして perl Makefile.PL && make all test && sudo make install とか、めんどくさい。 なので、svn や git レポジトリからソースコードをダウンロードしてインストールするツールを作り始めた。名前は、CPAN モジュール以外も簡単にインストールできるところから、Not-only CPAN、略して nopan。 こんな感じで動きます。まだ適当だけど。 $ sudo nopan http://github.com/kazuho/kaztools.git downloading files from URL:http://github.com/kazuho/kazto
Tritonn のホットバックアップ(とsync ３回伝説) - kazuhoのメモ置き場
Tritonn のホットバックアップ環境を構築しようと思って調査。結論から言うと 漢(オトコ)のコンピュータ道: MySQLバックアップ頂上決戦！！ LVMスナップショット vs InnoDB Hot Backup の「MyISAMをスナップショットでバックアップ」でよさそう。 確認したこととしては、 Tritonn の全文検索データは FLUSH TABLES しても fsync されない つまり sync (1) の呼び出しが必須 linux の場合 sync (1) は１回呼べば十分だと man に書いてある POSIX 的には何回呼んでも書き込みが完了してる保証はない ってあたり。実際に、FLUSH TABLES WITH READ LOCK して sync ３回呼んでから LVM snapshot とって、myisamchk と sennachk してみたけど、myisamchk
ウェブ業界の15年、これからの10年 (Re ウェブアプリケーションサーバを複数台構成とか2010年代には流行らない) - kazuhoのメモ置き場
先のエントリ (ウェブアプリケーションサーバを複数台構成とか2010年代には流行らない) ではボトムアップに煽った書き方をしたけど、自分がトップダウンでどういうふうに捉えているかについて。以下、あくまでも私見です。 いわゆるネット業界は1990年代後半に始まってから15年くらいたったわけだけど、当初はマスメディア（静的コンテンツの配信）が業界の中心だったのが、パーソナライゼーションを経て、コミュニケーションツールへと変化してきた*1。 それにあわせて技術的な面でも分化が進み、今ではデータベースとアプリケーションサーバと httpd っていう三層構成が一般的になっている*2。 そもそも Apache って、モジュールをC言語で a-patchy に書いて動的コンテンツを作れるのが売りだったわけだけど、今じゃコモディティ化を通り越してレガシーソフトウェアの代表格。でもみんなあんまり困ってないの
ドキュメントとテストコードつきのPerlスクリプトを書く方法 - kazuhoのメモ置き場
Re http://d.hatena.ne.jp/perlcodesample/20091130/1258979624, http://mt.endeworks.jp/d-6/2009/12/scriptsubimport.html スクリプトとコードとテストを単一のファイルにまとめたい*1という需要が、かねて自分の中であったので教えを請うた結果、以下のような感じで書けばいいことがわかった。 #! /usr/bin/perl use modules...; my $global = ...; sub foo { ... } sub bar { ... } run_tests() if $ENV{HARNESS_ACTIVE}; # メインのコード foo(); bar(); ... sub run_tests { ... exit; } __END__ =head1 NAME my_scr
Apache を daemontools で管理する - kazuhoのメモ置き場
自作のサーバプログラムに、いちいち setuid とか setsid とかログローテート機能とか実装するのめんどくさいわけで。だから daemontools を使って管理してるわけですが、だったら、いっそ全部のデーモンを daemontools で一括管理したい。 ちょうど、reverse proxy をセットアップする機会があったので、apache を daemontools で管理する方法を備忘録をかねてメモ。 % cat /service/httpd/run #!/bin/sh APACHE_ROOT=/usr/local/apache-2.2.14 exec 2>&1 exec pgrphack $APACHE_ROOT/bin/httpd -DNO_DETACH -DFOREGROUND -c "ErrorLog /dev/fd/1" -c "Include /var/httpd
mysql と drizzle の負荷テストツール「skyload」が凄い！ - kazuhoのメモ置き場
tmaesakaさんがやってくれました。 ずいぶん前からSQLのベンチマークを測定するのに使いやすいプログラムないかなーと思ってました。個人的にはmysqlslapというのを使ってたのですが、幾らか気に入らない所があったりコマンドラインオプションが複雑で毎回 --help を読んだりしていました。余計な機能なんかなくて、指定したSQLを高速にくりかえしてくれる物が欲しいなぁって思ってたんです。 とあるIRCでこの前、tmaesakaさんから「いま作ってる」という話を聞いて、いろいろ要望を言ってたんですが、ついさっきチュートリアルが公開されました。速いw 名前はskyload。とても小さく、実装コードだと800行程度です。しかもオプションが少ないので使い方が単純です。試しに適当な INSERT の速度を測ってみました。 $ skyload --server=localhost --mysql
(特にMyISAMを使っていた)ウェブ屋さんがInnoDBを使う場合の設定項目 - kazuhoのメモ置き場
InnoDBはMyISAMと比較して安全(OSクラッシュや電源断が発生してもテーブルが壊れない)分、書き込みが遅い。データベース屋さんからすると、それは当然のことでMyISAMがおかしいんだ、ということになり、だからバッテリバックアップ機能のついたRAIDカードを使うんだ、という話になる。でも、MyISAMを使っているウェブ屋さんの現場では、場合によって多少データが消えてもかまわないから、安いハードウェアで大量のアクセスを捌きたい... って乖離があるんじゃないかなーと思ってる。 そのような場合には、my.cnf の innodb_flush_log_at_trx_commit パラメータを調整することで、MyISAMに比肩する書き込み速度を得ることができる(そのかわり、クラッシュや電源断の場合は、設定によって直近１秒以内の変更が失われる)。 他のパラメータも含めて書いておくと、データベー
サーバやI/O待ちを含むベンチマークを Benchmark::cmpthese で比較してはいけない、という話 - kazuhoのメモ置き場
Benchmark.pm の cmpthese は手軽に速度の比較ができるのでとても便利。でも、そもそも何のパフォーマンスを比較しているのか？ ソースコードを読めばわかるけど、 perl プロセスのCPU使用時間 あるいは、上記＋子プロセスのCPU使用時間 を測定している。換言すると、プロセス間通信のオーバーヘッドやサーバ側での処理時間はベンチマーク結果に反映されない。つまり、サーバのベンチマーク（あるいはプロセス間通信やI/O待ちを含むベンチマーク）を比較したい場合には、cmpthese を使うべきではない。 ＃サーバと通信するクライアントモジュールのベンチマークがほしい、といった場合はOK どうしても Benchmark.pm を使いたいなら、 use Benchmark qw(:hireswallclock); my $r = timethese(...); for my $v (v
「テキストプロトコルは遅くないよ」という話 - kazuhoのメモ置き場
「バイナリプロトコルは速い」「テキストプロトコルは遅い」という言説を、ときおり目にするけど、それって本当なのか。個人的には、それって昔の話だと思ってる。 SMTP みたいな、ペイロードについてもターミネータ（とエスケープ）を使うプロトコル*1は確かに遅い。で、FTPプロトコルでは、大容量のデータを「高速」に転送するために、制御用のTCPコネクションと転送用のコネクションを分けたりしてた。 だけど、HTTPプロトコルは、テキストプロトコルだけど、ペイロードについてはターミネータを使わない。keep-alive を行う際には、Content-Length ヘッダ（あるいはchunkedエンコーディング）を使うことで、ペイロードのパース／変換処理を不要にしている。別の言い方をすると、テキストプロトコルだからと言って、バイナリプトロコルよりペイロードの処理時間が長くなるとは限らない。HTTP 以降
FastCGI プロトコルってなんのためにあるのかわからない - kazuhoのメモ置き場
どういう場合に便利なんだっけ。てか HTTP プロトコルでいいじゃんみたいな。 たとえば httpd とアプリケーションサーバを分割するような環境なら、apache + fastcgi external server みたいな構成よりも、apache (mod_proxy + mod_proxy_balancer) + apache (mod_perl) とかのほうが柔軟だし。 あるいは、apache + fastcgi external server みたいなのを組むよりも、apache (mod_proxy + mod_proxy_balancer) + HTTP::Server::Simple (Net::Server::Prefork) でいいんじゃないかみたいな。 unix socket を動的に作成して通信、みたいたことをする場合でも、独自プロトコルな必要ってないんじゃないのか
シングルマスタ／マルチスレーブ構成に興味がない理由 - kazuhoのメモ置き場
システム全体で必要な書き込みパフォーマンスが、RDBMSノード１基の IOPS の W% の場合、シングルマスタ+スレーブn台構成のシステム全体のパフォーマンスは、 書き込みパフォーマンス: W 読み込みパフォーマンス: R=(1-w)*(n+1) になる。この n=R/(1-w)-1 って w が増加するとスレーブ増設のメリットが加速度的に失われていく点がイヤ。 例えば、システム全体で要求される書き込みパフォーマンスが W=0.3 で、読み込みパフォーマンスが 3 ならば、シングルマスタ／マルチスレーブ構成で必要なノード数は5台。マルチマスタ構成を採った場合でも理想値は4台なので、そう遜色があるわけではない。 しかし、仮に必要なパフォーマンスが２倍 (W=0.6, R=6) になると、必要ノード数はマルチマスタ構成での8台に対し、シングルマスタ／マルチスレーブ構成では16台と、一気にコス
JavaScript で任意の漢字にマッチする正規表現を書く - kazuhoのメモ置き場
重箱の隅で恐縮ですが。弾さんは (function(e){ e.innerHTML = e.innerHTML.replace( /東京都?([\u3200-\u4DBF\u4E00-\u9FFF\uF900-\uFAFF]+)/g, '首都$1東京' ) })(document.body)漢字を判定する正規表現が工夫のしどころでしょうか。[一-龠]はUnicode時代にはちょっと古い。grep CJK /usr/local/lib/perl5/5.10.0/unicore/Blocks.txtが参考資料代わりです。CJK Unified Ideographだけ欲しければ[\u4E00-\u9FFF]でも行けます。 404 Blog Not Found:javascript+regexp - ていうか首都最強東京bookmarklet とおっしゃってるけど、[\u4E00-\u9FFF]
innodb_flush_logs_at_trx_commit のベンチマーク - kazuhoのメモ置き場
binlog の設定等によって大きく変わると思うので要注意ですが、テストによっては、これぐらい差が出ます。 hdparm -W trx_commit 秒 0 0 25.492 0 1 281.078 1 0 24.138 1 1 67.051 測定環境は MySQL 5.1.35; linux 2.6.18; x86_64。 テーブルのスキーマは、 CREATE TABLE `hoge` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `text` varchar(255) NOT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB AUTO_INCREMENT=500001 DEFAULT CHARSET=utf8;mysqlslap のパラメータは、 mysqlslap -c 20 -i 5000 -q '
Re はやいTCPサーバの書き方 - kazuhoのメモ置き場
はやいTCPサーバの書き方 - nyaxtのPC作業ログ について、いくつか気になった点があったので。 Nagleアルゴリズムは、相手側のACK送信をまとめてくれるものです。これは、下記の様にアプリケーション側でパケットを意識した処理を行っている場合、邪魔になることがあります。 違うと思います。自分の理解では、Nagle アルゴリズムは、ACK を受信していないデータがある場合に、次のパケットを送信しない、というものです。RFC896 から引用すると、 The solution is to inhibit the sending of new TCP segments when new outgoing data arrives from the user if any previously transmitted data on the connection remains unackn
はやいTCPサーバを書く際に忘れがちなこと - kazuhoのメモ置き場
はやいTCPサーバの書き方 - nyaxtのPC作業ログ で id:nyaxt さんが書いてらっしゃるように、 epoll や kqueue を使う TCP_NODELAY, TCP_DEFER_ACCEPT *1 等を活用する TCP パケットを意識する I/O システムコールの回数を最小にする sendfile といったあたりは、確実にやるべきことだと思います。一方で、TCP 関連以外のオーバーヘッドが実は結構あって、 接続のタイムアウト処理 ログの出力 メモリの確保や解放をやらない あたりにも気を配る必要がある、と思います。 接続のタイムアウト処理については、以前 Kazuho@Cybozu Labs: 高速なCometサーバを書いてみた件 に書いたように、ビットアレイのリングバッファを使うのがベストだと思います。 ログの出力について、複数行を１回のシステムコールにまとめてもいいかど
linux サーバ上のメモリの ECC 訂正回数を確認する方法 - kazuhoのメモ置き場
メモリのエラー訂正はサーバでは必須だよという話もあるけど、じゃあ実際どのくらい訂正が発生しているのか。確認するには、/sys/devices/system/edac/mc/mc*/csrow*/edac_mode が S.?ECD.?ED になっていることを確認した上で /sys/devices/system/edac/mc/mc*/csrow*/ce_count を見ればいいっぽい。 $ cat /sys/devices/system/edac/mc/mc*/csrow*/edac_mode S4ECD4ED S4ECD4ED S4ECD4ED S4ECD4ED S4ECD4ED S4ECD4ED S4ECD4ED S4ECD4ED $ cat /sys/devices/system/edac/mc/mc*/csrow*/ce_count 0 0 0 0 0 0 0 0 普段作業している
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
