タグ

ブックマーク / kazuhooku.hatenadiary.org (22)

  • グリーンITとメモリの消費電力 - id:kazuhookuのメモ置き場

    昨日、GREE Engineering (SAKURA インターネットさんの講演でグリーンITの話題が出ていた) の懇親会で、環境に優しい memcached サーバを構築するには古い CPU を捨てるべきかみたいな話を id:hyoshiok さんがしてて、それに「メモリの消費電力のが重要なのでは」みたいな絡みかたをしていたわけですが (またかよ、的ですみません) で、ちょっと気になって調べてみた。以下 facts DDR → DDR2 に移行して消費電力が下がった (動作電圧が下がったため) FB-DIMM の実消費電力はアイドル時で 10W/DIMM くらい *1 DDR2 DIMM の絶対最大定格は、 18W/DIMM とか *2 Opteron の CPU slot あたり DIMM が8なサーバ組むような場合だと、メモリをかなり気にする印象があった*3けど、平均消費電力的な意

    グリーンITとメモリの消費電力 - id:kazuhookuのメモ置き場
  • MySQL や PostgreSQL でトリガーベースの実体化ビューを後から追加する方法 (もしくは無停止での CREATE INDEX) - kazuhoのメモ置き場

    読み込み>書き込みなデータベースだと、実体化ビュー (materialized view) を使って読み込み速度を上げるってのは有効な手法 ちなみに MySQL や PostgreSQL だと実体化ビューはトリガーを使って書く *1 では、トリガーベースの実体化ビューを後から追加した場合に、どうやって既存データを新しいビューに反映させるのか。 UPDATE トリガを、ビューの側に対応するデータがない場合は INSERT トリガと同様の動作をするように実装すればいい (典型的には REPLACE INTO 文を使う)。ビューの初期データ充填は UPDATE src_table SET id=id; MySQL だと CREATE INDEX CONCURRENTLY がないから副インデックス作成はスレーブでやったりする*2けど、上の UPDATE を LIMIT つきで回すことで、ビューをイ

    MySQL や PostgreSQL でトリガーベースの実体化ビューを後から追加する方法 (もしくは無停止での CREATE INDEX) - kazuhoのメモ置き場
  • ウェブアプリケーションサーバを複数台構成とか2010年代には流行らない - kazuhoのメモ置き場

    タイトルは煽り入ってますが。 仮に動的ページを生成するのにかかる時間が1秒、そのうちデータベースやmemcached等リモートサーバへの問い合わせ時間を除くいたCPUの処理時間が0.1秒とする。また、ピークのリクエスト処理量は、平均の2倍とする。 そうすると、クアッドコアのアプリケーションサーバで処理できるリクエストは、 4 core * 10 reqs/sec * 86,400 sec/day * 30 day/mon / 2 = 51,840,000 reqs/mon と、約5,000万PV/月を1台で捌けることになる。 CPUが動いている時間は全処理時間の10倍と仮定したわけだから、アプリケーションサーバの最大同時接続数は 4 core * 10 = 40 程度あればいいことになる。実際には、安全係数を2倍かけて 80 とか。リクエストの処理に必要なメモリ量を 100MB とすると、

    ウェブアプリケーションサーバを複数台構成とか2010年代には流行らない - kazuhoのメモ置き場
  • linuxで httpd が使ってるメモリ総量を調べる話 - kazuhoのメモ置き場

    Perl等のLLでウェブアプリケーションサーバを書いていると、普通はマルチプロセスモデル (apache なら prefork とか) で運用することになると思う。で、それらがどれだけメモリを使っているか、っていうのはチューニングにおいて重要になってきたりする (んじゃないかと思う) けど、そもそもメモリの総使用量をどうやって測定するのか。 20:20追記: PSSを使ってワンライナーで測定するのが簡単 (コメント欄参照)。kosakiさんありがとうございます。 $ sudo perl -le 'for my $p (@ARGV) { open my $fh, "< /proc/$p/smaps" or die $!; map { /^Pss:\s*(\d+)/i and $s += $1 } <$fh> } print $s' `pgrep plackup` 914325以下は初回投稿時

    linuxで httpd が使ってるメモリ総量を調べる話 - kazuhoのメモ置き場
  • ドキュメントとテストコードつきの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

    ドキュメントとテストコードつきのPerlスクリプトを書く方法 - kazuhoのメモ置き場
  • vipっていうviラッパー作った - kazuhoのメモ置き場

    http://github.com/kazuho/vip/ よくperlとかで、 $ perl print "テストコードを色々..."; ... ^Dとかやってテストするけど、コード書き間違えちゃったりした時に編集できなくてめんどいのと、書いたコードが失われちゃうのが嫌だなあと思ってた。で、ついに重い腰をあげて、2つの問題を解決するラッパー書いた。 $ vip | perlとかやると、vi で編集した結果を標準出力にはいてくれる。ファイルは $HOME/vip 以下に保存されるので、あとから探すこともできる。 以下FAQ Q. $ENV{EDITOR} を見てくれないのですが? A. vip (vi pipe) なので vi 専用です ... てか vip 言いたいだけ (ry

    vipっていうviラッパー作った - kazuhoのメモ置き場
  • (特にMyISAMを使っていた)ウェブ屋さんがInnoDBを使う場合の設定項目 - kazuhoのメモ置き場

    InnoDBはMyISAMと比較して安全(OSクラッシュや電源断が発生してもテーブルが壊れない)分、書き込みが遅い。データベース屋さんからすると、それは当然のことでMyISAMがおかしいんだ、ということになり、だからバッテリバックアップ機能のついたRAIDカードを使うんだ、という話になる。でも、MyISAMを使っているウェブ屋さんの現場では、場合によって多少データが消えてもかまわないから、安いハードウェアで大量のアクセスを捌きたい... って乖離があるんじゃないかなーと思ってる。 そのような場合には、my.cnf の innodb_flush_log_at_trx_commit パラメータを調整することで、MyISAMに比肩する書き込み速度を得ることができる(そのかわり、クラッシュや電源断の場合は、設定によって直近1秒以内の変更が失われる)。 他のパラメータも含めて書いておくと、データベー

    (特にMyISAMを使っていた)ウェブ屋さんがInnoDBを使う場合の設定項目 - kazuhoのメモ置き場
  • 彼氏がMyISAM使ってた。別れたい… - kazuhoのメモ置き場

    追記: マジメな比較はこちら:Open database life: MyISAMとInnoDBのどちらを使うべきか MyISAMだとPostgreSQLと並べられた時なんか恥ずかしいww 下向いちゃうしww ウェブサイトにはせめてInnoDB使って欲しい・・・ 勉強会とかで発表されたら・・・・もう最悪ww せめて普通にトランザクションやMVCCぐらいは対応して欲しい。 常識的に考えて欲しいだけなんです! MyISAMでテーブルロックしちゃった時の遅さとか分かる? あのね?たとえばピーク時10〜20並行ぐらいで書込みとか行くでしょ? それぞれ別の接続で来るわけじゃない? みんな普通にグループコミットやアシッドネス期待してるわけでしょ? MyISAMでテーブル壊れてリペアしてたら大恥かくでしょうがww じゃあ MyISAM はどういう用途に適しているのか。待て! 次号!*1 参考: 彼氏が軽

    彼氏がMyISAM使ってた。別れたい… - kazuhoのメモ置き場
  • サーバや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

    サーバやI/O待ちを含むベンチマークを Benchmark::cmpthese で比較してはいけない、という話 - kazuhoのメモ置き場
  • HTTPプロトコルパーサのオーバーヘッドは18%以下という話 - kazuhoのメモ置き場

    「テキストプロトコルは遅くないよ」という話 - kazuhoのメモ置き場に関するの具体的な話。 Kazuho@Cybozu Labs: 「サーバ書くなら epoll 使うべき」は、今でも正しいのかを書く際に自作したベンチマークツールがあるのですが、それを使ったベンチマーク結果をid:tokuhiromがhttp://d.hatena.ne.jp/tokuhirom/20091001/1254355956にまとめてくれている*1。それについて、ちょっと補足と実測値を。 まず、コメントにも書いたんだけど、サーバのスループットを測る際にはTCP接続を多重化する必要があるので、-a 100 -n 100 -f *2のようなオプションでベンチマークをとってください。あと、ローカルホスト上での測定か、ホスト間での測定か、によっても当然結果は変わる。 自分の環境 (linux 2.6.18-028sta

    HTTPプロトコルパーサのオーバーヘッドは18%以下という話 - kazuhoのメモ置き場
  • 「テキストプロトコルは遅くないよ」という話 - kazuhoのメモ置き場

    「バイナリプロトコルは速い」「テキストプロトコルは遅い」という言説を、ときおり目にするけど、それって当なのか。個人的には、それって昔の話だと思ってる。 SMTP みたいな、ペイロードについてもターミネータ(とエスケープ)を使うプロトコル*1は確かに遅い。で、FTPプロトコルでは、大容量のデータを「高速」に転送するために、制御用のTCPコネクションと転送用のコネクションを分けたりしてた。 だけど、HTTPプロトコルは、テキストプロトコルだけど、ペイロードについてはターミネータを使わない。keep-alive を行う際には、Content-Length ヘッダ(あるいはchunkedエンコーディング)を使うことで、ペイロードのパース/変換処理を不要にしている。別の言い方をすると、テキストプロトコルだからと言って、バイナリプトロコルよりペイロードの処理時間が長くなるとは限らない。HTTP 以降

    「テキストプロトコルは遅くないよ」という話 - kazuhoのメモ置き場
  • C/C++に文字エンコーディングバリデーション機能がないって、ほんと? - kazuhoのメモ置き場

    通りすがり (2009-09-16 18:09) > PHP以外の言語は「(略)」のに対し ここに挙げられている言語がWebアプリで使われる全ての言語ではない。 例えば、CやC++にはない。付け足せば、PHPPerlなどのCモジュール内部で起こった不正な文字はスルーされうる。 よって、「PerlJava、.NETRubyPHPの中では」と書けば筋は通るが、「PHP以外では」は誤り。 そしてそんなことを、PHPの(脆弱性撲滅に注力している)開発者に言ったら、喧嘩を売られたと受け止められて当然。 PHP以外では: 既にあたり前になりつつある文字エンコーディングバリデーション - 徳丸浩の日記(2009-09-14) というコメントが気になった。 C言語にある文字コード変換機能って言ったら mbtowc だと思うけど、mbtowc は無効なバイト列を受け取ると EILSEQ を返すことに

    C/C++に文字エンコーディングバリデーション機能がないって、ほんと? - kazuhoのメモ置き場
  • HTTP::Parser::XS - a PSGI compatible, fast http parser - kazuhoのメモ置き場

    んー、と思って、書いた。GitHub - kazuho/p5-http-parser-xs: a fast http parser BLURB は、 PSGI のリクエストオブジェクトを返す 高速 同期 httpd, 非同期 httpd のどちらを実装する際にも使用可能 POST コンテンツのハンドリングはご自分で いったんファイルに入れたり、いろいろ要件があるし、パース作業は発生しないので Perl でもあまり遅くならないため てな感じです。以下ベンチマーク。 $ ./http-parser-vs-xs-benchmark.pl Rate HTTP::Parser HTTP::Parser::XS HTTP::Parser 2978/s -- -95% HTTP::Parser::XS 54348/s 1725% --ベンチマークに使ったコードは、以下のとおり。 #! /usr/bin/

    HTTP::Parser::XS - a PSGI compatible, fast http parser - kazuhoのメモ置き場
  • シングルマスタ/マルチスレーブ構成に興味がない理由 - kazuhoのメモ置き場

    システム全体で必要な書き込みパフォーマンスが、RDBMSノード1基の IOPS の W% の場合、シングルマスタ+スレーブn台構成のシステム全体のパフォーマンスは、 書き込みパフォーマンス: W 読み込みパフォーマンス: R=(1-w)*(n+1) になる。この n=R/(1-w)-1 って w が増加するとスレーブ増設のメリットが加速度的に失われていく点がイヤ。 例えば、システム全体で要求される書き込みパフォーマンスが W=0.3 で、読み込みパフォーマンスが 3 ならば、シングルマスタ/マルチスレーブ構成で必要なノード数は5台。マルチマスタ構成を採った場合でも理想値は4台なので、そう遜色があるわけではない。 しかし、仮に必要なパフォーマンスが2倍 (W=0.6, R=6) になると、必要ノード数はマルチマスタ構成での8台に対し、シングルマスタ/マルチスレーブ構成では16台と、一気にコス

    シングルマスタ/マルチスレーブ構成に興味がない理由 - kazuhoのメモ置き場
  • OpenVZ系の環境でプロセスの使用メモリ量を節約するライブラリを書いた - kazuhoのメモ置き場

    以前、 スワップがなく、かつ、overcommit が効かないので、いろいろ動かない。 apache 2 系の worker mpm とか標準設定だと起動時に 500MB 確保するので当然起動すらしない。 もう LD_PRELOAD で malloc を MAP_SHARED な mmap(2) にマップする共有ライブラリ作ろうかなぁ。なんという劣化再発明。 OpenVZ 系の VM の二重苦 - kazuhoのメモ置き場 と書いたわけですが、これを実現する morememory.so という共有ライブラリを作った (/platform/linux/morememory – CodeRepos::Share – Trac)。LD_PRELOAD なので、以下のような感じで、既存のプログラムを再コンパイルせずに使える。 % gcc -fPIC -Wall -g -O -shared more

    OpenVZ系の環境でプロセスの使用メモリ量を節約するライブラリを書いた - kazuhoのメモ置き場
  • Q. UTF-8 の冗長性問題は、設計上の問題なのか? - kazuhoのメモ置き場

    UTF-8 は、逆方向へのスキャンが可能、バイナリ比較の結果が UCS と同じ、といった特徴をもつ一方、冗長なエンコーディングが可能という欠点をもっている。では、前者の特徴を活かしたまま、後者の問題をもたないエンコーディングを定義することはできるだろうか? 定義が可能と考える場合は、そのアルゴリズムを、不可能だと考える場合はその理由を記せ。 (配点:20点) 参考: http://wassr.jp/user/kazuho/statuses/XqsSvKL1hQ, UTF-8 冗長 - Google 検索

    Q. UTF-8 の冗長性問題は、設計上の問題なのか? - kazuhoのメモ置き場
  • 呼び出し元のコンテキストで eval する方法 - kazuhoのメモ置き場

    String::TT なんかがそうですけど、呼び出し元の変数を使いたい、ということがときどきあります。たとえば、 sub hello_to_alice { my $user = "Alice"; say_hello(); # "Hello to Alice!" と言ってほしい } って書きたいとか、そういうケースですね。結論から言うと、以下のように say_hello 関数を定義すれば可能です。こんな感じ。 sub say_hello { @_ = ('print "Hello to $user!\n"', undef); goto &DB::eval_in_parent_and_return; } package DB; sub DB::eval_in_parent_and_return { my ($expr, $retvar) = @_; eval("package " . (cal

    呼び出し元のコンテキストで eval する方法 - kazuhoのメモ置き場
  • perl から任意の C ライブラリを呼び出す方法 - kazuhoのメモ置き場

    syscall って組込関数でシステムコールはできますけど、libc やその他ライブラリの関数を呼びたい、ってこともありますよね。i386 かつ dlopen な環境なら、こんな風に書けます。 use DynaLoader; use ops; sub ccall { my $r = '1111'; my $s = "\x68" . pack("L", $_[5]) . "\x68" . pack("L", $_[4]) . "\x68" . pack("L", $_[3]) . "\x68" . pack("L", $_[2]) . "\x68" . pack("L", $_[1]) . "\xb8" . pack("L", ("Dyna"."Loader")->can("dl_find_symbol")->(("Dyna"."Loader")->can("dl_load_file")->

    perl から任意の C ライブラリを呼び出す方法 - kazuhoのメモ置き場
  • Encode::compat::MIME::Header::ISO_2022_JP つーモジュールをでっちあげた - kazuhoのメモ置き場

    perl 5.8.7 以前かつ Encode のバージョンアップできねーみたいな環境でも互換性を保ちながら書けるように。 use Encode; use Encode::compat::MIME::Header::ISO_2022_JP; my $subject = encode('MIME-Header-ISO_2022_JP', '日語の件名'); みたいな感じ。コピペプログラミング万歳。コードは http://coderepos.org/share/browser/lang/perl/Encode-compat-MIME-Header-ISO_2022_JP/ に置いてあります。 アドバイスをくれた id:miyagawa++ id:tokuhirom++ Encode メンテナの id:dankogai++ Encode::MIME::Header::ISO_2022_JP コピ

    Encode::compat::MIME::Header::ISO_2022_JP つーモジュールをでっちあげた - kazuhoのメモ置き場
  • NanoA というウェブアプリケーションフレームワークをかいてみた - id:kazuhookuのメモ置き場

    CGI というシーンにおける現状の Perl のウェブアプリケーションフレームワークの問題点とは 都度 perl のインタープリタインスタンスを起動するのでモジュールの読みこみ/コンパイルコストを無視できない bless の速度を無視できない といったあたりであると認識している。 http://d.hatena.ne.jp/tokuhirom/20081111/1226418572 自分は、Sledge も Catalyst も Mojo も Rails も boofy も使ったことがありませんが、別に必要なモジュールをロードしたり bless したりするのはしょうがないのかなと思います。ただ、 不要なコントローラ (+それに伴う多数のモジュール) までロードしている ということが一番の問題なのかなと思いました。というわけで作った。 CodeRepos の /lang/perl/NanoA

    NanoA というウェブアプリケーションフレームワークをかいてみた - id:kazuhookuのメモ置き場