我在国外的服务器上部署了halo,然后发现它一直莫名其妙就不在后台运行了,需要我重新打开,我刚开始以为是我的服务器配置低,默认分配的资源太少,后来加了一些参数,还是会出现这种问题,求大佬解答。
我的服务器配置:
中央处理器:1个vCore
内存:1024兆字节
存储:25 GB固态硬盘
启动参数,该开始是直接
nohup Java -jar halo-1.4.1.jar > /dev/null 2>&1 &
后来改成了nohup java -server -Xms400m -Xmx500m -XX:PermSize=256m -XX:MaxPermSize=256m -XX:+PrintGCDateStamps -XX:+PrintGCDetails -Xloggc:log/gc.log -jar halo-1.4.1.jar > /dev/null 2>&1 &
依然会出现莫名其妙停止的问题。(好像加了 -server -Xms400m -Xmx500m -XX😛ermSize=256m -XX:MaxPermSize=256m -XX:+PrintGCDateStamps -XX:+PrintGCDetails -Xloggc:log/gc.log 这些后项目挂掉的更快了)
查看/root/.halo/logs/spring.log
日志最后是没有报错的。中间有一些报错,但是项目没有挂掉。
我的配置文件中放开了MySQL数据库,用的MySQL数据库。其的配置应该没有没有修改了。
还有的话就是我用了trojan 科学 shang wang
trojan的 443端口指向 halo的80端口

后台启动建议使用 systemctl。
可以查看 进阶配置
java这里1h1g的服务器建议 设置为 -Xms256m -Xmx256m。

    Takagi 6216 我想问一下 ,我用的是Java8 ,1G内存的话,Java8 默认的话最高好像分配的就是服务器内存的1/4,也就是说我刚开始使用
    nohup Java -jar halo-1.4.1.jar > /dev/null 2>&1 &
    这时候其实相当于加了-Xmx256m 的呀,还有我如果分配给他更多的资源500M,应该也不会导致它挂得更快吧。
    我试试你的建议吧,看看会不会有改变。

      lushenghen
      嗯。 如果只有halo的话,应该不会出现经常挂掉的情况,使用systemctl后有没有再挂过?可以观察你的服务器内存波动吧。也可以使用虚拟内存

        Takagi ![我现在使用的是你说的systemctl,暂时没有发现问题,我之前看过服务器的CPU,没有满呀,一般就是20%,最高就是80%(不知道那个时候为什么这么高),就譬如今天挂掉的时间内,CPU没超过40%的

          lushenghen 嗯,使用nohup应该有打印日志的吧,先看看程序的问题,是程序自己死掉的,还是被系统kill掉的

            Takagi 之前用nohup打印过,如果被系统kill掉的,最后应该会打印killed这句话吧,但是我在nohup打印的日志里面没有看到这句话。

            我的弱鸡也被安排了。你可以通过一下命令得到答案:

            $ dmesg | grep java
            [319557.950013] [  15353]  1000 15353   715358   194472  2015232        0             0 java
            [319557.950097] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/,task=java,pid=15353,uid=1000
            [319557.950211] Out of memory: Killed process 15353 (java) total-vm:2861432kB, anon-rss:777888kB, file-rss:0kB, shmem-rss:0kB, UID:1000 pgtables:1968kB oom_score_adj:0
            [319557.971155] oom_reaper: reaped process 15353 (java), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
            [641165.073405] [  23718]  1000 23718   711815   189519  1961984        0             0 java
            [641165.073456] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/,task=java,pid=23718,uid=1000
            [641165.073596] Out of memory: Killed process 23718 (java) total-vm:2847260kB, anon-rss:758076kB, file-rss:0kB, shmem-rss:0kB, UID:1000 pgtables:1916kB oom_score_adj:0
            [641165.103525] oom_reaper: reaped process 23718 (java), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
            [1006340.764289] [  19913]  1000 19913   717073   188892  2007040        0             0 java
            [1006340.764324] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/,task=java,pid=19913,uid=1000
            [1006340.764424] Out of memory: Killed process 19913 (java) total-vm:2868292kB, anon-rss:755568kB, file-rss:0kB, shmem-rss:0kB, UID:1000 pgtables:1960kB oom_score_adj:0
            [1006340.817200] oom_reaper: reaped process 19913 (java), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB

            我怀疑是类存泄漏,接下来会仔细分析一下。

              johnniang 我这边打印好像也有内存不足。
              # dmesg | grep java
              [235872.528471] [ 24683] 0 24683 637039 105266 1073152 0 0 java
              [235872.528494] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/user.slice/user-0.slice/session-78.scope,task=java,pid=24683,uid=0
              [235872.528665] Out of memory: Killed process 24683 (java) total-vm:2548156kB, anon-rss:421064kB, file-rss:0kB, shmem-rss:0kB, UID:0 pgtables:1048kB oom_score_adj:0
              [235872.612190] oom_reaper: reaped process 24683 (java), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
              [237783.912359] [ 25478] 0 25478 634694 100217 1085440 0 0 java
              [237783.912380] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/user.slice/user-0.slice/session-85.scope,task=java,pid=25478,uid=0
              [237783.912486] Out of memory: Killed process 25478 (java) total-vm:2538776kB, anon-rss:400868kB, file-rss:0kB, shmem-rss:0kB, UID:0 pgtables:1060kB oom_score_adj:0
              [237783.960776] oom_reaper: reaped process 25478 (java), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB

              Ryan Wang 👍 大佬,我用johnniang大佬的命令dmesg | grep java打印出来有oom-kill,这样子是否说明是halo内存泄漏呢?

                lushenghen 并不能完全说明是halo的问题。
                被系统oom有很多种情况,大致下面这样:

                1. 比如你系统内存占用过高(被其他应用),结果halo刚启动,在短时间内占用了大量内存,权重过高,oom这时候就会kill掉halo
                2. 这次就是halo的问题,halo运行了不少时间了,但内存过高且无法被回收,权重过高,被oom kill掉

                当然前提是,你这个kill的是java,并且pid是你的halo程序。
                在1H1G的服务器下,把halo最大内存设置为256MB就行。目前我在我的服务器上部署了好几个服务(两个Java,一个Node),但halo从来没崩过。可能是你进行的某些操作正好是halo内存泄露的地方

                  Takagi 我的CPU 占用我觉得挺低的。
                  CPU.PNG
                  这个是我现在的cpu使用率,时间不太对是因为硅谷时间与国内时间,某些时刻突然变高也不知道怎么回事。平时就不到20%,
                  我现在用你说的将halo设为service,用systemctl来开启,昨天到现在暂时没有发现挂掉的情况。

                  Takagi 我的这个服务器就只有一个halo,MySQL,trojan,其他的没有了。

                    Takagi ALL.PNG
                    尴尬,之前有次评论说错了,把cpu 和内存说混了,我用的vultr服务商,它监控面板看不到内存