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 普段作業している
mmapのほうがreadより速いという迷信について - kazuhoのメモ置き場
@ITに以下のような記事が出て、 今回からしばらくの間は、まったく逆の例、つまり使うとプログラムの処理性能が上がるというシステムコールを紹介していく。システムコールを呼ぶ回数は少ない方が処理性能は高くなるという原則は変わらないが、呼び出しておくと処理性能が向上するシステムコールというものが存在するのだ。こうしたシステムコールを使わないでいることは、とてももったいない。 今回紹介するシステムコールは「mmap(2)」だ。ここでは詳しく仕組みを解説しないが、mmap(2)は、プログラムの処理性能に必ず良い影響を与える。 やはりあった？ 高速化に効くシステムコール (1/2)：知ってトクするシステムコール（3） - ＠IT それを真に受けたのか、「Go言語でmmapシステムコールを使ったファイル読み込みの高速化検討とC言語のコンパイラの話 - ryochack.blog」のようなブログエントリも
同時にwrite(2)すると混ざるかどうか - kazuhoのメモ置き場
Linux のシステムコールである write(2) の ドキュメントを読むと Atomic/non-atomic: A write is atomic if the whole amount written in one operation is not interleaved with data from any other process. This is useful when there are multiple writers sending data to a single reader. Applications need to know how large a write request can be expected to be performed atomically. This maximum is called {PIPE_BUF}. This volume of
InnoDB の insert buffer - kazuhoのメモ置き場
INSERT 処理のスループットについて、ユニーク制約のないインデックスについては、ディスクに落ちてても大きな問題にならないらしい。 逆に言うと、セカンダリインデックスについては、無駄に UNIQUE とかつけるべきではない。 9.4.4. Issues with the Insert Buffer Secondary indexes are usually non-unique, and insertions into secondary indexes happen in a relatively random order. This would cause a lot of random disk I/O operations without a special mechanism used in InnoDB called the insert buffer. When a rec
[メモ] TCP/IPプログラミングにおけるエラー処理 (RSTパケットの飛ばし方と検出の仕方) - kazuhoのメモ置き場
SO_LINGER の秒数を 0 にしてソケットを閉じればいい。Perl で書くなら以下のような感じ。 setsockopt($sock, SOL_SOCKET, SO_LINGER, pack("II", 1, 0)) or die $!; $sock->close() 一方で RST によって切断 (＝異常切断された) かどうかはソケットからの読み込みが ECONNRESET エラーを返すかどうかで判断できる（正常切断なら 0 (==EOF) が返る)。
![[メモ] TCP/IPプログラミングにおけるエラー処理 (RSTパケットの飛ばし方と検出の仕方) - kazuhoのメモ置き場](https://cdn-ak-scissors.b.st-hatena.com/image/square/7094f829d5f0ef6ce8729219f846ece7e12712b0/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F17680117127106341284%2F17680117127106348519%2F1556845903)
ファイルに書かれたら 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,
Tiarra (あるいはPerl) からhosts.allowとか使ってアクセス制御する話 - kazuhoのメモ置き場
諸般の事情で、ついに Tiarra ユーザーになったんですけど、Dynamic DNS を使って SSH アクセスを制限する方法 - kazuhoのメモ置き場 に書いたようにサーバのアクセス制限を hosts_access 使ってやってるので Tiarra についても同様にしたい。 Perl の場合は Authen::Libwrap モジュールを使えばいいので、パッチ書いた。取り込んでもらおうとか別に思ってないので、モジュールがなかった場合の処理とか入ってないですが。 これで SSH をはじめ各種デーモンのアクセス制御を統一的にできるので楽ちん。 $ diff -u main/RunLoop.pm.orig main/RunLoop.pm --- main/RunLoop.pm.orig 2010-12-01 17:02:14.000000000 +0900 +++ main/RunLoo
2010年代には Apache の mpm_prefork とか流行らない (もしくは HTTP keep-alive のメリットとデメリット) - kazuhoのメモ置き場
HTTP の持続的接続の功罪について はじめに、HTTP の持続的接続 (keep-alive) のメリットについて。持続的接続を使うメリットは、以下の２点。 TCP 接続の確立にかかる時間の節約*1 TCP の接続と切断に必要な資源 (CPUとネットワーク) の節約 ウェブブラウザ〜データセンタ間の通信で、持続的接続を使う理由は、このうちの前者。特に太平洋を超えるようなケースだと、TCP 接続に0.2秒とかかかるので、メリットが大きい。 一方、持続的接続のデメリットは、 接続が切断されるまでの間、その接続を維持するためにコストがかかる (主としてメモリが無駄になる) という点になる。特に、１プロセス１コネクションを前提とするアーキテクチャ (例: mod_perl) だと、メモリの無駄使いが、とてもひどいことになる。 そこで、ブラウザからの接続を受ける HTTP サーバとアプリケーション
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
ドキュメントとテストコードつきの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
(特にMyISAMを使っていた)ウェブ屋さんがInnoDBを使う場合の設定項目 - kazuhoのメモ置き場
InnoDBはMyISAMと比較して安全(OSクラッシュや電源断が発生してもテーブルが壊れない)分、書き込みが遅い。データベース屋さんからすると、それは当然のことでMyISAMがおかしいんだ、ということになり、だからバッテリバックアップ機能のついたRAIDカードを使うんだ、という話になる。でも、MyISAMを使っているウェブ屋さんの現場では、場合によって多少データが消えてもかまわないから、安いハードウェアで大量のアクセスを捌きたい... って乖離があるんじゃないかなーと思ってる。 そのような場合には、my.cnf の innodb_flush_log_at_trx_commit パラメータを調整することで、MyISAMに比肩する書き込み速度を得ることができる(そのかわり、クラッシュや電源断の場合は、設定によって直近１秒以内の変更が失われる)。 他のパラメータも含めて書いておくと、データベー
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 を動的に作成して通信、みたいたことをする場合でも、独自プロトコルな必要ってないんじゃないのか
Ptrace と TOCTOU 攻撃 - kazuhoのメモ置き場
帰国して、ようやく 404 Blog Not Found:perl - Shibuya.pm #11:The Catcher in the INT 80h が読めるようになった id:kazuhooku です。弾さんのスライドは、FreeBSD 特有の事情と、その問題をカバーしようとするための努力について解説していて、とてもおもしろく読ませていただきました。が、一点、気になったのが TOCTOU (Time-Of-Use Time-Of-Attack) 攻撃への対策についてです。TOCTOU 攻撃とは何か、端的に言うと、 You can't stop the invocation but you can still poke the argument on the stack. Shibuya.pm #11:The Catcher in the INT 80h とのことですが、同様のことを
今回の shibuya.pm で一番困ったこと - kazuhoのメモ置き場
M○SQL Conference & Expo 参加中のため、アメリカから shibuya.pm 関連のブログエントリを読んでいるわけですが。一番困るのは発表者の皆さんが shellcode (あるいはそれっぽいもの) をブログに貼りまくってること。 ホテルのインターネット回線 (LODGENET) に接続されている IDS が、どうも HTTP 上を流れる shellcode を監視しているらしく、x86 バイナリ*1が流れた瞬間に、 「攻撃を検知しました。10分間回線を切断します」 って表示がでて、インターネットにつながらなくなる。これじゃ仕事になんないよー >< LODGENET-- ということで、回線断中の怒りにまかせてブログ更新。IDS 開発者の意図はわかるんだけど、いったいどこの製品なんだろ。 ちなみに MyS○L が伏せ字なのは、このどうでもいいエントリが http://jp
NanoA を mod_perl で使用する方法 - id:kazuhookuのメモ置き場
svn 版を適当な公開ディレクトリに展開 以下のような感じで httpd.conf と startup.pl を記述 (パスは適当に書き換えてください) ウマー httpd.conf Alias /nanoa /Users/kazuho/dev/NanoA RedirectMatch permanent ^/nanoa/$ /nanoa/nanoa.pl PerlRequire /Users/kazuho/dev/NanoA/etc/statup.pl <Location "/nanoa/nanoa.pl"> SetHandler perl-script PerlResponseHandler ModPerl::RegistryPrefork PerlOptions +ParseHeaders Allow from All Options +ExecCGI </Location> <Dir
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
