(Windows Vista)IEでサイトを表示できなくなった!

2007年6月末ごろからIEでインターネットサイトを表示できなくなった!という事象について。
原因はズバリ、Norton Internet Security 2007(以下NIS2007)。
2007年6月末のWindows Vistaの更新でIEの実行モジュールが変更されたから。
NIS2007のファイアウォールには「プログラム制御」という機能があり、この機能にてアプリ(プログラム)がインターネットにアクセスできるかどうかを制御している。
この制御のアプリの識別に実行モジュールのハッシュ値?(指紋のようなもの)を使用している。
この値は実行モジュールが変更されると変化する。
よって、IEが識別されなくなりインターネットに接続を許可していいのか判断つかなくなる。
○解決法
「プログラム制御」の”Internet Explore”(登録パスはC:Program FilesInternet Exploreiexplore.exe)の設定を一度削除して登録しなおす。登録するときは「許可する」で。

(linux) 実行ファイル実行時に参照する共有ライブラリを見つけれないときの対処

実行ファイルを実行すると
「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
で確認できる。

AIX 64bit化

AIXを64bit化する手順
1.パッケージの確認
# lslpp -L bos.64bit
# lslpp -L bos.mp64

2.リンク張替え
# ln -s /usr/lib/boot/unix_64 /unix
# ln -s /usr/lib/boot/unix_64 /usr/lib/boot/unix

3.ブートイメージ作成
# bosboot -a
4.リブート
# reboot

(AIX) Linux のように一発でアーカイブ+圧縮(tar+compress)

AIXにて Linux のように一発でアーカイブ+圧縮(tar+compress)する方法。
tarとcompressを別に行うと中間ファイルができてしまい、ディスク容量を喰ってしまい嫌だという場合に有効
・アーカイブ+圧縮
# tar cf - <アーカイブするファイル/ディレクトリ> ... | compress -c > xxxxxx.tar.Z
参考:linuxの場合
# tar zcf xxxxxx.tar.gz <アーカイブするファイル/ディレクトリ> ...

・解凍+アーカイブ展開
# zcat xxxxxx.tar.Z | tar xf -
または
# compress -dc xxxxxx.tar.Z | tar xf -
参考:linuxの場合
# tar zxf xxxxxx.tar.gz

DB2 SMSテーブルスペースチューニング

DB2のテーブルスペースのコンテナでSMSを使用する場合、Direct I/Oを使用するようにする。
理由は、Linuxカーネル(2.6)のファイルキャッシュとDB2のバッファプールが同じ働きをするから。
→要するに同じことを2回やっているので、処理時間とメモリ容量が無駄!

db2 “ALTER TABLESPACE <テーブルスペース名> NO FILE SYSTEM CACHING”

メモリーチューニング(AIX)

・現在の状態を確認

# vmstat -v
    524288 memory pages          ←実メモリページ数
   494223 lruable pages
      4115 free pages
         2 memory pools
    176832 pinned pages           ←ページアウトされない使用メモリ
      80.0 maxpin percentage
      20.0 minperm percentage     ←ファイルキャッシュの最低保持割合
      80.0 maxperm percentage     ←ファイルキャッシュの最大保持割合
      15.5 numperm percentage     ←実メモリに対するファイルキャッシュの占める割合
     76722 file pages             ←ファイルキャッシュのページ数
       0.0 compressed percentage
         0 compressed pages
      16.4 numclient percentage   ←現在のバッファキャッシュの実メモリに対する割合
      80.0 maxclient percentage   ←バッファキャッシュの最大保持割合
     81069 client pages           ←現在のバッファキャッシュのページ数
         0 remote pageouts scheduled
      9203 pending disk I/Os blocked with no pbuf
      8718 paging space I/Os blocked with no psbuf
      2740 filesystem I/Os blocked with no fsbuf
        30 client filesystem I/Os blocked with no fsbuf
         0 external pager filesystem I/Os blocked with no fsbuf

・メモリ関連のパラメータ確認

# vmo -a

・ファイルキャッシュを減らす
 明らかに、大量のファイルが何度も読み取られるがない場合 有効
 maxperm の値を減らす。
  ( maxperm > numpermの場合、ファイルキャッシュを取りにいこうとする。実メモリから移動できない実行中のメモリが大きいほど、使われてないメモリがスワップされてしまう)

# vmo -o maxperm=60 [-p]

 strict_maxperm を 1 にすると maxperm がファイルキャッシュのハード制限になる

# vmo -o strict_maxperm=1 [-p]

・バッファキャッシュを減らす
 大量ファイル読み取りによってメモリを逼迫している場合に有効
 当然、ディスクI/Oパフォーマンスは落ちる
 maxclient の値を減らす

# vmo -o maxclient=30 [-p]

・空きメモリ確保
 大きく空けるとプロセス生成時にページアウトしにくくなる。
 前もってページアウトして局所的に遅くなるのを防ぐ
 minfree ページアウト開始トリガー
 maxfree ページアウト終了

# vmo -o minfree=1000 [-p]

