Linux サーバ起動時にFSCKが実行されて、サーバの起動に時間がかかる

Linuxでは、サーバ起動時にディスク(ファイルシステム)のFSCKを実行、その後ディスク(デバイス)をマウントして起動プロセスへ移っていくようになっています。

FSCKの実行時間は、ディスク(デバイス)の容量に依存するため、ディスク(デバイス)容量が大きい(1TB等)場合は留意する必要があります。
サーバ起動時間がFSCKの実行有無で大幅に変わることが想定されます。
そのため、サーバの起動に時間がかかっている場合は、FSCKの実行有無が影響している可能性があります。

FSCKが実行される契機は、以下です。
  1.ディスク(デバイス)のマウント回数
  2.ディスク(デバイス)へFSCKを実行してから経過した時間

設定情報内容は、以下のコマンドで確認できます。
  tune2fs△-l△[デバイス名]
  ※例  tune2fs△-l△/dev/sda1

tune2fs で表示した結果で以下がFSCKに関連があります。

  Mount count: 10  ←ディスク(デバイス)がマウントされた回数
  Maximum mount count: 30  ←Monut countがこの値になるとFSCKが実行される
  Last checked: Sun Jan 01 09:00:00 2017  ←前回FSCKが実行された日時
  Check interval: 15552000 (6 months)  ←前回から次回のFSCKが実行されるまでの間隔(秒)

上記の場合、次回のFSCKが実行されるタイミングは以下になります。
  1.ディスクがあと20回マウントされた場合
    ※Maximum mount count(30) - Mount count(10)

  2.2017年6月30日9時
    ※Last checked(2017年1月1日9時) + Check interval(6ヶ月:15552000秒)
    ※ただし、1のマウント回数によりFSCKが先に実行された場合は、その日時から6ヶ月(15552000秒)後に変更されます。

FSCKの実行設定は、tune2fs で変更できます。
  オプション  -c  …  Maximum mount count を変更 (0 または -1 を設定すると、FSCKが実行されなくなります)
  オプション  -i  …  Check interval を変更 (0 を設定すると、FSCKが実行されなくなります)

複数のディスク(デバイス)をマウントしている場合は、ディスク(デバイス)毎にFSCKが実行されるタイミングを変え、全てのディスクが一斉にFSCKが実行されないようにして、サーバの起動にかかる時間を工夫(コントロール)した方がよいと思います。
マウント回数(Maximum mount count)か間隔(Check interval)のどちらかだけを設定するとコントロールし易いと思います。

ご指摘、ご質問などはコメントへお願いします。

Linux よく使うコマンド

保守や運用の仕事をする上で、知っておくべき(と個人的に思う)コマンドをまとめてみました。
(思いついたら追記します)

・ネットワーク疎通確認、経路確認

    ping

    traceroute

・全プロセス情報を表示

    ps
    オプション auxwwf (ツリーで表示)

    オプション -ef (PID、PPIDを表示)

    ※例  プロセスを探すとき(ヘッダが無いと見辛い)

      ps△-ef | head△-1; ps△-ef | grep△[探したいプロセス名] | grep△-v△grep

 ・時刻を表示

    date

    ※Linux時間で記録されている時間(auditログ等)を表示

      date△--date=@[Linux時間]

・OSの情報をまとめて収集

    sosreport

 ・ファイルやディレクトリをアーカイブ(又は展開)

    tar

    ※アーカイブして圧縮(bz2形式)

      tar△cfj△[アーカイブ後のファイル名].tar.bz2△[アーカイブしたいファイル1]△[アーカイブしたいファイル2]

    ※アーカイブして圧縮(bz2形式)したファイルを展開
tar△xfj△[アーカイブしたファイル名].tar.bz2

  ・稼働情報の確認
    sar

  ・ファイルの参照
    less

  ・プロセスや稼働情報をリアルタイムで確認
    top
    ※オプションでバッチとして実行することも可

ご指摘、ご質問などはコメントへお願いします。

Linux sosreportで情報収集してエラーの原因究明に役立てる

