WordPressのためのLinuxノートWordPressでのブログ運用のためにピピッと来たLinuxに関するナレッジを紹介しています。停止方法Webサービスを停止する場合には、実行中のリクエストの処理をどう扱うかを考えた上で、適切な方法を採らなくてはなりません。扱いの考え方には次の2通しがあります。実行中のリクエストの処理を中止して、即時停止する。実行中のリクエストの処理が完了するのを待ってから停止する。どのような方法を採るのかを整理しておきます。実行コマンドは次の2通りです。それぞれにオプションがありますが、どちらのコマンドでも同じ処理を行います。オプションオプションは次の2通りです。プロセスにTERMシグナル(SIGTERM)を送って、プロセスを即終了します。処理中のリクエストはすべて中止して、すべての子プロセスを終了してから、親プロセスも終了します。プロセスにWINCHシグナル(SIGWINCH)を送って、子プロセスを終了します。子プロセスは実行中のリクエストの処理が完了してから終了します。親プロセスは、すべての子プロセスが終了したあとに終了します。実行中のリクエスト処理の扱いと適切な停止コマンドオプション実行中のリクエスト処理の扱いの違いによる実行コマンドオプションの対応を下表に整理します。実行中のリクエストの処理を中止して、即時停止する。実行中のリクエストの処理が完了するのを待ってから停止する。起動関連の様々なコマンドオプションがあります。状況や目的に応じて、使い分けることが必要になると思います。どのようなオプションを使うべきなのか整理しておきたいと思います。コマンド自体を確認しておきます。下記の2通りあります。ここでの起動という目的を考えた場合には、いずれを使用しても同じです。このオプションを次のようにして確認してみます。{start|stop|restart|condrestart|reload|status|fullstatus|graceful|help|configtest}ここで、再起動に関係するオプションは次の4つです。gracefulそれぞれどのような処理になるのでしょうか。1.restart停止処理と開始処理を連続して行います。開始処理の際に、変更した設定が反映されます。停止処理は、TERMシグナル(SIGTERM)を送って、プロセスを即終了します。処理中のリクエストはすべて中止して、すべての子プロセスを終了してから、親プロセスも終了します。その後、起動処理を行います。親プロセスIDは変更されます。起動しているときだけ再起動を行います。3.reloadHUPシグナル(SIGHUP)を送って、子プロセスを終了します。子プロセスのみを即終了して、親プロセスは終了しません。処理中のリクエストはすべて中止されます。すべての子プロセスが終了したあとに、親プロセスは設定を再読み込みし、変更した設定が反映されます。変更後の設定の反映だけを行いたい場合に使用します。4.gracefulUSR1シグナルを送って、子プロセスを終了します。子プロセスは実行中のリクエストの処理が完了してから終了します。すべての子プロセスが終了したあとに、親プロセスは設定を再読み込みし、変更した設定が反映されます。実行中のリクエストの処理を中止させたくない場合に使用します。移行する必要がありました。移行方法を整理しておきます。ポイントは、旧環境における過去ログ分析データを移行することです。移行に必要な作業は次の通りです。rpmforgeリポジトリにありますので、それをインストールします。パッケージ情報を確認します。導入することにしました。要件事項は次のようなものです。これらの要件事項をほぼ満たしていると判断できましたので、導入することにしました。インストールyumでインストール可能なパッケージがあるはずだと考えられますので、検索してみます。(記事作成時バージョン2.2.3)のKeepalive関連ディレクティブの調整(チューニングとまでは行きませんが)を行いたいと思います。Keepalive関連ディレクティブとは次の3つです。接続しているセッションからのリクエストが途絶えてから、切断するまでの待ち時間の指定よくよく考えると、当然のようにkeepaliveを「On」にしがちですが、もう少し有効性やより効果的な設定を考えてみる必要があると思います。1つのWebページを表示するためには、そのWebページのhtmlファイルとそこに表示する画像ファイルやCSSファイルなどを別途リクエストして、サーバから送ってもらう必要があります。それらのファイルが多い場合には、1つのWebページを表示するために、htmlファイル以外に数多くのリクエストを行うことになります。ちなみに、画像は想像以上に多く使っているものです。アイコンやら、ちょっとした枠線、背景画像などよく考えるとみんな画像を使っています。その際に、Keepaliveを無効にしていると、ファイル一つ一つについて、接続と切断を繰り返さなくてはならなくなります。Keepaliveを有効にしていると、例え1つのWebページの表示に複数ファイルをダウンロードする必要があるとしても、1つの接続内ですべてのファイル処理を完了させることができるようになります。動的htmlファイルの場合は、phpやjavaなどのスクリプト(プログラム)によって、基本的に1つのhtmlファイルとして生成されていると思われます。各種スクリプトを別ファイルではなく、インライン編集するケースも多いと思います。動的htmlでも前述の画像ファイルは相応に存在するわけで、リクエストの多少は大きく変わらないかも知れません。比較的大きなファイルになるケースが多いということなどを考えると、動的htmlファイルの生成~送信の処理を早く終わらせ、接続を切る、というのがベターだと考えます。このようなことから、私の考えとしては、大規模Webサイトであれば、Webサーバを動的ファイル用と静的ファイル用に分割構成にして(バーチャルホストを分割する方法でも良い)、それぞれ次のように設定を分けるのが良いのではないかと考えます。←画像ファイルはこちらただし、当サイトは小規模ですので、動的ファイル用と静的ファイル用に分割する必要性まではありませんので、限られたリソースを有効に利用し、かつ無駄を最小限に止める方策を考えたいと思います。そこで、次のように考えてみました。1.当サイトの場合、1つのWebページを表示するために、概ね40~50程度の画像ファイルが必要です。よって、動的に生成された1つのhtmlファイルとそれらの画像ファイル数を合計して、1つの接続でリクエストするファイル数は最大50と考えて良さそうです。