APACHE インストールに関する注意事項

apache|メモ

著者: Chedong

要約:

WEB アプリケーションのキャパシティ プランニング: WEB アプリケーションのハードウェア構成と特性に基づいた WEB サービスの計画といくつかの簡単な見積もり式;
APACHE インストール プロセス: 将来の利便性を考慮した Apache の汎用的な簡素化されたインストール オプションアプリケーション;
HARD_SERVER_LIMIT を変更します:
vi /path/to/apache_src/src/include/httpd.h
#define HARD_SERVER_LIMIT 2560 <===元の HARD_SERVER_LIMIT 256 の後に「0」を追加します
apache コンパイル:
/path/ to/apache_src/configure --prefix=/another_driver/apache --enable-shared=max --enable-module=most
オプションのアプリケーションモジュール/ツールのインストール: php 樹脂 mod_gzip mod_expire と各種モジュールの連携
PHP のインストール:
/path/to/php_src/configure --with-apxs=/path/to/apache/bin/apxs --with-other-modules-you-need
mod_resin インストール:
/path/to/resin/src/ configure --with-apxs=/path/to/apache/bin/apxs
Mod_gzip インストール:
/path/to/apache/bin/apxs -i -a -c mod_gzip.c
ツール: cronolog インストール: http:/ /www.cronolog.org
アップグレード/メンテナンス: 共通のモジュール式インストール プロセスにより、毎日のアップグレード/メンテナンス作業がどのように簡素化されるかを確認します。
上記の方法に従って、システム管理者とアプリケーションを管理します。管理者の責任は明確に分離され、互いに独立しています。
システムのインストール：システム管理者の責任はシステムのインストールです => あらゆる状況に適応できるAPACHEをインストールし、COLONをインストールします
アプリケーションのインストール：アプリケーション管理者は特定のアプリケーションに必要なモジュールと設定を担当しますHTTPD。
システムのアップグレード: システム管理者: システムのアップグレード/APACHE のアップグレード
アプリケーションのアップグレード: システム管理者: アプリケーション モジュールのアップグレード


具体的な手順:

WEB アプリケーションの容量計画
APACHE は主にメモリを消費するサービス アプリケーションです。私の個人的な経験によると、 :
apache_max_process_with_good_perfermance < (total_hardware_memory / apache_memory_per_process ) * 2
apache_max_process = apache_max_process_with_good_perfermance * 1.5

apache_max_process_with_good_perfermance と apache_max_process があるのはなぜですか?その理由は、負荷が低い場合、システムはファイル システムのキャッシュに多くのメモリを使用できるため、単一リクエストの応答速度がさらに向上します。高負荷下では、単一リクエストに対するシステムの応答速度が大幅に遅くなり、apache_max_process を超えると、システムは仮想メモリ スワップ領域としてハードディスクを使用し始め、システムがクラッシュします。さらに、同じサービス: 2G メモリを搭載したマシンの apache_max_process は、通常、1G メモリの 1.7 倍にのみ設定されます。これは、APACHE 自体がより多くのプロセスを管理するためパフォーマンスの低下を引き起こすためです。

例 1:
Apache + mod_php サーバー: Apache プロセスには通常 4M のメモリが必要です
1G メモリを搭載したマシンでは: apache_max_process_with_good_perfermance < (1g / 4m) * 2 = 500
apache_max_process = 500 * 1.5 = 750
サービスができる限り 500 APACHE 未満で実行されるようにアプリケーションを計画し、APACHE のソフト上限を 800 に設定します。

例 2:
Apache + mod_resin サーバー: Apache プロセスは通常 2M のメモリを必要とします
2G メモリを備えたマシンの場合: apache_max_process_with_good_perfermance < (2g / 2m) * 2 = 2000
したがって: apache_max_process = 2000 * 1.5 = 上記推定 3000

はすべて小さなファイル サービスに基づいています (リクエストのサイズは通常 20k 未満です)。ファイル ダウンロード タイプのサイトの場合は、帯域幅などの他の要因の影響を受ける可能性もあります。

