记一次OOM问题排查历程

更新时间:2019-08-14

  能够发觉除了有10008192字节的数组还有10000000字节的数组,查看援用径能够看到这个正好是10M的数组是output buffer,区别于之前看到的input buffer:

  看线程名称该当是tomcat的nio工做线程,线程正在处置法式的时候由于无法正在堆平分配更多内存呈现了OOM,幸亏JVM启动参数设置装备摆设了-:+HeapDumpOnOutOfMemoryError,利用MAT打开拿到的hprof文件进行阐发。

  好吧,这就对了,一个线程分派了输入输出两个buffer,占用20M内存,一共401个线GB,所以OOM了。

  这合适之前的猜测,是tomcat的线M的buffer正在堆上。至此,顿时能够想到必然是什么参数设置的不合理导致了这种环境,一般而言tomcat不成能为每一个请求分派如斯大的buffer。

  至于问题3,明显我们的使用法式是设置装备摆设过最大线程的(查看设置装备摆设后发觉简直,我们设置装备摆设为了2000,好吧有点大),不然也不会有401个工做线),若是其时并发并不大的话就一种可能,请求很慢,虽然并发不大,可是由于请求施行的慢就需要更多线s的线线程了。这个问题的谜底仍是能够通过MAT去找,随便看几个线程能够发觉良多线程都正在期待一个外部办事的前往,这申明外部办事比力慢,去搜刮其时的法式日记能够发觉有良多feign.RetryableException: Read timed out executing的日记。。。。逃杀下逛去!慢点,我们的feign的timeout也需要再去设置一下,别被外部办事拖死了。