一.问题背景
背景是很早之前的项目，前端突然反馈某个POST接口保存特定的内容会报500，没有返回内容，记录一下定位问题的过程。
二.定位问题的过程
1.结合请求数据来看长度大概为15000+，首先想到是数据库字段长度问题。
查询后发现比较长的字段定义的是text类型， 最大长度为65,535(2的16次方–1)字符，排除这种猜想。
2.怀疑是后端接口逻辑的问题。（运行了几年都没问题，大概率不是）
写了个单元测试，模拟用户信息，然后用相同的数据去请求相关的方法，没有问题，排除接口逻辑问题。
3.怀疑是框架是否对post接口请求数据量做了限制。（因为这个接口正常业务应该只会接受10k以下的数据）
用的pigx框架，排查了请求链路涉及的所有服务，未发现有maxPostSize、max-http-post-size的相关配置，排除框架限制问题。
4.回到数据量问题上。
使用postman模拟请求，将入参特定字段分别以“aaaaaa”的形式定长8000和12000进行请求，发现8000数据可以请求正常，12000不行，那么就确定了是post数据量问题。
5.后端已经排查过了，是否是nginx限制post请求问题。
Tomcat 默认Post请求的数据大小是 2M , Nginx默认Post请求的数据大小是 1M , 超过这个数据量的请求会被直接拒绝，但是目前的界限在10k，我查询了nginx.conf中client_max_body_size，client_body_buffer_size的大小，发现限制大小的参数为2000M（虽然不是很合理，但是并不是这项配置的问题）。
6.基本能确定是nginx的问题，但是不知道问题出在哪里。
查询nginx的assess.log和error.log，看看报错信息相关的日志。
发现nginx日志信息打印了22G，我的天，突然好像理顺了问题的原因，连忙看了下服务器的内存：
7.最终原因：磁盘满了！！！！
nginx在转发数据超过10k以上需要借助磁盘空间，刚好今天上午磁盘才满，所以查ngnix报错日志只截止到今天上午，也查不出来相关的报错信息。当然，问题找到了就好解决：
把nginx的assess.log和error.log都删了，然后重启nginx，磁盘空间释放，重新测试相关接口返回正常，搞定！
三.总结
最后真正找到的原因感觉中间做了好多无用功，但是很多异常的情况需要一步步的落实，解决问题并不耗时，耗时的是如何定位问题。
来源地址：https://blog.csdn.net/xinleiweikai/article/details/131709598
