Nginx キャッシュの構成計画と、関連するメモリ使用量の問題を解決する方法

5 nginx キャッシュのオプション
1. 従来のキャッシュの 1 つ (404)
この方法では、nginx の 404 エラーをバックエンドに送信し、proxy_store を使用して返されたページは保存されます。
設定:

　　location / {
　　root /home/html/;#主目录
　　expires 1d;#网页的过期时间
　　error_page 404 =200 /fetch$request_uri;#404定向到/fetch目录下
　　}
　　location /fetch/ {#404定向到这里
　　internal;#指明这个目录不能在外部直接访问到
　　expires 1d;#网页的过期时间
 alias /html/;
 proxy_store会将文件保存到这目录下
　　proxy_pass//www.jb51.net/;#后端upstream地址，/fetch同时是一个代理
　　proxy_set_header accept-encoding '';#让后端不要返回压缩（gzip或deflate）的内容，保存压缩后的内容会引发乱子。
　　proxy_store on;#指定nginx将代理返回的文件保存
　　proxy_temp_path /home/tmp;#临时目录，这个目录要和/home/html在同一个硬盘分区内

　　}

使用する場合、nginx には /home/tmp および /home/html へのファイルの書き込み権限が必要であることに注意してください。Linux では、nginx は通常、は、nobody ユーザーとして実行するため、これらの 2 つのディレクトリは、nobody として chown し、nobody ユーザー専用に設定する必要があります。もちろん、chmod 777 を使用することもできますが、経験豊富なシステム管理者は、気軽に 777 を使用しないことをお勧めします。
2. 従来のキャッシュ 2 (!-e)
原理は基本的に 404 ジャンプと同じですが、より簡潔です:

　　location / {
　　root /home/html/;
　　proxy_store on;
　　proxy_set_header accept-encoding '';
　　proxy_temp_path /home/tmp;
　　if ( !-f $request_filename )
　　{
　　proxy_pass//www.jb51.net/;
　　}
　　}

をご覧ください。この構成では 404 と比較して多くのコードが節約されます。!-f を使用して、要求されたファイルがファイル システムに存在するかどうかを確認します。存在しない場合は、バックエンドに proxy_pass し、戻り値も proxy_store を使用して保存されます。
どちらの従来のキャッシュにも、基本的に同じ長所と短所があります。
短所 1: nginx はファイル名のみを保存するため、read.php?id=1 などのパラメータを使用した動的リンクはサポートされていないため、このリンクのみが保存されます。ファイル システムに read.php として保存すると、ユーザーが read.php?id=2 にアクセスしたときに誤った結果が返されます。同時に、nginx は非常に正直であり、そのようなリクエストをリンクによるとファイルシステム、そしてこれは明らかにディレクトリであるため、保存は失敗します。このような場合、正しく保存するには書き直す必要があります。
欠点 2: nginx 内にはキャッシュの有効期限とクリーンアップのメカニズムがありません。これらのキャッシュされたファイルはマシンに永続的に保存されます。キャッシュするものがたくさんあると、ハードディスクの容量全体がいっぱいになってしまいます。この目的のために、シェル スクリプトを使用して定期的にクリーンアップしたり、php などの動的プログラムを作成してリアルタイム更新を行うことができます。
デメリット3: ステータスコードは200個までしかキャッシュできないため、バックエンドから返される301/302/404などのステータスコードはキャッシュされない アクセス数の多い擬似静的リンクがたまたま削除された場合、貫通すると後端にかなりの圧力がかかります。
欠点 4: nginx はストレージ メディアとしてメモリまたはハードディスクを自動的に選択しません。すべては構成によって決まります。もちろん、現在のオペレーティング システムにはオペレーティング システム レベルのファイル キャッシュ メカニズムが存在します。ハード ディスク上のファイル キャッシュについてあまり心配する必要はありません。同時読み取りによって引き起こされる IO パフォーマンスの問題。
nginx の従来のキャッシュの欠点は、squid などのキャッシュ ソフトウェアとは異なる特徴でもあるため、利点とも言えます。運用アプリケーションでは、Squid のパートナーとして使用されることが多く、Squid は ? によるリンクをブロックできないことがよくありますが、nginx は http://jb51.net/? や http://jb51 などのアクセスをブロックできます。 net / は Squid 上で 2 つのリンクとして扱われるため、2 回の侵入が発生します。リンクが http://jb51.net/?1 または http://jb51.net/? になっても、nginx はそれを 1 回だけ保存します。 123 は nginx でキャッシュできないため、バックエンド ホストを効果的に保護します。
nginx は、リンク フォームをファイル システムに非常に忠実に保存するため、リンクについては、キャッシュ マシン上のキャッシュ ステータスとコンテンツを簡単に確認でき、また、使用されているファイル マネージャーなどの他のファイル マネージャーと簡単に通信することもできます。 rsync などと組み合わせると、完全にファイル システム構造になります。
これら 2 つの従来のキャッシュはどちらも、Linux ではファイルを /dev/shm に保存できます。通常、これを行うのは、システム メモリをキャッシュに使用できるようにするためです。メモリが使用されている場合、有効期限のコンテンツはクリーンアップされます。より速く、さらに多くのことを実現します。 /dev/shm/ を使用する場合、tmp ディレクトリを /dev/shm パーティションに指定するだけでなく、小さなファイルやディレクトリが多数ある場合は、inode の数とこのメモリの最大容量も変更する必要があります。パーティション:

