mmapのほうがreadより速いという迷信について - kazuhoのメモ置き場
@ITに以下のような記事が出て、 今回からしばらくの間は、まったく逆の例、つまり使うとプログラムの処理性能が上がるというシステムコールを紹介していく。システムコールを呼ぶ回数は少ない方が処理性能は高くなるという原則は変わらないが、呼び出しておくと処理性能が向上するシステムコールというものが存在するのだ。こうしたシステムコールを使わないでいることは、とてももったいない。 今回紹介するシステムコールは「mmap(2)」だ。ここでは詳しく仕組みを解説しないが、mmap(2)は、プログラムの処理性能に必ず良い影響を与える。 やはりあった？ 高速化に効くシステムコール (1/2)：知ってトクするシステムコール（3） - ＠IT それを真に受けたのか、「Go言語でmmapシステムコールを使ったファイル読み込みの高速化検討とC言語のコンパイラの話 - ryochack.blog」のようなブログエントリも
ファイルに書かれたら irc とかネットに通知するとかそういうデーモンを作るときは mkfifo するといいんじゃないか - kazuhoのメモ置き場
デーモン側をこんな感じで書きます。 use Errno qw(EEXIST); use Fcntl qw(S_IFIFO); use POSIX qw(mkfifo); my $FIFO_NAME = "/tmp/my_messenger.fifo"; if (mkfifo($FIFO_NAME, 0666)) { # ok } elsif ($! == EEXIST) { die "$FIFO_NAME is not a fifo!" unless +(stat($FIFO_NAME) & !S_IFIFO) != 0; } else { die "failed to create fifo:$FIFO_NAME, $!"; } while (1) { open my $fh, '<', $FIFO_NAME or die "failed to open fifo:$FIFO_NAME,
2010年代には Apache の mpm_prefork とか流行らない (もしくは HTTP keep-alive のメリットとデメリット) - kazuhoのメモ置き場
HTTP の持続的接続の功罪について はじめに、HTTP の持続的接続 (keep-alive) のメリットについて。持続的接続を使うメリットは、以下の２点。 TCP 接続の確立にかかる時間の節約*1 TCP の接続と切断に必要な資源 (CPUとネットワーク) の節約 ウェブブラウザ〜データセンタ間の通信で、持続的接続を使う理由は、このうちの前者。特に太平洋を超えるようなケースだと、TCP 接続に0.2秒とかかかるので、メリットが大きい。 一方、持続的接続のデメリットは、 接続が切断されるまでの間、その接続を維持するためにコストがかかる (主としてメモリが無駄になる) という点になる。特に、１プロセス１コネクションを前提とするアーキテクチャ (例: mod_perl) だと、メモリの無駄使いが、とてもひどいことになる。 そこで、ブラウザからの接続を受ける HTTP サーバとアプリケーション
ウェブ業界の15年、これからの10年 (Re ウェブアプリケーションサーバを複数台構成とか2010年代には流行らない) - kazuhoのメモ置き場
先のエントリ (ウェブアプリケーションサーバを複数台構成とか2010年代には流行らない) ではボトムアップに煽った書き方をしたけど、自分がトップダウンでどういうふうに捉えているかについて。以下、あくまでも私見です。 いわゆるネット業界は1990年代後半に始まってから15年くらいたったわけだけど、当初はマスメディア（静的コンテンツの配信）が業界の中心だったのが、パーソナライゼーションを経て、コミュニケーションツールへと変化してきた*1。 それにあわせて技術的な面でも分化が進み、今ではデータベースとアプリケーションサーバと httpd っていう三層構成が一般的になっている*2。 そもそも Apache って、モジュールをC言語で a-patchy に書いて動的コンテンツを作れるのが売りだったわけだけど、今じゃコモディティ化を通り越してレガシーソフトウェアの代表格。でもみんなあんまり困ってないの
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以下は初回投稿時
Boehm GCをC++のスマートポインタっぽく使う話 - kazuhoのメモ置き場
C++のプログラムを書いててGCを使いたくなるようなケースにぶつかったことは、ここ数年ないんですが、Goの絡みで、そういえばBoehm GCをC++のスマートポインタっぽく使えたら便利なのかな、とか思った。書くとしたら、こんな感じだろうか。 換言するならば、既存のクラスをBoehm GCで管理できる。絶対既出のネタ。 デリファレンスは余計に発生するけど、そもそもGCが必要になるようなデータ構造は少ない(だろう)し、小粒度のデータは自前でメモリ管理すりゃいい(し、難しくもない)ので、この程度で十分かなーと。 追記：あーでも C++0x のクロージャと組み合わせる場合を考えると、デリファレンス回数は減らしたいのかなー。 #include <gc_cpp.h> #include <string> template <typename T> class gc_ptr { struct gc_ptr
X25-M の速度低下の件 - kazuhoのメモ置き場
うちの環境。2.5TB ほど書いてるのかー $ iostat -k Linux 2.6.18-92.el5 (************) 02/14/2009 avg-cpu: %user %nice %system %iowait %steal %idle 0.03 4.92 2.24 6.83 0.00 85.98 Device: tps kB_read/s kB_wrtn/s kB_read kB_wrtn sda 1.02 11.87 7.33 100872054 62310908 sdb 148.58 2032.49 293.11 17270144052 2490585937 $ ./randombench.cc -b 16 -c 1 -f 102400 -l 20000 -m read /var/ssd/tmp/hoge block size: 16 KB file size:
Linux で共有ライブラリをビルド＆配布する際に気をつけること - kazuhoのメモ置き場
Linux の共有ライブラリをリンクするためのハッシュテーブルは、従来、.hash というセクションに収められていたのが、CentOS 5.0 や Fedora Core 6 以降? といった新しい環境では、.gnu.hash という新しいセクションに収められるようになった。 で、後者の環境で何も考えずに共有ライブラリをビルドすると、.gnu.hash セクションのみをもつものができあがるんだけど、それを Debian Etch とかに持っていくと、dlopen した際に SIGFPE で落ちてしまう。 問題を回避するためには、リンカに --hash-style=both というオプションを渡してやれば、両方のセクションが作成されるので、この問題を回避できる。 Q4M もこの問題にはまって、0.8.2 をリリースすることになりました。幸い問題を発見した人が id:hirose31 さん (
memcpy 最適化 - kazuhoのメモ置き場
バイト単位でコピーするアホなコードの方が、勝手にベクトル化される分、gcc 内蔵のヤツより最大３倍高速なんだってwww memcpy() compiled with vectorizing compilers All current compilers for linux should support SSE2 auto-vectorization with #include <string.h> void *(memcpy)(void *restrict b, const void *restrict a, size_t n){ char *s1 = b; const char *s2 = a; for(; 0<n; --n)*s1++ = *s2++; return b; }(中略) x86-64 gcc memcpy() (中略) Linking in a user-compiled
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Linux (NPTL) の pthread_rwlock_t はデフォルトがリーダー優先 - kazuhoのメモ置き場