Mar 2, 2020 - 프로세스 재시작 version 2

프로세스가 살아있는지 확인하고, 해당 프로세스를 다시 실행시키는 쉘 스크립트 입니다. 해당 스크립트가 있는 곳으로 cd 로 경로로 이동한 후에 쉘스크립트를 실행시킵니다.

#!/bin/bash

DATE=`date +%Y%m%d-%H%M`

LOGGING_1=`ps ax | grep java | grep -i xxxx1-0.0.1-SNAPSHOT-real.jar | grep -v grep | awk '{print $1}'`
LOGGING_2=`ps ax | grep java | grep -i xxxx2-0.0.1-SNAPSHOT-real.jar | grep -v grep | awk '{print $1}'`

if [ -z ${LOGGING_1} ]; then
        cd /home/xxxx/xxxx/xxxx1/logging
        sh /home/xxxx/xxxx/xxxx1/xxxx1_consumer_start.sh &
        echo "$DATE - xxxx1-0.0.1-SNAPSHOT-real.jar start" >> /root/shell/log/logging_check.log
fi

if [ -z ${LOGGING_2} ]; then
        cd /home/xxxx/xxxx2/xxxx2/logging
        sh /home/xxxx/xxxx2/xxxx2/xxxx2_consumer_start.sh &
        echo "$DATE - xxxx2-0.0.1-SNAPSHOT-real.jar start" >> /root/shell/log/logging_check.log
fi

해당 경로로 이동한 후 쉘스크립트 실행, 이렇게 처리하는 이유가, crontab 에서, 해당 스크립트의 실행할때, 스크립트가 jar파일의 경로를 찾지 못하는 경우가 있는 오류가 있어서 그렇습니다.

#!/bin/sh

nohup java -Xms4g -Xmx4g -XX:+UseG1GC -server -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9994 -Djava.rmi.server.hostname=xx.xx.xx.xx -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -jar xxxxx-logging-0.0.1-SNAPSHOT-real.jar >/dev/null 2>&1

crontab 에 등록하여 동작시키면, 스크립트가 백그라운드로 실행됩니다.

ps : 앞서 작성한 [프로세스 재시작]:(https://youngclown.github.io/2020/02/batch_shell) 에서 제대로 된 jar파일이 실행안되는 문제가 발생하여 처리함.

Feb 4, 2020 - 프로세스 재시작

#!/bin/bash

DATE=`date +%Y%m%d-%H%M`

LOGGING_1=`ps ax | grep java | grep -i xxxx1-0.0.1-SNAPSHOT-real.jar | grep -v grep | awk '{print $1}'`
LOGGING_2=`ps ax | grep java | grep -i xxxx2-0.0.1-SNAPSHOT-real.jar | grep -v grep | awk '{print $1}'`

if [ -z ${LOGGING_1} ]; then
        sh /home/xxxx/xxxx/xxxx1/xxxx1_consumer_start.sh &
        echo "$DATE - xxxx1-0.0.1-SNAPSHOT-real.jar start" >> /root/shell/log/logging_check.log
fi

if [ -z ${LOGGING_2} ]; then
        sh /home/xxxx/xxxx2/xxxx2/xxxx2_consumer_start.sh &
        echo "$DATE - xxxx2-0.0.1-SNAPSHOT-real.jar start" >> /root/shell/log/logging_check.log
fi

프로세스에서 해당 프로세스가 없을 시 재시작하도록 하도록 쉘스크립트 생성

ps : 해당 쉘스크립트가 경로를 찾지 못해 cd 로 해당 파일 이동 후 jar파일을 재실행하도록 함. [프로세스 재시작]:(https://youngclown.github.io/2020/02/batch_shell_1) 에 이동할 하는 쉘스크립트 추가하여, 크론탭에 등록하여 사용하였습니다.

Dec 16, 2019 - jvm 옵션 관리

jvm 옵션은 기본옵션을 유지하는 것이 좋다고 하여, 옵션을 안건드렸으나,

ehcache의 내부 메모리의 크기가 기하급수적으로 증가하는 로직이 하나가 추가되면서, 서버에 부하가 생기게 되었습니다.

서버 장애원인을 찾아보니,

ehcache가 잡아먹는 JVM 의 메모리에 의해, 강제 FULL GC가 발생하고, 그 발생한 부분의 지연현상때문에, 전체적인 서비스가 지연되는 문제였습니다.

java version 은 1.8 을 사용하고 있었는데,
JDK8 에서는 Default 로 ‘Parallel GC’ 를 사용합니다.

그래서, 결국 jvm 옵션을 건드릴 수 밖에 없었습니다.

-XX:+UseG1GC

G1 GC의 가장 큰 장점은 성능입니다.

JAVA_OPTS="-verbosegc -server -Xms6g -Xmx6g -XX:MaxGCPauseMillis=700 -XX:+PrintConcurrentLocks -Djava.security.egd=file:/dev/./urandom -Dscouter.config=/usr/local/tomcat7/conf/scouter.conf -Duser.timezone=GMT+09:00 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/usr/local/tomcat7/logs/memory_err.log"

기존 옵션에서 ‘-XX:+UseG1GC’ 만 추가하였습니다.

JDK 8 부터 G1 이 안정적이 되었기에 많은 서비스들이 G1 GC 를 사용 중으로 알고 있습니다.
(JDK8 에서는 Default 로 ‘Parallel GC’ 를 사용하기 때문에 G1 GC를 사용하지 않습니다. )

‘Parallel Collector’ 는 Compaction 단계 때문에 G1 GC 보다 FGC (Full Gabage Collection) 시간이 오래 걸리며,
실제 제 서비스에서는 점점 GC시간이 늘어나는 상태였습니다.

JAVA_OPTS="-verbosegc -server -Xms9216m -Xmx9216m -XX:NewRatio=5  -XX:+UseParNewGC -XX:+CMSParallelRemarkEnabled -XX:+UseConcMarkSweepGC -XX:MaxTenuringThreshold=0 -XX:CMSInitiatingOccupancyFraction=75 -Djava.security.egd=file:/dev/./urandom -Dscouter.config=/usr/local/tomcat7/conf/scouter.conf -Duser.timezone=GMT+09:00 -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/usr/local/tomcat7/logs/memory_err.log"

현재 75% 로 GC가 강제로 찾을 경우 강제 GC를 떨어뜨니는 기능과 단순하게 G1GC 나머지는 디폴트값으로 설정하는 것과 비교할 예정이며, 현재로써는 G1GC 로 하는것이 개인적으로 관리할때는 편해보여, 상태를 보다가 전체 적용할 예정입니다.

©2025 bymin. Powered by Jekyll, theme by Scott Emmons under Creative Commons Attribution