APACHE インストールプロセス

サーバー数のハード上限である HARD_SERVER_LIMIT の変更:
FREEBSD や LINUX などの UNIX オペレーティング システムでの APACHE プロセスのデフォルトの最大数は 256 で、apache_1.3.xx/src/ include/ を変更する必要があります。 httpd.h
#ifndef HARD_SERVER_LIMIT
#ifdef WIN32
#define HARD_SERVER_LIMIT 1024
#elif 定義(NETWARE)
#define HARD_SERVER_LIMIT 2048
#else
#define HARD_SERVER_LIMIT 2 560 <=== ハードサーバー制限 256続いて「 0」
#endif
#endif

説明:
APACHE のデフォルトの最大ユーザー数は 256 です: この構成は、サーバーのメモリーがまだ約 256M だった時代にとって非常に優れたデフォルト設定ですが、サーバーのメモリーが急激に増加しているため、メモリ コストの大規模サイトのサーバー メモリ構成は、通常、当時のメモリ構成よりも 1 桁以上高くなります。したがって、1G メモリを搭載したマシンにとって 256 プロセスというハード制限は無駄が多すぎ、APACHE のソフト上限 max_client は HARD_SERVER_LIMIT によって制限されるため、WEB サーバーのメモリが 256M を超える場合は、APACHE の HARD_SERVER_LIMIT を増やす必要があります。個人的な経験によると、2560 はメモリが 2G 未満のほとんどのサーバーの容量計画をすでに満たしています (APACHE のソフト上限の計画については以下を参照してください)。

APACHE コンパイル: 共通のコンパイル オプションにより、インストール プロセスを標準化できます
./configure --prefix=/another_driver/apache/ --shared-module=max --enable-module=most

説明:
--prefix=/another_driver/apache/: 一般に、ハードディスクはシステムの耐用年数が最も短いため、サービス データをシステムから完全に分離すると、データのアクセス速度が向上するだけでなく、さらに重要なことに、システムのアップグレードが大幅に容易になります。 、バックアップと復元。

--shared-module=max: 動的読み込みを使用するとパフォーマンスが 5% 低下しますが、便利なモジュールのアップグレード、システム アップグレードのリスクの軽減、標準化されたインストール プロセスなどの利点に比べれば大したことはありません

-- enable-module=most: いくつかの珍しいモジュールをコンパイルするために most を使用します。たとえば、後で説明する mod_expire は、Apache のデフォルトの共通モジュールに含まれていません。

そのようにビルドしたくない場合は、次のようにすることもできます。 /configure
"--with-layout=Apache"
"--prefix=/path/to/apache"
"--disable-module=access"
"--disable-module=actions"
"-- 無効にする-module=autoindex"
"--disable-module=env"
"--disable-module=imap"
"--disable-module=negotiation"
"--disable-module=setenvif"
"-- 無効にする-module=status"
"--disable-module=userdir"
"--disable-module=cgi"
"--disable-module=include"
"--disable-module=auth"
"-- 無効にする-module=asis"

しかし、そのようなコンパイルはサービスのパフォーマンスをほんのわずか (約 5%) 向上させるだけで、モジュールであろうと APACHE 自体であろうと、将来のシステム アップグレードやモジュール アップグレードの柔軟性を失うことがわかりました。アップグレードする必要があります。すべての SOURCE を一緒に追加して再コンパイルします。

Apache のデフォルト設定ファイルは一般に比較的大きいです。コメントを削除することで簡素化できます。その後、特定のトレーニング プロセスに入ることで、必要なものをより速くカスタマイズできるようになります。
grep -v "#" httpd.conf.default >httpd.conf

変更する必要がある一般的な項目は次のとおりです:

#サービス ポート、デフォルトは 8080、APACHE 全体を調整することをお勧めしますサービスポートを正式なサービスポートに変更します
ポート8080 => 80

#サーバー名:デフォルトではなし
サーバー名name.example.com

#サービスプロセスの最大数:サービス容量の予測に従って設定します
MaxClients 256 => 800

