VPSのLAMP + Nginxは安定しており、頭痛がありません

タスクは、最小のVPSリソースにいくつかのアンロードされたサイトのホスティングを展開することです。 将来的に最小限の問題でこれを迅速かつ便利に行い、ピーク負荷に陥らないようにする。

基本原則：

1. OS-Centos-6 86_x64。安定性があり、便利で、更新が簡単です。
2.自己組織化ソフトウェアはありません。 そして彼らが言うように、「make && make installコマンドで、どんなディストリビューションもSlackwareに変わります。」

現時点では、ホスティングプロバイダーflynet.pro（256MB RAM）でv256タリフプランを使用しており、ほとんどの作業を期待しないため、ほとんどのRAMを参照しますが、一般的に、ソリューションは実質的にすべてのタリフプランに簡単に移植できますさまざまなホスティングプロバイダー。
そしてもう一つの明確化-ホスティングは「あなた自身のために」行われます。 見知らぬ人にサイト管理へのアクセスを許可する場合に考慮すべき十分な説明された瞬間はありません。

行こう
1.アップデートを確認します。
ホスティングプロバイダーのインストールイメージは、最新のものではない場合があります。
[root@test ~]# yum update

更新するものがあります-更新します。 いいえ、私たちは幸せです。

2.不足しているソフトウェアをインストールするEPELリポジトリ（http://fedoraproject.org/wiki/EPEL）を接続します。
[root@test ~]# rpm -ihv download.fedora.redhat.com/pub/epel/6/x86_64/epel-release-6-5.noarch.rpm


3.必要なソフトウェアを入れます
[root@test ~]# yum install httpd mysql-server php vsftpd mc phpMyAdmin php-eaccelerator sysstat crontabs tmpwatch


ソフトウェアについて簡単に：
httpd-Centos-6のApache標準バージョン-2.2.15
mysql-server-mysql 5.1.52
php-PHP 5.3.2
vsftpd-非常に便利なFTPサーバーvsftpd 2.2.2
mc-コマンドラインよりもmcの方が便利な場合があります。
phpMyAdmin-mcに似ています。 phpMyAdminでmysqlデータベースを管理する方が便利です。
php-eaccelerator-PHPのアクセラレータ。 スクリプトの実行速度が著しく向上し、プロセッサーの負荷が軽減されます。 はい、そして記念品として。
sysstat-システムの状態を確認したい場合。
crontabs-スケジュールされたタスク用。
tmpwatchは、古いファイルを削除するためのユーティリティです。

実際、さらにいくつかのパッケージがインストールされます。インストールを要求したパッケージには、それらの機能に必要なものがすべて追加されます。
結果は次のとおりです。
Install 44 Package(s)
Upgrade 0 Package(s)

Total download size: 37 M
Installed size: 118 M


4. freeコマンドを使用して、スワップがあるかどうかを確認し、ない場合は作成して接続します。 ある場合、私たちは喜んでこの項目をスキップします。
ここで重要な点-スワップの積極的な使用-は非常に悪いです。 アクティブなスワップがある場合、何かを最適化またはトリミングする必要があります。 最適化して削減できない場合は、より高価な料金プランに切り替える必要があります。 また、ホスティングプロバイダーがスワップの過剰な使用によって気分を害する可能性があることも考慮する価値があります。
しかし、スワップがなければ、それもあまり良くありません-オームキラーは恐ろしいことです。 それは不注意にmysqldを強制終了する可能性があり、単にサイトの速度を落とす代わりに完全に嘘をつくでしょう。
注-使用可能なRAMを超えるスワップを行う必要はありません。 彼からの利益はありませんが、彼は場所を食べます。

次のようにスワップを作成します。
[root@test /]# dd if=/dev/zero of=/swap bs=1M count=256
[root@test /]# mkswap /swap


つなぐ
[root@test /]# swapon /swap

接続するために、このコマンドを/etc/rc.localに自動的に書き込みます
topまたはfreeコマンドを使用して、スワップの可用性とビジー状態を確認できます。

5.デーモンをオンにして開始する
[root@test /]# chkconfig httpd on
[root@test /]# chkconfig mysqld on
[root@test /]# chkconfig crond on

[root@test /]# service httpd restart
[root@test /]# service mysqld restart
[root@test /]# service crond restart


6.サイトのユーザーを作成します。 ユーザー名はサイトのドメインに似ていることを好みます。
[root@test /]# adduser testsite.ru
[root@test /]# adduser mysite.ru
[root@test /]# adduser cfg.testsite.ru

