记录一下关于connection reset by peer的错误问题解决

java.io.IOException: Connection reset by peer at sun.nio.ch.FileDispatcherImpl.read0(Native Method) at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39) at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223) at sun.nio.ch.IOUtil.read(IOUtil.java:197) at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:380) at com.wanyu.smarthome.gateway.EquipmentSocketServer.handleReadEx(EquipmentSocketServer.java:245) at com.wanyu.smarthome.gateway.EquipmentSocketServer.run(EquipmentSocketServer.java:115)

 

当时遇到这个问题，也没百度，重启了一下服务器，结果发现问题解决了

第二天又出现了，因为公司任务紧，也没去怎么花时间解决，只是百度了一番，没发现啥好的解决方案，应该是我这个问题和百度的问题不一样的吧，所以怎么试都是一样的，解决不了，最后重启一下又好了

第三天又复现了，还是直接重启，不管，等到了下午，公司任务完成了，再回到这个问题上，仔细一看，也不是整个项目不可用，只是部分接口报这个错，因为那几个报错的接口都是几个表关联查询的，而且每天第一次报错的时候，数据库的CPU使用达到了40%，而平常CPU使用率只有10%不到，第一反应就是会不会因为慢SQL导致的，但是本地跑项目的时候又都正常，而且项目也在线上跑了几个月了，不应该呀，然后就是各种百度各种谷歌，说的都差不多，然后就翻日志，找找报错的时候都执行了哪些代码，会不会是内存泄漏等问题，又百度了一波，还是没解决

最后看见前端报的是：

net::ERR_INCOMPLETE_CHUNKED_ENCODING 200 (OK) 

又百度了一波，发现有个人说的好像有点对头：网址https://blog.csdn.net/zhan107876/article/details/105041417

然后又查了一波nginx的配置，也没发现问题，最后看了一下nginx日志，发现了问题，nginx日志一直报错

pwritev() "/etc/nginx/proxy_temp/0/81/0000160810" failed (28: No space left on device)

翻译了一下说是磁盘空间不足，一查确实是，找到源头了就好办，原来系统日志文件没有清除，占了60个G的磁盘空间，把日志文件删掉，再看，解决了

# 检查磁盘情况 $ df -h

# 检查文件占用情况 $ du -hd 1