linuxでマウントできなくなった場合の対処法

サーバ起動時に特定領域がマウントできない事象に陥った。
その対処法を記録しておく。



【マウント状況の確認】
# df -TP
本来あるはずのマウントポイントがない。
下記が見えなくなっていた。
/dev/cciss/c1d0p1 ext3



【原因特定】
デバイスは存在している。
# fdisk -l
/dev/cciss/c0d0p1   *    1   25   101984   83  Linux


ファイルシステムは正常である。
# e2fsck -y /dev/cciss/c1d0p1
e2fsck 1.39 (29-May-2006)
/: clean, 157173/183091200 files, 97625776/366169796 blocks

手動で再度マウント。
失敗する。
# mount -t ext3 /dev/cciss/c1d0p1 /var
mount: wrong fs type, bad option, bad superblock on /dev/cciss/c1d0p1,
       missing codepage or other error
       In some cases useful info is found in syslog - try
       dmesg | tail  or so


起動時の状態を確認すると
ジャーナルログがないことで怒られているようである。
# dmesg | tail
VFS: Can't find ext3 filesystem on dev cciss/c1d0.
ext3: No journal on filesystem on cciss/c1d0p1
VFS: Can't find an ext2 filesystem on dev cciss/c1d0.
ext3: No journal on filesystem on cciss/c1d0p1
ext3: No journal on filesystem on cciss/c1d0p1



【ジャーナルを作成】
# tune2fs -j /dev/cciss/c1d0p1
Creating journal inode: done
This filesystem will be automatically checked every -1 mounts or
0 days, whichever comes first.  Use tune2fs -c or -i to override.

※この手段はファ入りシステムをext2からext3へ、またext3をext4へ
　変換する場合にも使える。



【マウント】
# mount -t ext3 /dev/cciss/c1d0p1 /var




参考
http://alpha-netzilla.blogspot.com/2010/12/rescue.html
http://alpha-netzilla.blogspot.com/2011/12/volume.html
http://slashdot.jp/~daikoku/journal/435744/

loadaverage(ロードアベレージ)に加算されるプロセス、スレッドの確認方法

ロードアベレージは実行中および実行待ちのプロセス、スレッドの数を集計した数値である。

サーバのリソースが許容できる数値であればいいのだが、

CPUかIOがボトルネックになり処理待ちになっているのであれば対処を検討する必要がある。

◆ 目的

①、②を特定することを目的とする。

① ボトルネックがCPUにあるにか、IOにあるのかの切り分け

② どのプロセス、スレッドが高騰させる原因を作っているのかの確認、見方の説明

◆ コマンドから現在のロードアベレージの確認

ロードアベレージを確認するコマンドは複数ある。

$ w

もしくは

$ uptime

(略)

load average: 35.58, 36.44, 34.07

ロードアベレージが35を超えているが、CPU起因か、IOに原因があるかは分からない。

※左から1分、5分、15分間の平均値で表示される。

◆ ボトルネックの確認

CPU起因か、IOが原因なのかを切り分ける。

$ vmstat

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------

 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st

 2 33    868  33356 258848 7803920    0    0     3     4    0    0  6  1 77 17  0

r: The number of processes waiting for run time.

b: The number of processes in uninterruptible sleep.

rはrun状態になっているか、run状態になる事が可能でCPU待ちの状態になっているかのどちらかである。

すべてcpu待ちにあるわけではなく、 現在running中のプロセス数も含まれることに注意が必要である。

bはdiskのI/O完了待ちになっているプロセス数である。

このシステムではIOがボトルネックになっている可能性が高い。

※当然各サーバのスペックを考慮して判断する必要がある。

ただしここからではどのプロセス、スレッドなのか確認できない。

◆ loadaverage(ロードアベレージ)に加算されるプロセス、スレッドの確認方法

psコマンドのSTATの状態から判断する。

$ ps aux -L | egrep -w "R.|D." | grep -v grep | wc -l