・プロセスごとの使用メモリ量取得

# svmon -P

DB2 ユーザデータの格納場所の移動

DB2 ユーザデータの格納場所の移動
DB2 ユーザデータの格納場所(コンテナ)の移動する方法。
DB2のリダイレクトリストア(RESTORE コマンド)機能を利用する
1.テーブルスペース・コンテナ情報取得
 テーブルスペース名とテーブルスペースIDの確認

$ db2 “LIST TABLESPACES”

 テーブルスペースIDごとに現在のコンテナパスの確認

$ db2 “LIST TABLESPACE CONTAINERS FOR <テーブルスペースID>

2.バックアップ取得

$ db2 “BACKUP DATABASE <DB名> ~(以下省略)

3.リダイレクトオプションを使用して、リストアを実行。
 ※リストアはペンディング状態になる

$ db2 “RESTORE DATABASE <DB名> FROM <バックアップイメージディレクトリパス> TAKEN AT <使用データのタイムスタンプ(YYYYMMDDhhmmss)> REDIRECT

4.リストアするデータ格納場所(コンテナパス)の変更

$ db2 “SET TABLESPACE CONTAINERS FOR <テーブルスペースID> USING (path ‘<新しいコンテナのパス>‘)”

5.リストアを再開する

$ db2 “RESTORE DATABASE <DB名> CONTINUE

空きメモリの確保の仕方(メモリーチューニング)(kernel2.6)

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

 しかし、これだけではダーティーページだけでページキャッシュは開放されない
B.最低空き容量を大きくする。
?空きメモリ容量が vm.min_free_kbytes を下回ったとき
 ページキャッシュは開放される。

  vm.min_free_kbytesの値を大きくすれば、
  ページキャッシュの総量を減らせる。

 極端な話、アプリで最大300MBメモリを使用するなら、
 この値を307200(=300MB*1024)にしておけばスワップしない(バッファキャッシュがあるぞとかスワップアウトのアルゴリズムが・・・とか細かいことは抜きして)



C.できるだけスワップさせない
?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の頃みたいに直接キャッシュサイズを指定できたらここまで悩まんでもいいのに・・・


	

DB2 テーブルスペース設計メモ

DB2のテーブルスペース設計に関するメモです。
○容量
テーブルスペースに格納する全テーブル及び全インデックスの合計容量が必要
・テーブル容量とインデックス容量の合計
・テーブル容量
1ページあたりのレコード数=(ページサイズ - ページヘッダー76バイト)/(レコード長 + レコードヘッダー10バイト)
※但しレコード数は255が最大
データ格納ページ数=(見積もり件数/1ページあたりのレコード数)*1.1
テーブル容量=データ格納ページ数*ページサイズ
※ページサイズ
4K、8K、16K、32のいずれか
・列数(項目数)
4K・・・500
それ以上・・・1024
756 列以上を表す IXF データ・ファイルをインポートすることはできません。
・レコード長
レコード長が(ページサイズ - (ページヘッダー+α))を超えてはいけない。
* 4kの場合、行の最大長は 4005 バイト。
* 8k の場合、行の最大長は 8101 バイト。
* 16k の場合、行の最大長は 16 293 バイト。
* 32k の場合、行の最大長は 32 677 バイト。
・テーブルサイズ
4K ・・・ 64GB
8K ・・・128GB
16K・・・256GB
32K・・・512GB
・インデックスサイズ
1インデックス容量=(項目長の合計+8バイト)*見積もり件数
インデックス容量=1インデックス容量+1インデックス容量+…..
・REORGするなら、さらにコピーを作成する容量が必要(テーブルスペース内の最大テーブルがもう1個入る容量)
○エクステントサイズ
* 25Mbytes未満の場合は、エクステント・サイズを8にします
* 25~250Mbytesの間の場合は、エクステント・サイズを16にします
* 250~2Gbytesの間の場合は、エクステント・サイズを32にします
* 2Gbytesを超える場合は、エクステント・サイズを64にします
OLAPデータベース、主にスキャンされる表(照会のみ)、
急速に増大する表の場合は、より大きな値を使用します。
表スペースがディスク・アレイ上(RAID)に存在する場合は、
エクステント・サイズをストライプ・サイズ(すなわち、
アレイ内の1つのディスクに書き込まれるデータのサイズ)に設定します。
○プリフェッチサイズ
・RAIDでない場合
プリフェッチ・サイズ=(複数の物理ディスク上に存在する表スペースのコンテナ数)×エクステント・サイズ
・RAIDの場合
プリフェッチ・サイズ=エクステント・サイズ×(アレイ内のパリティ・ディスク以外のディスクの数)
○その他
・マスタ系と詳細データ系に分ける(バッファプールのため)
・さらにデータ更新の種類((IMPORT/INSERT/UPDATE/DELETE) と LOAD)に分ける(トランザクションログ管理のため)
※故に最低4つあれば望ましい

ディスク使用率

コマンド

iostat -d -x 3

ビジーの基準

  • %util が 100%に近ければビジー
  • 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消費量(%)