Nginx 캐시 구성 계획 및 관련 메모리 사용 문제를 해결하는 방법

nginx 캐시에 대한 5가지 옵션
　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는 일반적으로 none 사용자로 실행되도록 구성되므로 이 두 디렉터리는 물론, 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과 같은 매개변수가 있는 동적 링크는 지원되지 않습니다. system 사용자가 read.php?id=2에 액세스할 때 잘못된 결과가 반환되도록 read.php로 저장합니다. 동시에 nginx는 매우 정직하고 이러한 요청을 링크에 따라 파일 시스템이 변경되고 이 링크는 분명히 디렉토리이므로 저장이 실패합니다. 이러한 경우 올바르게 저장하려면 다시 작성해야 합니다.
단점 2: nginx 내부에는 캐시 만료 및 정리를 위한 메커니즘이 없습니다. 캐시된 파일은 머신에 영구적으로 저장됩니다. 캐시할 항목이 많으면 전체 하드 디스크 공간을 차지하게 됩니다. 이를 위해 쉘 스크립트를 사용하여 정기적으로 정리할 수 있으며, PHP와 같은 동적 프로그램을 작성하여 실시간 업데이트를 수행할 수 있습니다.
　단점 3: 상태 코드는 200개만 캐시할 수 있으므로 백엔드에서 반환된 301/302/404와 같은 상태 코드는 방문 횟수가 많은 의사 정적 링크가 삭제되는 경우 캐시되지 않습니다. , 계속해서 침투하므로 백엔드에 많은 압력이 가해집니다.
　단점 4: nginx는 메모리나 하드 디스크를 저장 매체로 자동 선택하지 않습니다. 물론 현재 운영 체제에는 운영 체제 수준의 파일 캐싱 메커니즘이 있으므로 그럴 필요가 없습니다. 가져오기로 인해 발생하는 성능 문제가 하드 디스크에 저장되어 있는 경우 대량 동시 읽기에 대해 너무 걱정할 필요가 없습니다.
　nginx의 기존 캐싱의 단점도 Squid 등의 캐싱 소프트웨어와는 기능이 다르기 때문에 장점으로도 볼 수 있습니다. 프로덕션 애플리케이션에서는 Squid와 파트너로 사용되는 경우가 많습니다. Squid는 종종 ?가 포함된 링크를 차단할 수 없지만 nginx는 http://jb51.net/? 및 http://jb51과 같은 액세스를 차단할 수 있습니다. net /은 Squid에서 두 개의 링크로 처리되므로 링크가 http://jb51.net/?1 또는 http://jb51.net/?이 되더라도 nginx는 한 번만 저장합니다. 123은 nginx에서 캐시할 수 없으므로 백엔드 호스트를 효과적으로 보호합니다.
　nginx는 링크 형식을 파일 시스템에 매우 충실하게 저장하므로 링크의 경우 캐시 상태와 내용을 캐시 머신에서 쉽게 확인할 수 있고 rsync 등 다른 파일 관리자와도 쉽게 통신할 수 있습니다. 함께 사용하면 완전히 파일 시스템 구조가 됩니다.
　이 두 가지 기존 캐시는 모두 Linux에서 /dev/shm에 파일을 저장할 수 있습니다. 일반적으로 시스템 메모리를 캐싱에 사용할 수 있도록 이렇게 합니다. 메모리를 사용하면 만료 콘텐츠가 훨씬 빨리 정리됩니다. . /dev/shm/을 사용할 때 tmp 디렉토리를 /dev/shm 파티션으로 지정하는 것 외에도 작은 파일과 디렉토리가 많은 경우 inode 수와 이 메모리의 최대 용량도 수정해야 합니다. partition:
　

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

　　 이 명령은 메모리가 3g인 시스템에서 사용됩니다. /dev/shm의 기본 최대 메모리는 시스템 메모리의 절반인 1500m이므로 동시에 이 명령은 메모리를 2500m로 늘립니다. , shm 시스템의 inode 수는 기본적으로 충분하지 않을 수 있지만 흥미로운 점은 여기에서 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 중국어 웹사이트의 기타 관련 기사를 참조하세요!