Linuxでエラーなどが発生したときに情報収集する場合は、sosreportコマンドが便利です。
何か問題が発生した際は、ひとまずsosreportを実行しておくと、役に立ちます。

sosreportはパッケージの導入が必要なコマンドです。

sosreportコマンドの実行には、root権限が必要です。

sosreportでは、
  ・パッケージの導入状況
  ・/etc配下の設定ファイル
  ・サービス設定(chkconfig)
  ・コマンド実行時の状況(df、ps、netstat、freeコマンド)
  ・/var配下のログ(ファイル)
  ・コマンド実行時のカーネルパラメータ(/proc)
などの情報を集め、アーカイブ(圧縮)としてファイルが作成されます。

sosreportコマンドは通常 対話式ですが、オプション(--batch)を指定することでバッチ(非対話式)に変更出来ます。非対話式にすることで、シェルスクリプトへ組み込めます。

また、ファイルの出力先は、デフォルトで/tmp(または/var/tmp)ですが、オプション(--tmp-dir)を指定することで出力先を変更出来ます。出力先の空き容量が不足すると失敗する(ハングする可能性もあります)ので、注意が必要です。

コマンド例) シェルスクリプトに組み込み、出力先のディレクトリを変更する場合
  sosreport△--batch△--tmp-dir△[出力先のディレクトリ]

sosreportコマンドはシェルスクリプトのため、オプションや動作は直接ファイルの内容を確認することが出来ます。

ご指摘、ご質問などはコメントへお願いします。

Windows Linux 任意のサイズを指定してファイルを作成する

テスト等である程度のサイズのファイルを作成したい際、コマンドでファイルを作成できます。特に大きいサイズのファイルを作成する際は、以下のコマンドが非常に便利です。

Windowsの場合は、コマンドプロンプトからfsutilコマンドを使います。
  fsutil△file△createnew△[ファイル名]△[ファイルサイズ]

例えば、C:¥temp フォルダの中にサイズ 1024byteでファイル名 1k.txtを作成する場合
  fsutil△file△createnew△C:¥temp¥1k.txt△1024

Linux の場合は、ddコマンドを使います。
  dd△if=[ファイルを作るまての元データ]△of=[作成するファイル名]△bs=[bytes]△count=[blocks]

例えば、/tmpディレクトリの下にサイズ 1024byteでファイル名 1k.txtを作成する場合
※ファイルの中身はランダムなデータ(/dev/urandom)
  dd△if=/dev/urandom△of=/tmp/1k.txt△bs=1024△count=1
  ※bs × count のサイズでファイルが作成されます。そのため、上記例の場合は、bs=1、count=1024 としても同じサイズのファイルが作成出来ます。

また、Linux の場合はアンパサンド(&)を付ければ、バックグラウンドで処理することが出来ます。
例えば、/tmpの下に1MBのファイルを3つ(1m1.txt、1m2.txt、1m3txt)を作成する場合は、
  dd△if=/dev/urandom△of=/tmp/1m1.txt△bs=1024△count=1024△&
  dd△if=/dev/urandom△of=/tmp/1m2.txt△bs=1024△count=1024△&
  dd△if=/dev/urandom△of=/tmp/1m3.txt△bs=1024△count=1024△&
を実行することで各コマンド終了を待たずに、他の作業をすることが出来ます。
バックグラウンド処理の終了状況はjobs コマンドで確認できます。


ご指摘、ご質問などはコメントへお願いします。

Linux ディスク使用量とブロックサイズについて

Linuxのファイルとディレクトリの、サイズやディスク使用量を取得する主なコマンドとして、

    df コマンド

    du コマンド

    ls コマンド(-l オプション)

があります。

ディスク使用量とは、実際にディスクへ割り当てられた大きさを意味しています。

ディスクはブロックサイズ毎に割り当てられるため、ディスク使用量は最低でも必ずブロックサイズと同じになります。

つまり、ブロックサイズが4kの場合、どんなに小さなファイルを作っても、ディスク使用量は必ず4kになります。
また、どのような大きさのファイルを作成しても、必ず4kで割り切れるディスク使用量になります。