35

loadaverage数と合致する。

$ ps aux -L | egrep -w "R.|D." | grep -v grep 

USER     PID   LWP %CPU NLWP %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND

user   23590 12570  0.0 3046 14.9 2281140 1839224 ?     Dl   Jul24   3:01 application

user   23590 27141  0.0 3046 14.9 2281140 1839224 ?     Dl   Jul24   3:14 application

user   23590 18818  0.0 3046 14.9 2281140 1839156 ?     Dl   Jul24   2:36 application

user   23590 20815  0.0 3046 14.9 2281140 1839132 ?     Dl   Jul26   1:20 application

user   23590 10288  0.0 3045 14.8 2281140 1825828 ?     Rl   Jul24   2:03 application

user   23590  9952  0.3 3045 14.8 2281140 1825824 ?     Rl   12:15   1:01 application

(略)

D    Uninterruptible sleep (usually IO)

R    Running or runnable (on run queue)

S    Interruptible sleep (waiting for an event to complete)

T    Stopped, either by a job control signal or because it is being traced.

W    paging (not valid since the 2.6.xx kernel)

X    dead (should never be seen)

Z    Defunct ("zombie") process, terminated but not reaped by its parent.

<    high-priority (not nice to other users)

N    low-priority (nice to other users)

L    has pages locked into memory (for real-time and custom IO)

s    is a session leader

l    is multi-threaded (using CLONE_THREAD, like NPTL pthreads do)

+    is in the foreground process group

RとDはvmstatのrとbと同じ意味である。

STATがSであればサーバとしては問題ない。

◆ その他
プロセスの挙動を調べるにあたり、
pidstatやperfコマンドも有効に活用できる。

サーバ内で最低限取得すべきリソース(resource)情報

サーバのリソースを確認するためにある程度の情報はグラフ化しておくべきであろう。
だからといって、なにからなにまでグラフ表示させるのは大げさすぎる。
しかしながら、サーバにボトルネックが発生した場合には、
過去にさかのぼってシステムの状態をトレースし、原因をつきとめなければならない。

そのために、グラフ化させるまではないが、
サーバ内では定期的に細かい情報は取得しておくべきである。

自宅でのlinuxサーバでは何を取得しているかを参考までに記録しておく。

#!/bin/sh

LANG=C

TIME=`date +"%Y%m%d %H%M%S"`

DIR="/var/tmp/resource/"
HOSTNAME=`hostname`

PATH=$PATH:/usr/sbin
for CMD in "top -n 1 -b" "lsof -n" "uptime" "mpstat -P ALL 10 1" "iostat -x 10 2" "vmstat 10 2" "free" "df -P" "ps auxww -L" "netstat -an" "netstat -s" "ipcs" "w"
do

  NAME=`echo $CMD | cut -d ' ' -f 1`
  FILE=${DIR}/${HOSTNAME}_${TIME}_${NAME}.log
  $CMD >> $FILE

done

サーバ内のリソースの確認ポイントはここを参照のこと。


また、sysstatの情報もディフォルト10分から毎分に変更しておいた方がいいだろう。
# vim /etc/cron.d/sysstat
* * * * * root /usr/lib64/sa/sa1 -S DISK 1 1

起動しなくなったLinuxをレスキューモードと、シングルモードで復活手順

職場で突然あるサーバにSSHログインできなくなった。


◆ 事象
サーバにSSHログイン不可



◆ 原因
共有ライブラリ"/lib/libdl-2.5.so"が削除されたため。
ログイン時にどう使われるかは分からないが、
とにかくそのライブラリは必要だったらしい。
※そもそもなぜ消えたのかというと、同僚がオペミスしていたことが判明した。



◆ 準備するもの
・OSインストール時に利用したOSがインストールされたCD(レスキューCDとして使う)
※今回のOSはRed Hat ES 5である

・消えた"libdl-2.5.so"を保存したUSBフロッピー
　※USBフロッピーがなければUSBメモリでもなんでもいい