　mount -o size=2500m -o nr_inodes=480000 -o noatime,nodiratime -o remount /dev/shm

上記のコマンドは、3g のメモリを備えたマシンで使用されています。/dev/shm のデフォルトの最大メモリはシステム メモリの半分である 1500m であるため、このコマンドは増加します同時に、shm システム i ノードの数はデフォルトです。場合によっては十分ではないかもしれませんが、興味深いのは、自由に調整できることです。ここでの調整は 480000 です。保守的ですが、基本的には十分です。
3. memcached ベースのキャッシュ
nginx は memcached をある程度サポートしていますが、機能はそれほど強力ではなく、パフォーマンスは依然として非常に優れています。

　location /mem/ {
　　if ( $uri ~ "^/mem/([0-9a-za-z_]*)$" )
　　{
　　set $memcached_key "$1";
　　memcached_pass  192.168.1.2:11211;
　　}
　　expires 70;
　　}

　　这个配置会将http://jb51.net/mem/abc指明到memcached的abc这个key去取数据。
　　nginx目前没有写入memcached的任何机制，所以要往memcached里写入数据得用后台的动态语言完成，可以利用404定向到后端去写入数据。
　　4、基于第三方插件ncache
　　ncache是新浪兄弟开发的一个不错的项目，它利用nginx和memcached实现了一部分类似squid缓存的功能，我并没有使用这个插件的经验，可以参考：
　　http://code.google.com/p/ncache/
　　5、nginx新开发的proxy_cache功能
　　从nginx-0.7.44版开始，nginx支持了类似squid较为正规的cache功能，目前还处于开发阶段，支持相当有限，这个缓存是把链接用md5编码hash后保存，所以它可以支持任意链接，同时也支持404/301/302这样的非200状态。
　　配置：
　　首先配置一个cache空间：

复制代码 代码如下:

　　proxy_cache_path /path/to/cache levels=1:2 keys_zone=name:10m inactive=5m max_size=2m clean_time=1m;

　　注意这个配置是在server标签外，levels指定该缓存空间有两层hash目录，第一层目录是1个字母，第二层为2个字母，保存的文件名就会类似/path/to/cache/c/29/b7f54b2df7773722d382f4809d65029c；keys_zone为这个空间起个名字，10m指空间大小为10mb；inactive的5m指缓存默认时长5分钟；max_size的2m是指单个文件超过2m的就不缓存；clean_time指定一分钟清理一次缓存。

　　location / {
　　proxy_pass//www.jb51.net/;
　　proxy_cache name;#使用name这个keys_zone
　　proxy_cache_valid 200 302 1h;#200和302状态码保存1小时
　　proxy_cache_valid 301 1d;#301状态码保存一天
　　proxy_cache_valid any 1m;#其它的保存一分钟
　　}

　　ps：支持cache的0.7.44到0.7.51这几个版本的稳定性均有问题，访问有些链接会出现错误，所以这几个版本最好不要在生产环境中使用。nginx-0.7下目前所知较为稳定的版本是0.7.39。稳定版0.6.36版也是近期更新，如果在配置里没有使用到0.7的一些新标签新功能，也可以使用0.6.36版。

nginx缓存的内存占用问题的一般解决方法
1、前些日子某服务被刷，每分钟达到上几百万请求；当时采用了nginx cache来解决的；但是因为某服务不能缓存太久，当时设置了5s，那么带来的问题就是产生大量小文件，而且很快就删除了。

2、通过

free -m

会发现used是27g；但是通过top查看进程占的内存并没有那么多

那内存去哪了？

3、通过查阅资料会发现(cat /proc/meminfo)
slab: 22464312 kb
sreclaimable: 16474128 kb （这些是内核保持的但是可以释放的inode和dentry的缓存）
sunreclaim: 5990184 kb

4、这些内存为什么会不自动清理呢？
某机房机器系统版本：linux 2.6.32-431.el6.x86_64 #1 smp fri nov 22 03:15:09 utc 2013 x86_64 x86_64 x86_64 gnu/linux（正常，没出现内存快到100%的情况）
某机房机器系统版本：linux 2.6.32-279.el6.x86_64 #1 smp fri jun 22 12:19:21 utc 2012 x86_64 x86_64 x86_64 gnu/linux （不释放）

5、通过设置如下参数来设置内存阀值

sysctl -w vm.extra_free_kbytes=6436787
sysctl -w vm.vfs_cache_pressure=10000

以上がNginx キャッシュの構成計画と、関連するメモリ使用量の問題を解決する方法の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。