背景
 
日前服务器一个应用总是莫名挂掉，通过排查发现是老年代内存无法回收引起，那么要定位到到底是那一部分数据导致的无法回收，就需要把堆内存dump出来，然后用工具分析。但奇怪的是dump的时候一直报错
 
 
 
Unable to open socket file: target process not responding or HotSpot VM not lo
 
 
排查完整过程
 
解决方案
 
网上找了很多方案，都没效果，最终通过一些文章的启示，自己找到了解决方案。
 
问题引起的原因
 
由于Linux一切皆文件的特性，也就是说一个Java进程实际上会对应到一个PID文件，dump命令依赖于进程的PID文件，报错这个是由于这个PID文件可能已经被系统给删除了。
 
 
 
linux系统有个删除管理机制：系统每天会用tmpwatch命令检查并删除 /tmp 下超过240小时未访问过的文件和目录。
 
 
问题的解决方案
 
Linux有个文件（/usr/lib/tmpfiles.d/tmp.conf）中记录着一些目录，这些目录中不会被自动删除，我们需要在这个文件中配置我们的JAVA进程的PID目录。
 
第一步：先找到PID所在目录
 先用JPS命令得到进程号
 
 32383为我的JAVA应用的进程号，然后我们去/tmp目录下找这个进程号
 
 很明显这里没有32383，但这里有个hsperfdata_root目录不知道是什么东西，进去看看
 
 这里有31383，那么也就是说/tmp/hsperfdata_root目录即是要排除在外的目录。
 
第二步：把找到的目录添加到文件内容中
 
vi /usr/lib/tmpfiles.d/tmp.conf
 
添加如下内容
 
 /*代表目录下的所有文件，添加之后应该是立即生效的，无需重启。如此，即可避免文件被系统删掉。
 
其他事项
 
以上解决方案是我在我的系统中亲测成功的方案，由于系统版本不同，我的解决办法可能不适用于你，你需要尝试。
 我的Linux内核版本为Linux version 3.10.0-1062.1.1.el7.x86_64
 系统版本为CentOS Linux release 7.5.1804
 我不确定其他系统版本的设置方式是否一致，有的系统可能没有/usr/lib/tmpfiles.d/tmp.conf这个文件，那么可以看看是否存在/etc/cron.daily/tmpwatch这个文件，存在的话可以在这个文件中添加排除项，添加方式与本文一致。
 
如果依然无法解决，可以看看我参考的两篇文章，寻找解决方案。
 
参考
 
https://www.cnblogs.com/vsop/p/10943753.html
 https://blog.51cto.com/zhangshaoxiong/1310166

1、刚开始我以为是batch_size设置问题导致内存溢出，但是仔细观察发现空闲内存大于需要使用的内存,
 解决办法
 卸载torch 当前torch 版本为1.6.0 torchvision版本为0.7.0
 回退到 torch 1.2.0 torchvision 0.4.0
 问题解决

一.Error running ‘JsaasApplication’: Command line is too long. Shorten command line for JsaasApplication or also for Spring Boot default configuration.
 
 
在wordspace.xml中找到下面代码.
 
<component name="PropertiesComponent">
    <property name="WebServerToolWindowFactoryState" value="false" />
    <property name="aspect.path.notification.shown" value="true" />
    <property name="last_opened_file_path" value="$PROJECT_DIR$/.." />
    <property name="nodejs_interpreter_path.stuck_in_default_project" value="undefined stuck path" />
    <property name="nodejs_npm_path_reset_for_default_project" value="true" />
    <property name="project.structure.last.edited" value="Project" />
    <property name="project.structure.proportion" value="0.0" />
    <property name="project.structure.side.proportion" value="0.0" />
    <property name="settings.editor.selected.configurable" value="project.propCompiler" />
  </component>
 
增加<property name="dynamic.classpath" value="true" />即可.
 
二.java.lang.OutOfMemoryError:GC overhead limit exceeded
 
 报错原因:
 内存溢出错误
 举个例子,一个厕所里有五个坑位,有十个人要上厕所,十个人使劲往五个坑位里挤,报错.所以要调整坑位数量,增大堆内存.
 与内存泄漏区别:
 五个坑位中,有两个人拉肚子,一直拉,坑位一直被占用,该部分堆空间一直在被占用即内存泄漏.
 
解决办法:
 调整内存大小从默认700改到2048.
 

 
原因
 
在cli环境下，PHP程序需要长时间运行，客户端与MySQL服务器之间的TCP连接是不稳定的。
 
不稳定的原因有以下可能：
 
MySQL-Server会在一定时间内自动切断连接
PHP程序遇到空闲期时长时间没有MySQL查询，MySQL-Server也会切断连接回收资源
其他情况，在MySQL服务器中执行kill process杀掉某个连接，MySQL服务器重启
网络抖动
 
这时PHP程序中的MySQL连接就失效了。如果仍然执行mysql_query，就会报一个MySQL server has gone away的错误。程序处理不到就直接遇到致命错误并退出了。所以PHP程序中需要断线重连。
 
解决方案
 
mysql_ping
 
有很多人提出了mysql_ping的方案，每次mysql_query进行连接检测或者定时连接检测。
 
这个方案不是最好的。原因是:mysql_ping需要主动侦测连接，带来了额外的消耗。定时执行mysql_ping不能解决问题，如刚刚执行过mysql_ping检测之后，连接就关闭了;
 
捕获错误码，进行断线重连
 
它的原理是：mysql_query执行后检测返回值，如果mysql_query返回失败，检测错误码发现为2006/2013（这2个错误表示连接失败），再执行一次mysql_connect执行mysql_connect后，重新执行mysql_query如果mysql_query返回成功，那么连接是有效的，这是一次正常的调用。
 
众多知名的PHP常驻进程框架
 
swoole_framework中query方法。
 
$res = mysql_query($sql, $this->conn);
if ($res === false)
{
    if (mysql_errno($this->conn) == 2006 or mysql_errno($this->conn) == 2013)
    {
        $r = $this->checkConnection();
        if ($r === true)
        {
            continue;
        }
    }
 
workerman中数据库连接类execute方法。
 
  protected function execute($query, $parameters = "")
    {
        try {
            ...
        } catch (PDOException $e) {
            // 服务端断开时重连一次
            if ($e->errorInfo[1] == 2006 || $e->errorInfo[1] == 2013) {
                $this->closeConnection();
                $this->connect();
            ...
        }
    }
 
很明显捕获错误码，进行断线重连，是高可靠低消耗的方案，推荐大家在常驻环境里使用。
 
thinkphp + phpworkman 使用
 
TP+workman也会出现类似的情况，TP从 V5.0.6+版本开始，支持Mysql的断线重连机制，默认关闭，需要的话，在application/databases.php数据库配置文件中添加
 
// 开启断线重连
'break_reconnect' => true,
 
这样就OK了。
 
转载自：https://my.oschina.net/fage1151/blog/995775