◆ 復旧方法
レスキューモードと、シングルモードで復旧させる

1. レスキューCDと"libdl-2.5.so"を保存したUSBフロッピーを準備

2. CDをサーバにセット、USBフロッピードライブをサーバへ接続

3. サーバの電源をOFF

4. 起動時にBIOS画面に移行(F9などを押す)
起動順としてHDDよりもCDを優先

5. boot:が表示されたら「linux rescue」と入力

6. 言語、キーボードを聞かれるのでそれぞれ「English」「jp106」を選択

7. Network設定を聞かれるが、使わないのでNo

8. マウント可能な領域が、/mnt/sysimageにマウントされるので、
/mnt/sysimage/etc/inittabの以下を書き換えてシングルブートにする
id:3:initdefault: → id:1:initdefault:

9. exitでサーバ再起動

10. 起動時にBIOS画面に移行(F9などを押す)
起動順としてCDよりHDDを優先

11. シングルブート

12. フロッピーディスクを以下のコマンドでマウント
mkdir /mnt/floppy
mount -t vfat /dev/sda /mnt/floppy

※外部ディスクを使っていれば、sdaは使われていることもありえる
その場合は、sdb、sdcなどになる

13. フロッピー内の正しい"libdl-2.5.so"を/lib/配下にmv
※cpだとsegmentation faultが発生した

14. /etc/inittabの以下を書き換えてマルチブート
id:1:initdefault:→id:3:initdefault:

15. 以下のコマンドでサーバ再起動
shutdown -r now


以上である

サーバリソース(resource)最速確認ポイント

サーバのリソースでボトルネックになっている部分を把握するためには

どこをどう確認すればいいのか。

最低限ここを見ればいいというポイントをまとめておく。

◆ ロードアベレージを確認する

$ uptime

 09:00:00 up 100 days, 00:00,  1 user,  load average: 2.61, 3.10, 3.30

ロードアベレージ数は左から1分、5分、15分間の平均値で表示される。

(参考)
loadaverage(ロードアベレージ)に加算されるプロセス、スレッドの確認方法

◆ リアルタイムにCPU、メモリの利用率とそれを利用しているプロセスを特定する

$ top

top - 09:00:00 up 100 days, 00:00,  1 user,  load average: 2.61, 3.10, 3.30

Tasks: 239 total,   2 running, 236 sleeping,   0 stopped,   1 zombie

Cpu0  :  5.2%us, 0.7%sy, 0.0%ni, 73.8%id, 20.0%wa, 0.0%hi, 0.2%si, 0.0%st

Cpu1  : 20.1%us, 1.7%sy, 0.0%ni, 54.8%id, 22.7%wa, 0.0%hi, 0.6%si, 0.0%st

Cpu2  :  2.1%us, 0.5%sy, 0.0%ni, 91.3%id,  5.9%wa, 0.0%hi, 0.1%si, 0.0%st

  PID USER  PR NI  VIRT  RES  SHR S %CPU %MEM  TIME+ COMMAND

26258 user1 17  0 2237m 1.7g 6632 R 25.9 16.9 527:37 cmd1

19166 user2 16  0 2357m 1.7g 6664 S 23.6 17.5 574:20 cmd2

"1"を押すと全プロセッサ(CPU)が表示される。

"shift+p"で%CPU行でソートできる。

"shift+m"で%MEM行でソートできる。

(参考)
topコマンドの少し詳しい使い方

プロセス状態を表すS行にも注目すること。

タスクの状態は以下のいずれかである。

"D" = 割り込み不可能なスリープ状態

"R" = 実行中

"S" = スリープ状態

"T" = トレース中/停止された

"Z" = ゾンビ

"D"の状態が続く場合は要注意である。

プロセスがIO処理待ち状態になっている可能性がある。

◆ CPUのステータスを確認する。

$ mpstat -P ALL

