- ボトルネック箇所の推定
- 負荷の高いプロセスを特定するには
- メモリ使用率の算出
- インターフェースのオートネゴシエーション設定
- /dev/nullを削除してしまった
- 待機系DISKからの起動
- シリアル接続したコンソールの画面に表示されない
- okプロンプトから bootを実行するとnet bootする
- クラッシュダンプの採取方法
- break信号の無効化
- ブレーク信号が無効化された場合でのクラッシュダンプの採取
- GUI の無効化
ボトルネック箇所の推定
$ vmstat 2
procs memory page disk faults cpu
r b w swap free re mf pi po fr de sr s0 s3 -- -- in sy cs us sy id
0 0 26 2049760 206176 13 53 22 19 20 0 16 3 0 0 0 150 234 180 6 12 82
0 0 27 2035024 219848 0 3 0 0 0 0 0 2 0 0 0 2769 980 412 5 29 65
0 0 27 2036224 220664 1 1 0 0 0 0 0 4 0 0 0 2582 1190 452 1 28 71
0 0 27 2036224 220304 0 0 4 0 0 0 0 2 0 0 0 2320 1292 476 4 27 69
| r | CPU のリソース不足で生成できなかったプロセス数 |
| b | ディスクI/O のボトルネックにより生成できなかったプロセス数 |
| w | swap に追いやられて、その後呼び戻されないプロセス数（使用されてないから？） |
SolarisではCPU使用率を調べるコマンドとしてsar が用意されてるので、sar の出力結果についても併せて説明します。
■sar コマンドによるCPU使用率
% sar 5 5 SunOS sweety 5.9 Generic_118558-35 sun4us 06/12/2007 13:19:29 %usr %sys %wio %idle 13:19:34 0 0 0 100 13:19:39 0 0 0 100 13:19:44 0 0 0 100 13:19:49 0 0 0 100 13:19:54 0 2 0 98 Average 0 0 0 100
通常、「%usr」+「%sys」の値が常に高いとCPUがボトルネックになっている可能性が高いです。
しかし、マルチCPU構成ではCPU使用率が高くなくても特定のCPUに負荷が集中している可能性があるので mpstatで確認します。
※squidはデフォルトではマルチCPUに対応してない。マルチCPUに対応させるにはconfigureオプションで指定する（？）
■mpstat によるCPU使用率
% mpstat 5
CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl
0 78 0 41 303 202 312 0 20 8 0 337 0 0 0 100
1 128 0 28 4 1 262 1 21 9 0 301 0 0 0 99
CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl
0 98 0 39 306 206 331 0 19 12 0 455 0 0 0 100
1 133 0 25 4 1 276 1 19 8 0 285 0 0 0 100
mpstatの場合も、「usr」、「sys」、「wt」、「idl」がsarの結果に相当します。
負荷の高いプロセスを特定するには
■Solaris7以降
prstatで確認
% prstat -a
PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP
11787 root 6032K 4544K cpu1 59 0 0:00:00 0.0% prstat/1
556 root 56M 25M sleep 59 0 1:12:14 0.0% java/24
489 root 1080K 752K sleep 59 0 0:00:00 0.0% utmpd/1
25553 root 14M 4904K sleep 59 0 0:01:07 0.0% imsssysmon/2
528 root 3488K 2280K sleep 59 0 0:00:00 0.0% htt_server/2
248 root 3888K 1984K sleep 59 0 0:00:06 0.0% syslogd/14
参考）RSSはプロセスのイメージサイズ
シェアードメモリ（プロセス間で共有できるメモリ）を含んだ値をレポートするため合計すると実メモリよりも大きくなる場合がある。
■Solaris2.6
prstatは含まれてないのでBSD系のpsコマンド(/usr/ucb/ps)で確認
% /usr/ucb/ps auwx
USER PID %CPU %MEM SZ RSS TT S START TIME COMMAND
root 3 0.3 0.0 0 0 ? S 3月 27 230:52 fsflush
root 9792 0.1 0.1 1352 872 pts/5 O 15:58:28 0:00 /usr/ucb/ps auwx
メモリ使用率の算出
メモリ使用率の計算式を以下に示します。
計算式
（ 実メモリ[byte] - 空きメモリ[byte] ） / 実メモリ[byte] x 100 = (%)
■実メモリのサイズ （Mbyte = 1024 kbyte × 1024 byte）
% prtconf|grep Memory Memory size: 2048 Megabytes
■空きメモリのサイズ（byte）
sar -r でメモリの空き要領を確認（ページ数単位で表示される）
% sar -r 5 5
SunOS sweety 5.9 Generic_118558-35 sun4us 06/12/2007
14:09:07 freemem freeswap
14:09:12 150747 3352926
14:09:17 150747 3352926
14:09:22 151006 3359158
14:09:27 151299 3365772
14:09:32 150996 3359040
Average 150958 3357957
上記のfreememの値にページサイズ(8192 byte)を掛けた値が空きメモリ（byte）になります。
% pagesize 8192
インターフェースのオートネゴシエーション設定
- 【事象】
- OSリブート後にeri0インタフェースがリンクアップしない。
- 【原因と対処方法】
- オートネゴシエーション設定（adv_autoneg_cap）は最後に実行する必要があります。
以下、eri0 を 10Mbps 半二重固定にする設定です。
#!/bin/sh /usr/sbin/ndd -set /dev/eri instance 0 /usr/sbin/ndd -set /dev/eri adv_autoneg_cap 0 /usr/sbin/ndd -set /dev/eri adv_100fdx_cap 0 /usr/sbin/ndd -set /dev/eri adv_100hdx_cap 0 /usr/sbin/ndd -set /dev/eri adv_10fdx_cap 0 /usr/sbin/ndd -set /dev/eri adv_10hdx_cap 1
#!/bin/sh
/usr/sbin/ndd -set /dev/eri instance 0
/usr/sbin/ndd -set /dev/eri adv_100fdx_cap 0
/usr/sbin/ndd -set /dev/eri adv_100hdx_cap 0
/usr/sbin/ndd -set /dev/eri adv_10fdx_cap 0
/usr/sbin/ndd -set /dev/eri adv_10hdx_cap 1
/usr/sbin/ndd -set /dev/eri adv_autoneg_cap 0 ←最後に指定
なお、対向機器とリンク速度が合っていない場合、リンクはアップするがコリジョンが多発してレスポンスが極端に悪化する。
/dev/nullを削除してしまった
devfsadm を使って /dev と /devices を再構成
# devfsadm -C
待機系DISKからの起動
OBP(PROM)モードで待機系DISKのディスクの物理デバイス名を指定
例) ok boot /pci@17,4000/scsi@3/sd@1,0 <-待機系ディスクの物理デバイス名
起動できない場合は物理デバイス名の"sd"を"disk"に変更する。実行環境により"ssd"であることもある。
起動できたことが確認できたら再びOKプロンプトにしてエイリアス登録する
<ディスクのデバイスエイリアス登録> ---------------------------- okプロンプトから devalias disk2 /pci@1f,0/pci@1/scsi@1,1/sd@2,0
参考） <ブートデバイス名の確認> ----------------------------- ok printenv boot-device boot-device = disk ok boot
シリアル接続したコンソールの画面に表示されない
eepromのパラメータで output-device=screen input-device=keyboard
上記設定だと、OS起動後、CRT装置、キーボード装置に制御が移りシリアルコンソールが接続できないため、ttya"に変更
# eeprom input-device=ttya # eeprom output-device=ttya (確認方法) # eeprom input-device output-device
コンソールデバイスの設定反映を行う為にはリブートが必要です。
okプロンプトから bootを実行するとnet bootする
OBP の設定によって発生しうる事象です。
eeprom コマンドの結果から OBP の設定を確認します。
# eeprom | grep diag diag-retry=off diag-level=min diag-file: data not available. diag-device=disk diag-switch?=false
diag-switch が true の場合、システム再起動時に diag(システム診断モード)を走らせます。 そのとき、diag-device=net(デフォルト設定)の場合、ネットワークに接続されたブートデバイス を探しそこから起動を試みますが、そのネットワーク上のブートデバイスが見つからなかったときに、 以下のメッセージが出力され、起動が出来なくなってしまいます。
Timeout waiting for arp/rarp packet
この現象を回避させるには以下のように diag-switch を false に変更すれば回避可能です。
【solaris上での変更】
# eeprom diag-switch?=false
【OBPでの変更】
ok setenv diag-switch? false
クラッシュダンプの採取方法
デフォルトでは、/var/crash/hostname 配下に保存されます。
クラッシュダンプの取得方法は 2種類あります。
1. システムがハングしていない場合
2. システムがハングしている場合
【システムがハングしていない場合】
savecore コマンドのオプションに L を使用することでクラッシュダンプが取得できます。
以下はコマンドの実行例です。
# savecore -L
このコマンドを使用する場合には専用のダンプデバイスが必要となります。
【システムがハングしている場合】
システムがハングしている場合には、ok プロンプトにする必要があります。
以下は、ok プロンプトにする方法・クラッシュダンプを取得する方法です。
1. ok プロンプトにします。
stop + a を実行し、ok プロンプトにします。
又は
キーボードのケーブルを抜き差しし、okプロンプトにします。
2. ok プロンプトにて、sync コマンドを実行し、クラッシュダンプを取得します。
ok sync
補足 [ ダンプデバイスについて ]
ダンプデバイスとは、クラッシュファイルを一時的に保存をする領域になります。
デフォルトでは swap 領域になっていますのが、swap 領域を使用することは推奨いたしませんので別の領域をダンプデバイスとして
構成して下さい。
以下にダンプデバイスの変更方法を記載します。
1. 現在、どの領域がダンプデバイスになっているか確認します。
# dumpadm
出力例
# dumpadm Dump content: kernel pages Dump device: /dev/dsk/c0t0d0s1 (swap) Savecore directory: /var/crash/ultra5 Savecore enabled: はい
出力結果の 「 Dump device 」が swap になっている場合には変更します。
2. ダンプデバイスの領域を変更します。
# dumpadm -d /dev/dsk/c0t0d0s3
3. 正常に変更がされているか確認します。
# dumpadm
出力例
# dumpadm Dump content: kernel pages Dump device: /dev/dsk/c0t0d0s3 (dedicated) Savecore directory: /var/crash/ultra5 Savecore enabled: はい
swap と表示されていた部分が dedicated と表示されれば正常に変更されたことになります。
break信号の無効化
ノートPCをコンソール端末として、シリアルのケーブルをサーバに繋いだまま電源ON/OFFすると、
サーバにbreak（ブレーク）信号が流れ、サーバがOBPモードに落ちてしまいます。
ここではbreak 信号を無効にする手順を示します。
break 信号を有効/無効にするには以下の2種類があります。
【コマンドラインから設定する方法】
# kbd -a disable <-break 信号を無効 # kbd -a enable <-break 信号を有効
【起動時にbreak 信号を無効にする方法】
1. /etc/default/kbd を編集します。
# vi /etc/default/kbd
(行数)
22 # Uncomment the following line to disable keyboard or serial device
23 # abort sequences:
24 KEYBOARD_ABORT=disable ★行頭の # を外します
25
26 # Uncomment the following line to enable a non-BREAK alternate
27 # serial input device abort sequence:
28 #KEYBOARD_ABORT=alternate
2. 変更をカーネルに反映させます。
# kbd -i
3. 反映された事を確認します。
# echo 'abort_enable/D' | adb -k
physmem 1ef8e
abort_enable:
abort_enable: 0
^ ★
0 disable (無効化)
1 enable (有効化、デフォルト)
2 alternate (代替ブレークシーケンスの有効化)
ブレーク信号が無効化された場合でのクラッシュダンプの採取
KEYBOARD_ABORT=disable 状態においてシステムハングが発生した場合、send break -> sync でダンプを採取する事が出来ません。
次の様に対処を行って下さい。
コンソール接続後、#. で lom> プロンプトにエスケープさせた後、
lom> reset -x
と実行する事で ok プロンプトに割り込みがかかります。その後、sync を投入する事によりダンプが採取出来ます。
また、alternate と設定する事で、reset -x を投入しなくても通常の send break は無効としつつ、代替のブレークシーケンスを投入す
る事で ok プロンプトに割り込む事が出来ます。
一般的なシリアルポートに直接コンソール端末を接続した構成では
return -> tilde -> control-B
と投入する事で代替ブレークシーケンスを送る事が出来ますが、V120 + LOM の構成でも問題なく同じ手
順で送れるかどうかを確認中です。
この確認が終りましたら、disable ではなく alternate に変更します。
※ break に関する詳細は kbd(1) , asy(7D) のオンラインマニュアルを参照して下さい。
GUI の無効化
サーバー用途で使用していて、GUI でログインすることがない場合は GUI は必要ないので無効にします。
# /usr/dt/bin/dtconfig -e 無効にします 完了しました。 デスクトップの自動起動を使用可能にしました。 # init 6 再起動後、GUI ログインの画面は出力されません
GUI を有効に戻すには以下のコマンドを実行します。
# /usr/dt/bin/dtconfig -d 完了しました。 デスクトップの自動起動を使用不可にしました。
メールサーバ