dyld: DYLD_ environment variables being ignored because main executable (/usr/bin/sudo) is setuid or setgid

Mountain Lion で bashrc や zshrcに「export DYLD_LIBRARY_PATH」が書いあると sudo する時に警告が出る。
バグの模様。

追記

「export DYLD_LIBRARY_PATH」の設定が必要な人には正当な対応策は存在しない。 無理矢理回避する方法はあるが、それほど意味がないので、無視するのが良いと思われる。

2013年12月29日追記

Mac OS X 10.9 Mavericks ではこの問題は解決しています。

ifttt で Google Apps の Google Talk を有効にする方法

IFTTTは、いろいろな Web サービスを連携させる Web サービスです。
IFTTT では Google Talk と連携させることができますが Google Apps を利用している場合 Google Talk と連携させようとしても連携のために必要な PIN コードが送信されてきません。
これは、Google Apps の DNS 設定が不足しています。設定の方法は「Google Apps を使用していないユーザーとのチャットを有効にする - Google Apps ヘルプ」に詳しく記述されていますが「SRV レコード」の登録が必要です。

この「SRV レコード」に対応している DNS 業者は非常に少ないようです。
有料(普通の利用なら月 1 ドル以下)ですが、「Amazon Route 53」なら確実に対応しているのでこれを利用するのが良いでしょう。
どうしてもお金をかけたく無い場合は、ifttt の連携先としては Google Apps の Google Talk はあきらめるか、ifttt 側で Google Apps の Google Talk に対応してくれるのを待った方が良いでしょう。

Linuxサーバの反応が遅い(重い)場合の原因の調査手順

概要

Linuxサーバの反応が遅い場合の調査手順のメモ。
実行する場合は自己責任でお願いします。

原因として考慮すべき事項

サーバが遅い場合には様々な原因がありますが、以下を考慮します。

• CPU負荷
• メモリ不足
• ディスクI/O負荷
• ネットワークI/O負荷

まず、どれが原因か調査する必要があります。

top コマンド

最初は「top」コマンドを利用します。

top

以下のような出力になります。

top - xx:xx:xx up 0 min,  1 user,  load average: 1.44, 0.51, 0.18
Tasks:  87 total,   1 running,  86 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.7%us,  0.3%sy,  0.0%ni, 99.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   2057692k total,   291352k used,  1766340k free,    27824k buffers
Swap:  4292600k total,        0k used,  4292600k free,   133052k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND           
    6 root      20   0     0    0    0 S  3.3  0.0   0:02.29 events/0
    1 root      20   0 23672 1884 1288 S  0.0  0.1   0:00.98 init
    2 root      20   0     0    0    0 S  0.0  0.0   0:00.01 kthre

確認する項目は「load average」、「Tasks」、「Cpu(s)」、「Mem」、「Swap」になります。

「load average」

Load average は単純に説明すると、処理を待っているプロセスの平均数です。 この数が多いほど、処理が滞留しているので、反応が遅くなります。
左から「直近1分」、「直近5分」、「直近15分」の平均になります。
CPUの数やサーバの状態よって異なりますが、CPU コア数で割って「1」以下が良いと考えてください。
「直近5分」、「直近15分」の値が大きい場合は、かなり処理がつまっています。
あまりに大きい値の場合 SSH でログインする処理も処理待ちの列に入りますので、ログインに異状に時間がかかったりするようになります。

「Tasks」

プロセスの数が表示されます。zombie プロセス等が異状に多かったりしないか確認します。
普段からプロセスの数を確認していないと訳に立たないかもしれません。

「Cpu(s)」

CPUの利用率になります。各項目は以下の割合を示します。

• %us:ユーザプロセス
• %sys:システムプロセス
• %ni:niceしてあるプロセス
• %id:空き
• %wa:I/O待ち
• %hi:ハードウェア割り込み要求
• %si:ソフトウェア割り込み要求
• %st:仮想プロセス

id が大きい場合は CPU が余ている状態なので問題ありませんが、他の値が大きい場合は問題になります。
wa が大きいとファイルの I/O 待ちをしている可能性が高いです。
st の値は共用のサーバ(VPS、レンタルサーバ等)で 値が大きくなると、自分意外のユーザによる負荷が影響していることになります。
最近のサーバはかなり CPU の効率が良い物が多いので、よほど変なプログラムを走らせないかぎり、wa と st 以外は大きな値にならないかと思います。
wa と st 以外が大きくなるようならば、最近入れたプログラムが異状になっている可能性が高いです。
topコマンド表示中に「P」(shift+p)を押すとCPU利用率順にソートされますので、CPUを大量に利用しているプロセスを確認します。
自分の作成したプログラムならばなんらかの改善が必要ですし、インストールしたソフトの場合は、設定のミスがないかを疑ってください。
そもそもCPUが不足している場合は、CPUの増強を考慮する必要があります。