次に、追加のユーザーディレクトリを作成します。 html（サイ​​トのメインコンテンツ）と、このサイトのログが書き込まれ、権限を設定するログ。 権限を設定します：ユーザー-フルアクセス、Apacheグループの読み取りとディレクトリのリスト、残り-イチジク。
権限は手動で設定するか、小さなスクリプトを使用できます。
cd /home
for dir in `ls -1 `; do
mkdir /home/$dir/log
mkdir /home/$dir/html
chown -R $dir:apache $dir
chmod ug+rX $dir
done;


7. Webサーバーを構成します。 /etc/httpd/conf/httpd.confを編集します
本当に必要な変更のうち、preforkモジュールを構成して、最初に消費するメモリを減らし、食欲を制限します。
実際には、Apacheは最初に最大256個のワークプロセスを実行するように構成されていましたが、1つのワークプロセスは20〜40 MB（256 * 20 = 5 GB）を簡単に消費しますが、これは特に256 MBのRAMしかない控えめなVPSで問題を引き起こす可能性があります
したがって、使用可能なRAMに基づいて、その数を適切な数に制限します。 たとえば、平均サイズが30 MBの5つのApacheプロセスには約150 MBがかかりますが、これはすでに耐えられます。
それは：
<IfModule prefork.c>
StartServers 8
MinSpareServers 5
MaxSpareServers 20
ServerLimit 256
MaxClients 256
MaxRequestsPerChild 4000


次のようになりました：
<IfModule prefork.c>
StartServers 2
MinSpareServers 2
MaxSpareServers 3
ServerLimit 5
MaxClients 5
MaxRequestsPerChild 1000


このような設定では、Apacheがメジャーを超えて拡張し、すべてのRAMを消費することはできません。 実際の負荷によっては、パラメータを修正する価値があります。
さて、行のコメントを外します
NameVirtualHost *:80

同じIPアドレスに多くのサイトを配置するため。

次に、/ etc / httpd / conf.d /ディレクトリに移動し、サイトを構成します。
そこでインデックスを無効にし、代わりにApache 2テストページページを表示するwelcome.confを削除できます。
このディレクトリ内の仮想ホスト設定は、アルファベット順に順番に適用されることに注意してください。
ユーザーがいずれかのサイトにIPアドレスでアクセスし、完全に異なる（リストの最初に表示される）ようにしないために、conf.dディレクトリを、たとえば000-default.confなどの名前のファイルに配置する必要があります。
<VirtualHost *:80>
ServerName localhost.local
DocumentRoot "/var/www/html"


ディレクトリ/ var / www / html / index.htmlファイルに希望を入れます。

次に、仮想ホストごとに、おおよそ次のテンプレートに従って構成ファイルを作成します。
<VirtualHost *:80>

ServerName testsite.ru
ServerAlias www.testsite.ru
ServerAdmin webmaster@testsite.ru
ErrorLog /home/testsite.ru/log/error.log
CustomLog /home/testsite.ru/log/access.log combined
DocumentRoot /home/testsite.ru/html/

<Directory "/home/testsite.ru/html">
Order allow,deny
Allow from all




これらのファイルでは、好みに応じて、モジュールの個々の設定を追加できます。

Apacheを再起動し、すべてが機能するかどうかを確認します。
[root@test /]# service httpd restart


Apacheは正常に起動するはずです。 ログサイトのディレクトリに、2つのログファイルを作成する必要があります。
IPアドレスでサーバーにアクセスする場合、/ var / www / html /に配置したファイルが表示され、サイト名でアクセスする場合、htmlディレクトリの内容（ほとんどの場合は空）と、対応するサイトのaccess.logファイルのエントリが表示されます。

8. mysqlを構成します。 まず、テストデータベースを削除し、mysqlのルートパスワードを設定します。
[root@test /]# mysql


mysql> DROP DATABASE test;
mysql> USE mysql;
mysql> UPDATE user SET Password=PASSWORD('MyMysqlPassword') WHERE user='root';
mysql> FLUSH PRIVILEGES;
mysql> quit