#サービス開始後のデフォルトのサービスプロセス数: サービスが比較的安定したら、平均負荷時の httpd の数に応じて設定します
StartServers 5 => 200

:
その変更の前に次のような提案がありました:
MinSpareServers 5 => 100
MaxSpareServers 10 => 200

しかし、私の経験から言うと、デフォルト値はすでに非常に最適化されており、APACHE にプロセス数を独自に調整させる方が良いです。

特別な変更:
Solaris またはメモリ リークが発生しやすい一部のアプリケーション:
MaxRequestsPerChild 0 => 3000

アプリケーション モジュールとツールのインストール構成:

動的読み込みモードのため、簡単に渡すことができますAPACHE をカスタマイズするための設定: 使用頻度の低いモジュールをすべてクリアします

一般的に、不要なモジュールには次のものが含まれます:
#LoadModule env_module libexec/mod_env.so
#LoadModule relationship_module libexec/mod_negotiation.so
#LoadModule status_module libexec/mod_status include は廃止されました
#LoadModule include_module libexec/mod_include.so
#デフォルトのインデックス ファイルなしでディレクトリ内のすべてのファイルをリストする必要はありません
#LoadModule autoindex_module libexec/mod_autoindex.so
#CGI は使用しないようにしてください : 従来からAPACHEで最もセキュリティ上の問題が多い場所
#LoadModule cgi_module libexec/mod_cgi.so
#LoadModule asis_module libexec/mod_asis.so
#LoadModule imap_module libexec/mod_imap.so
#LoadModule action_module libexec/mod_actions.so
#使用しないでくださいセキュリティ検証により、アクセス速度が大幅に向上します
#LoadModule access_module libexec/mod_access.so
#LoadModule auth_module libexec/mod_auth.so
#LoadModule setenvif_module libexec/mod_setenvif.so

保持するのに最適なものは次のとおりです:
#ログ形式のカスタマイズ用
LoadModule config_log_module libexec/mod_log_config.so
#ファイルアプリケーションの関連付けを増やすために使用されます
LoadModule mime_module libexec/mod_mime.so
#デフォルトのインデックスファイルに使用されます:index.phpなど
LoadModule dir_module libexec/mod_dir.so

利用可能かどうかは次のとおりです:
#例: ~/username/ で php をデバッグする必要がある場合は、
LoadModule userdir_module libexec/mod_userdir.so を使用できます
#例: 以前の URL をリダイレクトする必要がある場合、またはCGI script-alias を使用します
LoadModule alias_module libexec/mod_alias .so


一般的に使用されるモジュール:
おそらく最も一般的に使用されるモジュールは、php および JAVA WEB アプリケーションのラッパーです。さらに、パフォーマンスの点では、mod_gzip は約 40% 削減できます。 mod_expires はトラフィックの削減につながり、送信のためのマシンの負荷を軽減します。一方、mod_expires は繰り返しのリクエストを約 10% 削減し、サーバーにまったくリクエストを行わずに、繰り返しのユーザーリクエストをローカルにキャッシュできるようにします。

PHP インストール:

/path/to/php_src/configure --with-apxs=/path/to/apache/bin/apxs --with-other-modules-you-need
変更が必要な設定:
AddType application/x-httpd-php .php .php3 .any_file_in_php

樹脂のインストール設定:
/path/to/resin/src/configure --with-apxs=/path/to/apache/bin/apxs

通常、特定の樹脂設定は別のファイルに配置されます:

CauchoConfigFile /path/to/apache/conf/resin.conf


mod_expires インストール構成:

ExpiresActive on
#すべての .gif ファイルは 1 か月後に期限切れになります
ExpiresByType image/ gif "アクセスプラス 1 か月"
#デフォルトではすべてのファイルの有効期限が 1 日後に切れます
ExpiresDefault "現在プラス 1 日"


mod_gzip インストール:
/path/to/apache/bin /apxs -i -a -c mod_gzip.c


mod_gzipとPHPを一緒に設定します