「Mem」

メモリの利用率です。

• total:メモリの合計
• used:利用中メモリ
• free:空きメモリ
• buffers:確保メモリ

free が少ないのならば、メモリ不足になっている場合があります。
topコマンド表示中に「M」(shift+m)を押すとメモリ利用順にソートされますので、メモリを大量に利用しているプロセスを確認します。
自分の作成したプログラムならばなんらかの改善が必要ですし、インストールしたソフトの場合は、設定のミスがないかを疑ってください。
そもそもメモリが不足している場合は、メモリの増強を考慮する必要があります。

「Swap」

Swap の率です。メモリが大量に free なのに used が高い等の場合は「vm.swappiness」の値を確認すると良いです。

cat /proc/sys/vm/swappiness

データベースサーバ等はメモリを大量に積んで swappiness の値を 0 に設定してしまって良いと思います。

vmstat コマンド

I/O 関連は top コマンドだけだと原因が不明です。top の CPU(s)でどの値も高くなく、メモリもswapもたいしたことがないが、「load average」が異状に高い、という場合はほとんどの場合 I/O に問題があります。
I/O に問題があると CPU(s) の wa が高くなりそうな物ですが、CPU のコア数が多かったり、高機能だと、wa に限界がくるので、 wa が 20%以下 なのに、I/O 限界のような状況になる場合があります。
vmstat を確認してみるのが良いでしょう。

vmstat 1

以下のような出力になります。

procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 0  0      0 1770564  23700 132956    0    0 13298   215  252  907 17 43 38  2
 0  0      0 1770556  23700 132980    0    0     0     0   19   38  0  0 100  0
 0  0      0 1770556  23700 132980    0    0     0     0   18   24  0  1 99  0
 0  0      0 1770556  23700 132980    0    0     0     0   15   17  0  0 100  0
 0  0      0 1770564  23700 132980    0    0     0     0   18   20  0  1 99  0
 0  0      0 1770564  23700 132980    0    0     0    36   19   24  0  1 99  0
 0  0      0 1770564  23700 132980    0    0     0     0   21   40  0  1 99  0
 0  0      0 1770564  23700 132980    0    0     0     0   15   15  0  0 100  0
 0  0      0 1770564  23700 132980    0    0     0     0   19   17  0  1 99  0

プロセス、メモリ、swap、I/O、system、CPUの変化が1秒毎に見れます。
注目するのは「procs」で「r」が「実行中プロセス」、「b」が「ブロック中プロセス」です。
「r」の数が1以上の場合はプロセス数に対してCPUの機能が不足しています。
「b」の数が1以上の場合はほとんどの場合は「I/O待ち」です。

dstat コマンド

top と vmstat で原因が特定できる場合もありますが、それは簡単な問題の場合が多く、複雑な問題は経験に頼ることになる場合も多くなってしまいます。
dstat コマンドは、より正確にサーバ負荷関連を調査する場合は強力なツールになります。

以下のようにインストールします。

# CentOS
sudo yum install dstat
# Debian/Ubuntu
sudo apt-get install dstat

dstat の使い方は「DAG: Dstat: Versatile resource statistics tool」に説明がありますが、以下のように使います。

dstat -Tclmdrn

dstat にはプラグイン機構があるので「dstat --list」などするとプラグイン一覧が表示されます。
「--」でプラグインが複数指定できます。

dstat -tlp --disk-util --top-io --top-bio

dstat が利用できれば、サーバに関する知識があればだいたいの問題の原因は特定できると思われます。

その他のツール

その他にも以下のようなツール、コマンドがありますが、dstat があれば機能的には足りると思います。

• free -m
• ps aux
• sar(sysstat)
• iostat
• iotop

負荷対処方法

負荷の原因がわかったとして、対処をどうすれば良いかが問題になります。

• CPU負荷
• メモリ不足
• ディスクI/O負荷
• ネットワークI/O負荷

CPU負荷への対処方

CPU負荷への対処は以下になります。