09:00:00 CPU %user %nice %sys %iowait %irq %soft %steal %idle intr/s

09:00:00 all  5.39  0.00 0.90   10.58 0.01  0.22   0.00 82.91 533.08

09:00:00   0  5.24  0.01 0.74   19.98 0.00  0.18   0.00 73.84 246.11

09:00:00   1 20.14  0.00 1.74   22.70 0.04  0.59   0.00 54.78 266.01

09:00:00   2  2.14  0.01 0.50    5.91 0.00  0.13   0.00 91.32 174.10

あわせて、iowaitも注目して見ておくこと。

iowaitは、CPUがアイドル状態で、システムに未処理のディスク入出力要求が

あった時間の割合を意味する。

一点注意が必要である。

ネットーワークI/O待ちはiowaitではなく、idle扱いになる。

また下記の計算式が成り立つ。

%user + %sys + % iowait + %idle = 100%

◆ IOのステータスを確認する

$ iostat -x 10

avg-cpu:  %user   %nice    %sys %iowait   %idle

          20.31    0.00    7.93    1.19   70.57

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

sda       0.60  76.60 0.10 3.00   5.63  58.59   2.81 29.30     4.90    0.00  0.09 0.00  0.00

sda1      0.00   0.00 0.00 0.00   0.00   0.01   0.00  0.00     2.84    0.00  1.43 0.97  0.00

sda2      0.19   0.47 0.02 0.05   1.72   4.21   0.86  2.10    78.66    0.00 19.98 3.98  0.03

２つのIOレスポンス値に注目する。

await：デバイスへのIOリクエストの平均待ち時間(ms)。キューにいる時間＋処理時間

svctm：デバイスへのIOリクエストの平均処理時間(ms)

※当然awaitの方が大きな値になる。

IOPS(秒間のIOリクエスト数)にも注目する。

IOPS = r/s + w/s である。

◆ swapの発生状況を確認する。

$ vmstat 10

procs -----------memory---------- -swap- --io-- --system- -----cpu------

 r  b   swpd   free   buff  cache  si so bi bo  in cs     us sy id wa s

 2  2      0  36808 434172 5436128  0  0  1  6 112 52      5  1 83 11 0

swapが使われていることを確認するのではない。

頻繁にディスクからスワップイン(si)、またディスクにスワップアウト(so)しているかどうかを確認する。

swapとは何かについてこちらにまとめている。

inは割り込み回数である。

vmstatでは割り込みの合計回数しか確認できないが、/proc/interrupts から

内訳を確認することが可能である。

csはコンテキストスイッチの回数である。

csが数千の水準になっていれば、カーネル内部の処理オーバーヘッドが大きくなるはずである。usは小さいのに、syが増えるといった状況だ。

ただし、CPUコアあたりの数値なので、多数のコアを搭載しているマシンでは、例えば16コアだと10万程度までいくことはある。

◆ メモリの状況を確認する

$ free

             total         used        free    shared     buffers      cached

Mem:      10259640 A   10230080 B     29560 C       0 D    435368 E   5440144 F

-/+ buffers/cache:      4354568 G   5905072 H

Swap:     13109032 I        488 J  13108544 K

A = B + C

H = C + D + E + F

G = B - D - E - F

I = J + K

◆ プロセスごとのリソース消費を確認する

プロセスごとに利用しているリソースを確認するにはpidstatが便利である。
pidstat自体はsysstatの機能なので、負荷はsysstatと同じでほぼかからない。

$ pidstat -u -p <PID> 1 3600　　※1 3600は1秒間隔で3600回

$ pidstat -w -p <PID> 1 3600

$ pidstat -r -p <PID> 1 3600

-u: Report CPU utilization.
-w: Report task switching activity 
-r: Report page faults and memory utilization
-p: pid(pid is the process identification number)


どのシステムコールがどれくらい来ているのかを知るためにperfコマンドも使えるだろうか。

【参考】
linux サーバ内で最低限取得すべきリソース情報