各ディスクのブロックサイズは、コマンドで変更が出来ます。

ブロックサイズを大きくした場合、
    メリット…ディスクへの書き込み速度が向上する
      ※ブロックサイズ単位で(ディスク容量が割り当てられて)ディスクへ書き込みが実行されるため
    デメリット…作成できるファイル(ディレクトリも)が少なくなる
      ※ブロックサイズ単位でディスク容量が割り当てられるため

ブロックサイズを小さくした場合、(大きくした場合の逆ですが)
    メリット…作成できるファイル(ディレクトリも)が多くなる
    デメリット…ディスクへの書き込み速度が低下する

あらかじめ、主にサイズが大きいファイルの数が多いことが見込まれる場合は、ブロックサイズを調節すると、パフォーマンスの向上を期待できます。
ただし、本来あまりディスク容量を必要としないファイル(小さなファイルやディレクトリ)を作成した場合もブロックサイズ分のディスク容量が割り当てられてしまうので、留意が必要です。

ディスクへの書き込み速度が影響するのは、ブロックサイズ以上のファイルを作成した場合です。
また、ディスクへ作成できるファイル(ディレクトリ)の数は、i-node数を越えることは出来ません。

ご指摘、ご質問などはコメントへお願いします。

HULFT ジョブ定義の入力制限、標準出力、環境変数について

以下の話は、HULFTのバージョン 7、8です。

●ジョブ定義の入力制限

HULFTのジョブ定義では60バイトの入力制限があります。
コマンドのフルパス、標準出力やエラー出力を制御すると、制限に引っかかることが多いです。

以下のように環境変数(PATH)を設定することで、コマンドのパスの分だけ、バイト数を減らすことができます。

《Linuxの場合》
/etc/profileで、環境変数PATHにコマンドのパスを設定
(HULFTでは基本的にrootで各処理が実行されます。)

《Windowsの場合》
システム環境変数で、環境変数PATHにコマンドのパスを設定

●HULFTの環境変数
HULFTではファイルID($FILEID)等のHULFT固有の環境変数を使うことが出来ます。

《Linuxの場合》

ジョブ定義の中でsudoコマンドを使ってコマンドの実行ユーザを変える場合、変更したユーザにはHULFTの環境変数が引き継がれないため、/etc/sudoresのenv_keepで引き継ぎたい変数名を定義する必要があります。

●ジョブ定義の標準出力と標準エラー出力

ジョブ定義のコマンドの標準出力と標準エラー出力は、HULFTで厳密に制御されていないようです。

《Linuxの場合》
そのため、出来るだけ制御(どこかに出力しておく、又は/dev/nullに出力(捨てる))した方が好ましいです。
ジョブ定義で出力を制御しなかった場合、経験だと、HULFTデーモンを起動した際に指定した出力先へ出る模様です。

例えば、集信デーモンを以下コマンドで起動した場合、ジョブ定義で出力を制御していない集信ジョブの標準出力はstdo.log、標準エラー出力はstde.logへ出力されます。

  hulrcvd >stdo.log 2>stde.log

ご指摘、ご質問などはコメントへお願いします。

Linux initプロセスとrc.dディレクトリ

ランレベル変更時に、initプロセス( uid=0 )により諸々(/etc/inittabに記載されている内容)が実行されます。

inittab には、各ランレベルに対する rc.d ディレクトリ(配下のスクリプト)の実行やキーボード操作の制御等が記載されています。

ランレベルが0のときは /etc/rc0.d 配下のスクリプトを実行 、ランレベルが1のときは rc1.d 配下のスクリプトを実行、等です。

/etc/rcX.d(X は0から6までの数字)配下のスクリプトは、/etc/init.d 配下のスクリプトのシンボリックリンクとなっています。
また、rcX.d 配下のスクリプト(リンク)の名前は、S 又は K 、2桁の数字で始まります。
S は起動するプロセス、K は停止するプロセスを表し、2桁の数字は実行順序(小さい数字→大きい数字 の順)を表しています。

