网站访问量很小的时候，页面报504 Gateway Time-out

查看服务器发现内存空闲空间free很小，但是buff/cache很高

可以通过此工具来查看buff/cache高的进程：

https://www.cnblogs.com/zh94/p/11922714.html

怀疑是缓冲区的数据没有及时写入磁盘，可能是缓冲区的数据，没有被相应程序使用，导致一直存在于缓冲区，服务器内存不够导致nginx无法提供服务（因为nginx本身也是需要用到缓冲区的）而现在空闲的内存已经不够用了；

其实：buffers/cache占用的较多，说明系统中有进程曾经读写过文件，但是不要紧，这部分内存是当空闲来用的

Linux内核会在内存将要耗尽的时候，触发内存回收的工作，以便释放出内存给急需内存的进程使用。一般情况下，这个操作中主要的内存释放都来自于对buffer／cache的释放。尤其是被使用更多的cache空间。既然它主要用来做缓存，只是在内存够用的时候加快进程对文件的读写速度，那么在内存压力较大的情况下，当然有必要清空释放cache，作为free空间分给相关进程使用。所以一般情况下，我们认为buffer/cache空间可以被释放，这个理解是正确的。

但是这种清缓存的工作也并不是没有成本。理解cache是干什么的就可以明白清缓存必须保证cache中的数据跟对应文件中的数据一致，才能对cache进行释放。所以伴随着cache清除的行为的，一般都是系统IO飙高。因为内核要对比cache中的数据和对应硬盘文件上的数据是否一致，如果不一致需要写回，之后才能回收。

在系统中除了内存将被耗尽的时候可以清缓存以外，我们还可以使用下面这个文件来人工触发缓存清除的操作,或者写成定时任务：

echo 1 > /proc/sys/vm/drop_caches:表示清除pagecache。
echo 2 > /proc/sys/vm/drop_caches:表示清除回收slab分配器中的对象（包括目录项缓存和inode缓存）。slab分配器是内核中管理内存的一种机制，其中很多缓存数据实现都是用的pagecache。
echo 3 > /proc/sys/vm/drop_caches:表示清除pagecache和slab分配器中的缓存对象。

用sync强制将缓冲区的内容写入后还是没变化，继续查找

发现redis的Recv-Q很高（非0状态，正常一般为0）

recv-Q 表示网络接收队列
表示收到的数据已经在本地接收缓冲，但是还有多少没有被进程取走，recv()
如果接收队列Recv-Q一直处于阻塞状态，可能是遭受了拒绝服务 denial-of-service 攻击。

send-Q 表示网路发送队列
对方没有收到的数据或者说没有Ack的,还是本地缓冲区.
如果发送队列Send-Q不能很快的清零，可能是有应用向外发送数据包过快，或者是对方接收数据包不够快。

这两个值通常应该为0，如果不为0可能是有问题的。packets在两个队列里都不应该有堆积状态。可接受短暂的非0情况。

从图中可以看到是大量的 send-Q ,可以判定是发送数据给目的地址的时候出现了阻塞的问题，导致了包堆积在本地缓存中，不能成功发出去。

那么问题就产生在了客户端，根据公司的业务逻辑发现是客户端发送的TCP长连接数量过多。

经后面排序是有一个程序循环执行没有给等待时间，同时在写redis,kill掉redis进程

修改redis配置(/etc/redis/6379.conf)，将stop-writes-on-bgsave-error 设为no

同时优化程序(usleep一定时间)

重启 redis 解决问题

重启后 Recv-Q正常