MySqlの問題は、Apacheの場合とほぼ同じです-VPSで非常に高価なメモリ要件。
サーバーが使用するSQLメモリの量を減らすには、次のように/etc/my.cnfを編集します。
[mysqld]セクションに次を追加します。
key_buffer = 16M
max_allowed_packet = 10M
table_cache = 400
sort_buffer_size = 1M
read_buffer_size = 4M
read_rnd_buffer_size = 2M
net_buffer_length = 20K
thread_stack = 640K
tmp_table_size = 10M
query_cache_limit = 1M
query_cache_size = 32M
skip-locking
skip-innodb
skip-networking


ファイルの最後に次の行を追加します。
[mysqldump]
quick
max_allowed_packet = 16M

[mysql]
no-auto-rehash

[isamchk]
key_buffer = 8M
sort_buffer_size = 8M

[myisamchk]
key_buffer = 8M
sort_buffer_size = 8M

[mysqlhotcopy]
interactive-timeout


mysqldを再起動して、すべてが正常であることを確認します。
[root@test ]# service mysqld restart


また、「skip-networking」オプションを使用すると、ローカルマシンからのみソケットを介してサーバーにアクセスできるようになります。 ネットワークアクセスが必要な場合、このオプションを有効にする必要はありません。
このような設定により、mysqlプロセスで使用されるメモリが最小化され、アンロードされたサイトで正常に動作します。 しかし、もちろん、mysqlの統計を確認する必要があり、必要に応じて、ここでのデータ制限を増やす必要があります。

mysqlのさらなる管理は、phpMyAdminを介して行う方が便利です。
現在、1つの警告があります-デフォルトでは、phpMyAdminはすべてのサイトのpath / phpMyAdminで利用可能です。
これを回避するために、管理用の特別なサイト（cfg.testsite.ruなど）を作成し、他のサイトと同様に構成します。
次に、/ etc / httpd / conf.d / phpMyAdmin.confファイルの内容全体をこのサイトの構成に転送し、phpMyAdmin.confファイル自体を削除するか、conf.dディレクトリからどこかに転送します。
このようなアクションの後、phpMyAdminはpath / phpMyAdmin /専用サイトでのみ利用可能になります。
さて、サイト構成ファイルに入力できるように、変更します
<Directory /usr/share/phpMyAdmin/>
Order Deny,Allow
Deny from All
Allow from 127.0.0.1
Allow from ::1


<ディレクトリ/ usr / share / phpMyAdmin / setup />
注文拒否、許可
すべてから拒否
127.0.0.1から許可
から許可:: 1


に
<Directory /usr/share/phpMyAdmin/>
Order Deny,Allow
Deny from All
Allow from 127.0.0.1
Allow from ...
Allow from ::1


<ディレクトリ/ usr / share / phpMyAdmin / setup />
注文拒否、許可
すべてから拒否
127.0.0.1から許可
メールアドレスから許可します。
から許可:: 1


その後、phpMyAdminがIPアドレスから利用可能になります。

設定したパスワードを使用して、rootユーザーとしてログインします。
ユーザーを作成するには、「特権」-「新しいユーザーの追加」に進みます
ユーザー名は任意です。混乱を避けるためにサイト名を使用することを好みます。
ホストはローカルです（そこでスピンするサイトのためにそれを行っていますか？）
パスワード-生成。 （パスワードを忘れずにコピーしてください）
チェックマークを付けます-「名前にユーザー名を使用してデータベースを作成し、それに完全な権限を提供します」
適用します。
その結果、同じ名前のユーザーの名前、パスワード、および選択したデータベースを取得します。

9.多くの場合、ftpを介してファイルをホスティングにアップロードすると便利です。 このためにvsftpdをインストールしました
その構成を編集/etc/vsftpd/vsftpd.conf
匿名ログインをオフにし、変更します
anonymous_enable=YES

に
anonymous_enable=NO


コメント解除
chroot_local_user=YES


特定のサイトのftpにアクセスできるようにするには、対応するユーザーがパスワードを設定する必要があります
[root@test /]# passwd testsite.ru


デフォルトでは、パスワードを持つこのユーザーはSSH経由でログインできることを忘れないでください。 この機能を無効にする最も簡単な方法は、ユーザーのシェルを変更することです
[root@test etc]# chsh -s /sbin/nologin testsite.ru


vsftpdをオンにして実行する
[root@test /]# chkconfig vsftpd on
[root@test /]# service vsftpd start


すべてが機能するかどうかを確認します。