例えば以下が /etc/rc5.d 配下に存在する場合、ランレベルを5に変更した際に、nfsdの停止、httpdとtestdの起動(httpd、testdの順)が実行されます。

  K95nfsd    S80httpd    S99testd

サーバを起動する場合は、/etc/inittab で default に設定されているランレベルでinitプロセスが実行されます。

init コマンドや runlevel コマンドでランレベルを変更することが出来ます。

ご指摘、ご質問などはコメントへお願いします。

HULFT 必要最低限の定義(設定)について

以下の話は、HULFTのバージョン 7、8です。

 HULFTで集信、配信、要求受付の際に定義(設定)が必要です。

集信の場合
    最低限だと集信管理情報、転送グループ情報と詳細ホスト情報が必要です。
    集信管理情報でジョブを指定している場合はジョブ情報の定義も必要になります。

配信の場合
    最低限だと配信管理情報、転送グループ情報、詳細ホスト情報、/etc/hostsの定義が必要です。
    配信管理情報でジョブを指定している場合はジョブ情報の定義も必要になります。

 要求受付の場合
    必要な定義は配信の場合と同様です。

集信、配信、要求受付には、それぞれデーモン(utlrcvd、utlsndd、utlobsd)の起動が必要です。

 ご指摘、ご質問などはコメントへお願いします。

HULFT 改行コード、文字コードの変換について

以下の話は、HULFTのバージョン 7、8です。

配信定義で、改行コードや文字コード、フォーマットを変換することが出来ます。

配信定義の転送タイプでバイナリ転送以外を指定した場合、コード変換で無変換を指定しても、配信元と集信先で情報ホスト情報を元に改行コードの変換が実行されます。

例えば、
    配信元の詳細ホスト情報のホスト種をUNIX
    集信先の詳細ホスト情報のホスト種をWindowsNT    で定義した場合、
    転送ファイルは改行コードはLFからCRLFへ変換されます。

そのため、コード変換(改行コードと文字コードの変換)を行いたくない場合は、転送タイプをバイナリ転送に指定する必要があります。

文字コードを変換(Shift-JISからUTF-8へ変換等)したい場合は、コード変換を配信側変換又は集信側変換を指定します。
変換する文字コードは、情報ホスト情報の漢字コード種類で指定します。

コード変換の指定により、変換処理のタイミング(配信側、集信側)を変えられます。
そのため、変換処理のタイミング(コード変換を配信側で処理するのか、それとも集信側で処理するのか)は、サーバのスペックや処理効率を考慮して決められます。

ご指摘、ご質問などはコメントへお願いします。

Linux パイプでの並行処理、戻り値について

コマンドの実行結果をもう１つのコマンドの引数として渡すために、パイプ( | )をよく使います。

例えば、実行中の全プロセスを表示(ps -ef)した結果から、単語(nfsd)のみを抽出(grep)する場合は、以下のコマンドを実行します。
    ps -ef | grep nfsd

パイプの使い方として、上記のように引数を渡すためではなく、(パイプの右側のコマンドが引数を必要としない場合に限りますが)並列処理を実行させることができます。

例えば、2つのシェルスクリプト(test1.shとtest2.sh)を並列(同時)に実行する場合は以下のように実行すします。

    time ./test1.sh | time ./test2.sh

いくつのコマンドまで並列処理で実行して処理が速くなるかはコア数にも依りますが、大概の場合は速くなります。

パイプを使った場合に取得できるコマンドの戻り値は、パイプの一番右のコマンドの戻り値のみとなります。そのため、(パイプを使うことを想定した際の一番右以外の)コマンドでエラーハンドリングしたい場合は、パイプが使えません。

パイプは非常に便利ですが、使い方次第です。

ご指摘、ご質問などはコメントへお願いします。

Linux initプロセスのuidについて

LDAPのユーザは除く各ユーザの uid は、/etc/passwd ファイルで確認できます。
また、ユーザでログイン後の id コマンドで確認することもできます(LDAPも確認可)。

上記の方法で確認できない init の uid は『0』です。