mod_gzip_on Yes
mod_gzip_minimum_file_size 1000
mod_gzip_maximum_file_size 300000
mod_gzip_item_インクルード ファイル .htm$
mod_gzip_item_include ファイル .html$
mod_gzip_item_include ファイル .php $
mod_gzip_item_include file .php3$
mod_gzip_item_include mime text/.*
mod_gzip_item_include mime httpd/unix-directory
#mod_gzip セッションと php セッションに同じ一時ディレクトリを使用させないでください: php_session は php.ini を渡す必要があります セッション .save_path を設定します= /tmp/php_sess
mod_gzip_temp_dir /tmp/mod_gzip
mod_gzip_dechunk はい
mod_gzip_keep_workfiles いいえ

mod_gzip と mod_php 間の連携: mod_gzip と mod_php が同じ一時ディレクトリを使用しないようにします。

mod_gzipレジン協力：Make mod_gzip は mod_caucho の後にロードされます。そうしないと mod_gzip は機能しません
...他のモジュール
AddModule mod_so.c
AddModule mod_caucho.c
#注意: mod_gzip は mod_caucho
AddModule mod_gzip.c
AddModule mod_expires.c
の後にロードする必要があります。

mod_gzip_on はい
mod_gzip_dechunk はい
mod_gzip_keep_workfiles いいえ
mod_gzip_minimum_file_size 3000
mod_gzip_maximum_file_size 300000
mod_gzip_item_include ファイル 。 html$
mod_gzip_item_include mime text/.*
mod_gzip_item_include mime httpd/unix-directory
mod_gzip_item_include ハンドラ 'caucho- request'


ログ ローテーション ツール cronolog のインストールと設定: cronolog は毎日のローテーションでログを非常にきれいに保存できます
デフォルトのコンパイルとインストールは /usr/local/bin/ にあります。設定を次のように変更するだけです。

CustomLog "|/usr/local/sbin/cronolog /path/to/apache/logs/%w/access_log" を結合

ログは日ごとに切り捨てられ、曜日をディレクトリ名とするディレクトリに保存されます。例: log/1 は月曜日、log/5 は金曜日、log/0 は日曜日です

アップグレードとメンテナンス:

標準化された DSO モードを使用して APACHE をインストールするため、APACHE の HTTPD コア サービスとアプリケーション モジュール、およびアプリケーション モジュールは、非常に柔軟です。すべての独立したモジュールの設定を

CONFIGURATIONS..

に入れることをお勧めします。この設定は、特定のモジュールをブロックすることで非常に簡単に実行できます。例:
#AddModule mod_gzip.c
は mod_gzip をブロックし、他のモジュールは影響を与えません。

インストールとメンテナンスのプロセス:

システムのインストール: システム管理者の責任は、システムと、あらゆる状況に適応できる APACHE、そして COLON をインストールすることです。
アプリケーションのインストール: アプリケーション管理者は、特定のアプリケーションに必要なモジュールと HTTPD の設定を担当します。
システム アップグレード: システム管理者: システムのアップグレード/APACHE のアップグレード
アプリケーションのアップグレード: アプリケーション管理者: アプリケーション モジュールのアップグレード
システムのバックアップ/復元: APACHE がデフォルトのシステム ディスク上にない場合は、APACHE ディレクトリをバックアップするだけで済みます。システム パーティションでハードウェアの問題が発生した場合は、事前に準備されたシステム COLON を使用して、APACHE が存在する物理ディスクを直接復元します。
システム管理者: APACHE の最も単純なインストール OS + APACHE (httpd コアのみ)
アプリケーション管理者: アプリケーション モジュールのカスタマイズ +so
+php
+so
+caucho
+ssl
適用可能なアプリケーション: 純粋な静的ページ サービス:
image.example。 com
www.example.com bbs.example.com mall.example.com


参考ドキュメント:

Apache
http://httpd.apache.org/

php
http://www .php.net /

樹脂
http://www.caucho.com/

mod_gzip
http://www.remotecommunications.com/apache/mod_gzip/

Cronolog
http://www.cronolog.org /

mod_expires
http://httpd.apache.org/docs/mod/mod_expires.html