そして最後に、非常に単純な「運用バックアップ」。 「バックアップはあまり起こらない」という原則によると。
より正確なものを使用することをお勧めしますが、完全に不在の場合よりも、バックアップが不良である方が優れています。
このようなバックアップは、ホスティングプロバイダーでの仮想マシンのフルバックアップへの適切な追加として機能します。 しかし、決してそれを置き換えるものではありません。
サイトとデータベースのコンテンツ、および/ etc /ディレクトリの設定をバックアップします。
ディレクトリ/ backup /を作成し、その権利を「700」に設定します

[root@test /]# mkdir /backup/
[root@test /]# chmod 700 /backup/


/etc/cron.daily/ディレクトリで、backup.shファイルを作成し、「700」権限も設定します。
[root@test /]# touch /etc/cron.daily/backup.sh
[root@test /]# chmod 700 /etc/cron.daily/backup.sh


ファイルの内容は次のとおりです。

#!/bin/sh

# html
tar -cf - /home/*/html/ | gzip > /backup/sites-`date +%Y-%m-%d`.tar.gz

#
mysqldump -u root --password=MyMysqlPassword --all-databases | gzip > /backup/mysql-`date +%Y-%m-%d`.dump.gz

#
tar -cf - /etc/ | gzip > /backup/etc-`date +%Y-%m-%d`.tar.gz

# 7
tmpwatch -t -m 7d /backup/


原則として、1つのヒープだけでバックアップするのではなく、すべてを個別にバックアップする方がよい場合がありますが、何かのバックアップを構成することを忘れて、必要なときに後悔することが可能になります。
まあ、または「個別に」バックアップオプションでは、サイトのユーザー名とデータベース名が一致する必要があります。

#!/bin/sh
for dir in `ls -1 /home/ `; do
tar -cf - /home/$dir/html/ | gzip > /backup/sites-$dir-`date +%Y-%m-%d`.tar.gz
mysqldump -u root --password=MyMysqlPassword $dir | gzip > /backup/mysql-$dir-`date +%Y-%m-%d`.dump.gz
done;

#
tar -cf - /etc/ | gzip > /backup/etc-`date +%Y-%m-%d`.tar.gz

# 7
tmpwatch -t -m 7d /backup/


10.アップデート。
時々システムを更新することを忘れないでください。
[root@test ~]# yum update

ソフトウェアに関するRHEL / Centosのポリシーのおかげで、アップグレード後のソフトウェアバージョンは同じままであり、構成内で何かがほとんど変更されていないという事実により、不注意でサーバーを配置します。
このアプローチの真実もマイナスです。Centos-6では、3年間で現在と同じソフトウェアバージョンが提供されます。 しかし、目標が安定性であれば、それは私たちに合っています。

11.テスト。
設定後にサイトをテストすることを強くお勧めします。
テストの最初のポイントは、サーバーを再起動し、必要なすべてのデーモンが起動し、すべてが期待どおりに機能することを確認することです。 通常、稼働時間の数字を追いかけるのではなく、自動的に起動するサーバーソフトウェアのバージョンをインストールまたは変更した後に再起動することをお勧めします。
ホスティング業者に問題があり、仮想マシンを再起動した結果、そのサイトがすでに半日稼働していることを確認するよりも、Apacheがスケジュールされた独自の再起動後に自動実行を開始しないことを確認する方が適切です。
次は、abユーティリティ（Apache HTTPサーバーベンチマークツール）を使用した負荷テストです。
このテストでは、負荷のかかったサーバーの動作ほど、オウムの数には関心がありません。 それは死にかけているプロセスとアクティブなスワップを持たないはずです。
テストを行うには、稼働状態のこのサーバーでホストされているサイトが必要です。 そして、このサイトの「典型的な」ページ。 まあ、または典型的なものではなく、最も難しいものを使用できます。

たとえば、新しくインストールしたDrupal 7.9でテストしています

さまざまなコマンドラインabから、必要なパラメーターは2つだけです-n-http要求の数-c-同時要求（スレッド）の数
topを使用した2番目のsshセッションでのテスト中に、サーバーの動作を観察します。

2スレッドで100リクエスト。

[root@test ~]# ab -n 100 -c 2 testsite.ru


abの出力から、サーバーパフォーマンスの一般的な概念を示す「1秒あたりのリクエスト数」、「リクエストあたりの時間」、「失敗したリクエスト」に特に興味があります。

Failed requests: 0
Requests per second: 6.20 [#/sec] (mean)
Time per request: 322.788 [ms] (mean)


サーバーは1秒あたり1ペニーのリクエストで6を処理し、1ページの生成に322ミリ秒を費やしていることがわかります。

一番上の出力から、メモリの割り当てとプロセッサのロードが興味深いです。

Tasks: 62 total, 3 running, 59 sleeping, 0 stopped, 0 zombie
Cpu(s): 19.9%us, 5.3%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.4%si, 74.5%st
Mem: 244856k total, 151624k used, 93232k free, 3752k buffers
Swap: 262136k total, 0k used, 262136k free, 76604k cached


スワップ：0k使用-すっごく良い。
93232kの空き+ 76604kのキャッシュは、実際には170 MBの空きメモリです。

100リクエスト5スレッド。

[root@test ~]# ab -n 100 -c 5 testsite.ru


Failed requests: 0
Requests per second: 6.21 [#/sec] (mean)
Time per request: 804.513 [ms] (mean)

Tasks: 63 total, 5 running, 58 sleeping, 0 stopped, 0 zombie
Cpu(s): 17.5%us, 6.2%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 76.3%st
Mem: 244856k total, 159756k used, 85100k free, 3812k buffers
Swap: 262136k total, 0k used, 262136k free, 76660k cached


1秒あたりのリクエスト数は同じままでしたが、生成時間は2倍以上増加しました-プロセッサに到達しました。

そして最後に、habraeffectまたは何か近い:-)

[root@test ~]# ab -n 500 -c 50 testsite.ru


Failed requests: 0
Requests per second: 6.45 [#/sec] (mean)
Time per request: 7749.972 [ms] (mean)

Tasks: 63 total, 6 running, 57 sleeping, 0 stopped, 0 zombie
Cpu(s): 19.1%us, 5.3%sy, 0.0%ni, 0.0%id, 0.0%wa, 0.0%hi, 0.0%si, 75.6%st
Mem: 244856k total, 162740k used, 82116k free, 3884k buffers
Swap: 262136k total, 0k used, 262136k free, 76672k cached


繰り返しますが、1秒あたりのリクエスト数は比較的安定していますが、生成時間は非常に悲しくなりました。 ただし、同時に、失敗したリクエストはゼロです。 つまり、ゆっくりですが、すべてが機能します。
さて、メモリについて-Swap：0k used、82116k free、76672k cached-消費量はそれほど増えておらず、原則としていくつかの制限を増やすことができますが、現時点ではサイトコンテンツが不足しているため、これを行うべきではないと思います。 しかし、後で完成したサイトでテストを実行する価値があり、結果に応じて、すでに設定を調整しています。

12. nginxをフロントエンドとしてインストールします。

なぜこれが必要なのですか。
主な問題は、Apacheが着信接続を処理する方法です。 着信接続ごとに、新しいプロセスが作成されるか、開始されたプロセスの1つが取得され、サービスのために接続が転送されます。 接続が閉じられるまで、このプロセスはそれだけを扱います。
原則として、多くのRAMおよび/または非常に高速なクライアント（ローカルホストからこれらのオプションのいずれかを実行している）がある限り、すべてが見栄えがしますが、クライアントが遅いチャンネルに座っているか、急いでいない場合はすべてがより悲しくなります。 この場合、要求の収集時にプロセスの1つを実際にブロックします。この時点では、サーバーからはオフになっています。
したがって、理論的には、100Mbitチャネルにサーバーがあり、リセット付きのダイヤルアップに1つの永続的なクライアントがあると、DOSのようなものが得られます-いくつかのスレッドのクライアントは、RAMが少ないために考えているほぼすべてのApacheプロセスをブロックします。
この問題は、フロントエンドの形式である種の軽量のhttpサーバーをインストールすることで解決されます。 フロントエンドがある場合、すべての着信接続は彼によって受け入れられ、リクエストはapacheに送信され、応答がすぐに受信されるため、新しいリクエストに対してapacheプロセスが解放されます。 フロントエンドは、不必要なリソースをゆっくりと無駄にせずに、既に要求したクライアントに受信した応答を提供します。
フロントエンド自体が静的コンテンツに追加のボーナスを提供できます-たとえば、写真、CSSなど。 重いApacheの緩和。

[root@test ~]# rpm -ihv centos.alt.ru/pub/repository/centos/6/x86_64/centalt-release-6-1.noarch.rpm
[root@test ~]# yum install mod_realip2 nginx-stable


Apacheとリクエスト内のスクリプトがフロントエンドアドレスではなく実際のクライアントIPアドレスを確認するために、mod_realip2をインストールします。
/etc/httpd/conf.d/mod_realip2.confの編集、コメント解除
RealIP On
RealIPProxy 127.0.0.1
RealIPHeader X-Real-IP


httpd.confおよび/etc/httpd/conf.d/内のファイルを編集します
ポート80のすべての表示をポート8080に変更します
合計で、次の3つのディレクティブを変更する必要があります。
Listen 127.0.0.1:8080
NameVirtualHost *:8080
<VirtualHost *:8080>


/etc/nginx/nginx.confを編集します
user apache;
worker_processes 2;


最初はすべての権利を期待して与えていたため、apacheユーザーの下からnginxを起動します。
二重ロギングを回避するために、nginx.confのaccess_logディレクティブをコメント化することも役立ちます。
error_logはそのままにしておくのが最善です-Apacheとnginxのエラーはまだ異なります。

サーバーセクションで、listenディレクティブを編集して設定します。
listen 80 default


変更：
location / {
root /usr/share/nginx/html;
index index.html index.htm;
}

に
location / {
proxy_pass 127.0.0.1:8080/;
}


/etc/nginx/conf.d/ディレクトリで、次の内容のproxy.confファイルを作成します
proxy_redirect off;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
client_max_body_size 10m;
client_body_buffer_size 128k;
proxy_connect_timeout 90;
proxy_send_timeout 90;
proxy_read_timeout 90;
proxy_buffer_size 4k;
proxy_buffers 4 32k;
proxy_busy_buffers_size 64k;
proxy_temp_file_write_size 64k;


Apacheとnginxを再起動します
service httpd restart
service nginx restart

すべてが機能するかどうかを確認します。

一般的に、すべて。 現在、nginxはフロントエンドとして機能し、すべての着信接続を受け入れ、Apacheがプロキシを処理してそれらを処理し、すぐに応答をnginxに返し、新しいリクエストのためにプロセスを解放します。

パフォーマンスを向上させ、リソース消費を削減するための次のステップは、nginxから直接静的コンテンツを返すことです。

これを行うには、Apache仮想ホストに加えて、nginx仮想ホストを作成し、配布するものを指定する必要があります。
これを行うには、/ etc / nginx / conf.d /ディレクトリに、サイトの名前と拡張子.confを持つファイルを作成し、次の内容を追加します。
server {
listen 80;
server_name testsite.ru www.testsite.ru;
location / {
proxy_pass 127.0.0.1:8080/;
}

location ~ /\.ht {
deny all;
}

location /sites/default/files {
root /home/testsite.ru/html;
access_log /home/testsite.ru/log/access_static.log combined;
}
}


この例では、CMS Drupalのサイトの場合、/ sites / default / filesディレクトリの静的コンテンツはnginxを介して配布されますが、他のすべてについては、すでにApacheにアクセスしています。
別のオプションは、locationディレクティブを次のものに置き換えることです。
location ~ \.(jpg|gif|png|css|js|ico)$ {
root /home/testsite.ru/html;
access_log /home/testsite.ru/log/access_static.log combined;
}

この場合、対応する拡張子を持つすべてのファイルはnginxによって提供されます。 しかし、このバージョンには小さなマイナスがあります-nginxは.htaccessファイルの操作方法を知らないため、.htaccessを表示できないコンテンツがある場合は、このオプションの使用を控えてください。

この状況では、1つのサイトで2つのログを取得することにも注意してください。 個別に、Apacheが動作したリクエストログと、nginxログの内容を個別に。
または、access_logディレクティブをlocationセクションからserverセクションに転送し、Apache仮想ホストでaccess_logを無効にします。 この場合、nginxのみがログに記録します。
しかし、「それがどのように機能するか」を見るために、二重ログは興味深いことがあります-彼らはすぐに負荷がどれだけ誰にかかっているかを示します。

さらなる最適化については、特定のコンポーネントを既に最適化し、現在の状況を考慮してそれを行うことに関するマニュアルを読む価値があります。

UPD：いくつかのタイプミスを修正
UPD：スワップ接続を修正、 AngryAnonymousに感謝
UPD： nginxのインストールと設定に関する説明を追加しました。正しい方向へのキックにmasterboに感謝します。
odmin4egのバックアップスクリプトの別のバージョン： habrahabr.ru/blogs/s_admin/132302/#comment_4391784

批判を待っています。