また、/etc/passwd で root の uid は『0』に設定されています。

そのため、init プロセス中に起動されたプロセス群は init ( uid が 0 ) が親プロセスとなりますが、ps コマンドで表示した場合、uid が 0 のユーザが root のため、root と表示されます。

(ps コマンドで uid での表示を指定しない場合、ユーザ名が表示されます)

ご指摘、ご質問などはコメントへお願いします。

Linux uidの重複でのオーナー表示、パスワード変更について

Linuxでは、ユーザを作成するとユーザ毎に uid が割り当てられますが、作成時にuid を指定することが出来ます。

uid 指定時に、既に割り当てられている uid と同じ uid を指定して、uid が同一のユーザを作成することも出来ます。

ユーザ作成後にusermodコマンドでuidを変更することが出来ますが、既に作成されているuidへ変更(指定)することは出来ません。そのため、uidの重複したユーザを作成するには、作成時にuidを指定する方法のみです。

その場合、uid が重複したユーザが複数になるため、ls コマンドでオーナーを表示した際に、どちらか一方のユーザ(/etc/passwd ファイルの上に位置しているユーザ)が表示されます。

nscd(起動の有無、/etc/nscd.conf)の関係で、uid が重複しているユーザについて、表示されるオーナーが変わることがあります。
経験ですが、nscd.conf で、auto-propagateをnoに設定することで表示が変わります。なお、デフォルトではauto-propagateはyesです。

また、uid が重複しているどちらか一方のユーザでパスワードを変更した場合、もう一方のユーザのパスワードも変更されますので、注意が必要です。

ご指摘、ご質問などはコメントへお願いします。

Linux メモリのコマンド、cached、buffers、書き込みについて

現在のメモリ(memory)の使用量は、free、top 、vmstat コマンドや/proc/meminfo を参照することで確認できます。

また、sar コマンドでは現在の値や過去(デフォルト10分毎)の情報を確認できます。

メモリは、高速に読み書きできるようにキャッシュとして使われます。

そのため、メモリ使用量を表示した際に、常に高い使用量(使用率)のように見えますが、実際にはキャッシュ(cached、buffers)で多く使われていることが多いです。
※サーバ起動後、メモリ使用率は徐々に増加して90%程度に推移します。

メモリ上のデータは、一時的にduty(メモリには書き込まれ、ディスクには書き込まれていない状態)となりますが、あるタイミングでclean(ディスクに書き込まれて、いつでもメモリから消えても問題ない状態)となります。

duty から clean になるタイミングは、メモリからディスクへの書き込みタイミングの設定によって異なります。
※pdflush が実行されるタイミング。

メモリのサイジング(見積り)には、cached/buffers を考慮する必要があります。
大きなサイズのファイルを読み書きする場合、メモリを chached/buffer として使うことで、パフォーマンスが上がる可能性が高いです。サイズの大きな同じファイルに連続でアクセスする場合は、さらにメモリによるパフォーマンス向上が期待できます。

cached/buffers のみに多くメモリが使われているからといって、メモリが過剰なサイズになっているとは一概には言えません。

ご指摘、ご質問などはコメントへお願いします。

Linux CPU使用率のコマンド、複数コアの計算について

現在のCPUの使用率は、top 、mpstat コマンドや/proc/cpuinfo を参照することで確認できます。

また、sar コマンドで過去(デフォルト10分毎)の情報を確認できます。

CPU使用率は、OSが認識しているコア数が関係します。

1コアであれば全CPU使用率は1コアの使用率と同じになりますが、4コアの場合の全CPU使用率は4コアの合計値となります。

例えば、各コアの使用率が、
   1コア目:100%
   2コア目:60%
   3コア目:40%
   4コア目:0%
の場合、全CPU使用率は50%((100+60+40+0)/4=50)となります。

mpstatやcpuinfo はコア毎に使用率(量)が表示されている項目があるため、全CPU使用率を確認する際は、全使用率の項目を確認する、又は合算するなどの注意が必要です。

ご指摘、ご質問などはコメントへお願いします。