Memcached のベンチマークツールを公開しました。自作の KVS のパフォーマンス測定に使っていたものです。 以下のように簡単にベンチマークがとれます。 $ mcbench -b 10000 -t 10 -n 1000 -s 127.0.0.1 -p 11211 -c get ==== mcbench started ======================= Server: 127.0.0.1:11211 10 threads x 1000 = 10000 commands. Inserting base data 10000 ... done Sending get Commands ... done ==== mcbench result ======================== Interval: 138 msec Performance: 72661 comma
しばらく放置してましたが、久々にZabbixをいじる時間が出来たので、前回の続きの設定をします。 インストール ひとまず、zabbix インストールメモ にあるようにインストールがおこなわれていて、Zabbixのページにアクセスできることが前提です。バージョンは1.6.4みたいです。 日本語化 右上の[profile]リンクから言語を変更できます。 設定ファイルの編集 設定しなければならない主な設定は zabbix_agent.conf 監視対象のサーバ zabbix_agentd.conf 監視対象のサーバ zabbix_server.conf 監視サーバ dbconfig.php 監視サーバ 以下、順に。 すべての監視対象の /etc/zabbix/zabbix_agent.conf を編集します。 # This is config file for zabbix_agent # To
前回は、kumofsはなぜスケールするかということについて紹介しました。その中で最後に、耐障害性もスケーラビリティにとって重要だーと述べました。 そこで今回は、kumofsはなぜ落ちないのか、なぜ耐障害性が高いと言えるのかーということについて紹介したいと思います。 分散システムはテストが難しいことに定評がありますが(たぶん^^;)、その中でも耐障害性の検証は最上級に困難な部類です。 耐障害性は実際のところ、アルゴリズムの設計以前に実装上のバグが大きく影響するので、設計上は耐障害性が高いと言っていても、実際に使ってみると良く止まるという話はありがちな話です。(個人で開発している場合など、開発リソースが小さい場合はなおさら) そのため耐障害性の高いシステムを実現するためには、実装しやすくバグが入り込みにくい設計も重要かなーと思います(もちろん、アルゴリズムも重要ですが)。 分散システムには複雑
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く