• 負荷を発生させているプロセスの改善
• CPUを増強

top コマンドや dstat コマンドを利用すると CPU 負荷を発生させているプロセスを特定することは可能ですので、地道に対処するのが良いかと思います。

メモリ不足への対処方

メモリ不足への対処は以下になります。

• メモリを消費しているプロセスの改善
• メモリを増強

top コマンドや dstat コマンドを利用すると メモリを消費しているプロセスを特定することは可能ですので、地道に対処するのが良いかと思います。

ディスクI/O負荷への対処方

ディスクI/O負荷への対処は以下になります。

• 無駄なディスクI/Oを発生しているプロセスの改善
• データを書き出すディスクを物理的に分離
• RAID構成の場合はアレイコントローラのキャッシュ設定等を確認

ディスクI/Oは SSD にしてしまうなどで、速度を改善することも可能ですが、プログラムに問題がある場合も多いです。

ネットワークI/O負荷への対処方

ネットワークI/O負荷への対処は以下になります。

• 無駄なネットワークI/Oを発生しているプロセスの改善
• ネットワークカードの改善
• ネットワークカードを増設し、物理的に分離

ネットワークI/O負荷は、ほとんどの場合プログラムに問題があります。ノンブロッキングI/O等ブロックしないようなプログラムをしないと問題が発生する場合が多いです。
また Web サーバなどはサーバデーモンの設定に問題があることも多いので、設定は気をつけましょう。

まとめ

原因が判明しても、対処や検証に時間が必要な場合が多いです。基本的には地道にやるのが良いでしょう。

Mercurial(hg)で過去のコミットメッセージを修正する

過去のコミットログを修正したい場合は mq を利用して修正します。
設定ファイルで mq を有効にしておきます。

[extensions]
mq =

r 1 のログを変更したい場合は以下の手順で変更できます。
これで"change" というコメントになります。

hg qimport -r 1:tip
hg qapplied
hg qgoto 1.diff
hg qrefresh -m"change"
hg qpush -a
hg qfinish -a

mq を利用するといろいろと過去の修正はできます。

Python で入出力の文字コードが判明している場合の文字コード変換方法

Python の文字コード周りは基本に忠実で、かつ高機能です。入出力の文字コードがわかっているなら、iconv とか nkf よりも使いやすい場合も結構あります。
基本は、入力時に decode して、出力時に encode します。
decode すると Python の Unicode 型になり、この型はかなり便利。
とりあえず decode の簡単なサンプルを以下に書きましたので参考にしてみてください。

読み込みファイルは以下から取得してください。
sakito / python_sample_code / source — Bitbucket

Python の MongoDB 用 ORM の MongoEngine の簡易サンプル

Python で MongoDB を扱う場合は、「pymongo」を使えば良いですが、素のままだとそこそこ面倒なので、「MongoEngine」の簡易サンプルを書いてみました。

Python の MongoDB 用 ORM は他にも以下のような物があります。

• MongoKit
• Ming
• MongoAlchemy

一応、全部ためしてみましたが、MongoEngineはテストコードがテストとしても、サンプルとしてもかなりしっかりしており信頼できます。
あと GeoPoint とかその他複雑な機能にちゃんと対応しているのが MongoEngine ぐらいしかないみたい。
まあ結局選択の一番は個人的にかなり使いやすいと言うことですね。
ほんとうに MongoDB ちゃんと使っている人が作っている感じがします。

hgflowを試してみる

hgflow の説明と使い方は「hgflow - watawata日記」を参照。
hgflow は Fork した物の方を利用している。yujiewu / hgflow / overview — Bitbucket

curl -LO https://bitbucket.org/yujiewu/hgflow/downloads/hgflow-v0.9.2.tar.gz2
tar xvfj hgflow-v0.9.2.tar.bz2

解凍すると、hgflow.py をいうファイルができる。任意にディレクトリに配置して、${HOME}/.hgrc に以下を設定すると利用できるようになる。

[extensions]
flow = /path/to/hgflow.py

とりあえずこんな感じで動作させてみる。

hg flow init
hg flow develop
hg flow feature start spam
hg flow feature finish spam
hg flow release start 1.0
hg flow release finish 1.0

感想としては、使い易い。
場合にもよるが、git-flow の場合は feature は削除されるので、hgflow も feature は branch でなくて、bookmark の方が良いような気がする。本当は選択できるのが良いのだけど、このあたりはポリシーの問題のような気がする。