投稿者: chidipy

実行ファイルを実行すると
「cannot open shared object file: ～ – xxxxx.so (LoadError)」
や
「relocation error: symbol not found」
と、共有ライブラリやらシンボルが見つからないと怒られるときの対処方法。この事象は、
rpmパッケージを無理矢理インストールしたときや、
どこかの製品をインストールしたとき
に発生する可能性大。
とりあえず、lddコマンドで実行するコマンドが使用する共有ライブラリ（ダイナミックリンクライブラリ）の依存関係を調べる。
# ldd /usr/local/hoge/bin/hoge
hoge1.so => /usr/local/hoge/lib/hoge1.so (0x0000008000030000)
hoge2.so => /usr/local/hoge/lib/hoge2.so (0x0000008000148000)
ここで、
・右側に表示されたライブラリのパスに該当のファイルが存在している場合
　→バージョン違いの共有ライブラリがキャッシュされている可能性（この時たぶんsymbolエラーになっているはず）
　または共有ライブラリがキャッシュされていない（この時はたぶん見つからないエラー）
　→下記の対処方法を参照
・左側に表示されたファイル名が右側のパスと異なるディレクトリにある
　→共有ライブラリのあるディレクトリがライブラリキャッシュの対象となっていない
　　→下記の対処方法を参照
・左側に表示されたファイル名のファイルがどこにもない
　→そもそも必要な共有ライブラリがインストールされていない
　（rpm -i –force で無理矢理入れたな。もしや製品の前提条件読んでないな。）
　　→先に前提条件のパッケージを入れろ！
・対処方法
　ライブラリ検索リストを確認。
　該当の共有ライブラリが存在するディレクトリが登録されていなければ登録する。
　# vi /etc/ld.so.conf
/usr/local/hoge/lib
　共有ライブラリを更新（リンク再作成・キャッシュ）
　# ldconfig
ちなみに、現在キャッシュおよびリンクされている共有ライブラリの一覧は
# ldconfig -l
で確認できる。

linux kernel2.6 での メモリーチューニングの方法。大容量物理メモリの場合、ほとんどがページキャッシュ・ファイルキャッシュ。
必要な処置
?Ａ．早めにダーティーページを掃除させる
?Ｂ．できるだけスワップさせない
?Ｃ．最低空き容量を大きくする。
?　→ファイルキャッシュがたまらない
?　　→１つのプロセス分の空きメモリを空けていれば、プロセス起動時にスワップしない。
?　　　→メモリが必要になった瞬間の、スワップによるスローダウンが防げる
Ａ．早めにダーティーページを掃除させる
?pdflushがダーティーページの掃除を行う
?　vm.dirty_ratio ＞ ダーティーページの割合 ＞ vm.dirty_background_ratio
?　のときpdflushがバックグラウンドで掃除
?　ダーティーページの割合 ＞ vm.dirty_ratio
?　のときdflushがフォワグラウンドで掃除

　なので、vm.dirty_ratio vm.dirty_background_ratioの値を小さくすれば

　こまめに掃除をし、メモリが空く可能性がある。

　（メモリが必要になったときに、一括で長時間スローダウンすることが

　　　防げる可能性がある）

　しかし、これだけではダーティーページだけでページキャッシュは開放されない

Ｂ．最低空き容量を大きくする。
?空きメモリ容量が vm.min_free_kbytes を下回ったとき

　ページキャッシュは開放される。

　 vm.min_free_kbytesの値を大きくすれば、

　　ページキャッシュの総量を減らせる。

　極端な話、アプリで最大３００ＭＢメモリを使用するなら、

　この値を307200(=300MB*1024)にしておけばスワップしない（バッファキャッシュがあるぞとかスワップアウトのアルゴリズムが・・・とか細かいことは抜きして）

Ｃ．できるだけスワップさせない
?vm.swappiness を減らせばスワップしにくくなる。

　　（何かのパーセンテージらしい・・・）

[追記]

/proc/sys/vm/drop_caches に値を放り込めば、

キャッシュが即時開放されるらしい（Kernel2.6.16 以降(CentOS5/RHEL5以降))

echo "3" >  /proc/sys/vm/drop_caches

1・・・ページキャッシュのみを解放

2・・・ダーティページとinodeキャッシュを解放

3・・・ ページキャッシュとダーティページとinode
を解放

実行前にsyncを実行したほうがいいらしい。

2はいいとして、1と3をしたら直後にパフォーマンス悪くなりそう・・・

（コマンドを実行するごとにメッセージファイルを読みにいったりしてるの知ってますか？）

kernel2.4の頃みたいに直接キャッシュサイズを指定できたらここまで悩まんでもいいのに・・・

コマンド

iostat -d -x 3

ビジーの基準

• %util　が １００％に近ければビジー
• svctm 50（ﾐﾘ秒）以上
• 平均I/O要求サイズ(avgrq-szフィールド) 平均待機時間(awaitフィールド)が高いとI/O待ちの可能性

平均サービス時間(svctmフィールド)

iostat 秒数 測定回数
avg-cpu: %user %nice %sys %idle

出力項目の説明

• AIX版 iostat

Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn

• %user—アプリケーション使用率
• %nice—
• %sys—カーネルのCPU使用率
• %idle—CPUの未使用率
• tps—
• Blk_read/s—ディスクの読み込み量(ブロック/秒)
• Blk_wrtn/s—ディスクの書き込み量 Blk_read—ディスクの読み込み総量(ブロック)
• Blk_wrtn—ディスクの書き込み総量

• linux版 iostat -xの項目説明

Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s avgrq-sz await svctm%util

• rrqm/s—秒毎にマージされた読み込み要求数
• wrqm/s—秒毎にマージされた書き込み要求数
• r/s—読み込み要求数/秒 w/s—書き込み要求数
• rsec/s—読み込みセクタ数/秒
• wsec/s—書き込みセクタ数/秒
• rkB/s—読み込み量(KB)/秒
• wkB/s—書き込み量(KB)/秒
• avgrq-sz—I/O要求の平均サイズ(セクタ)
• avgqu-sz—I/O要求の平均待ち数
• await—I/O要求の平均待ち時間(ミリ秒)
• svctm—I/O要求の平均処理時間(ミリ秒)
• %util—I/O要求におけるCPU消費量(%)