자세한 정보 감사합니다. 이렇게 해주셔서 다행입니다.
하지만 이 작업을 수행해도 다음 재부팅까지만 효과가 있을 것으로 보입니다. 재부팅 후에도 다시 실행해야 합니다. 이를 영구적으로 설정하는 방법에 대한 팁은 MKJ’s Opinionated Discourse Deployment Configuration에서 확인해 보세요.
메모리(RAM+스왑)가 부족할 가능성이 있어 보입니다. 다만 2+4라면 충분해야 합니다. 다음 간단한 진단 명령을 실행한 후 결과를 공유해 주세요:
cat /etc/lsb-release
uptime
df -h /
free
swapon
vmstat 5 5
dmesg|egrep -i "memory|oom|kill"
ps auxrc
app.yml 파일도 여기에 공유해 주십시오. 단, 파일 내부의 비밀번호와 시크릿 토큰은 제외해야 합니다!
두 개의 SSH 연결을 설정할 수 있다면, 한 연결에서는 앱 재빌드를 실행하고 다른 연결에서는 시스템이 어떤 일을 하고 있는지 관찰할 수 있습니다. 저는 다음과 같이 번갈아 가며 확인하는 것을 선호합니다.
vmstat 5 5
ps auxrc
원격 디스크(네트워크 연결 저장소)로 스왑을 하고 있을 수도 있으며, 이는 잘 알려진 문제입니다. 속도가 매우 느려집니다. 이로 인해 타임아웃이 발생하여 문제가 생기는 것일 수 있습니다. 타임아웃을 조정할 수 있는 방법이 있을지도 모릅니다.
이 글을 찾았는데 도움이 될까요?
(일부 systemd 릴리스의 경우 기본 systemd 타임아웃은 90초이므로, 이는 꽤 잘 맞습니다).
postgresql의 systemd 유닛(또는 전역적으로)에서 TimeoutStartSec를 늘려서 이 문제를 우회해 볼 수 있지만, 이는 아마도 다음에 서비스가 갑자기 시작되지 않을 때까지 문제를 가리는 것에 불과할 것입니다.
수정: 만약 그렇다면 이 조언이 좋을 수 있습니다:
/etc/systemd/system.conf에서 다음 줄의 주석을 해제할 수 있습니다:DefaultTimeoutStartSec=90s DefaultTimeoutStopSec=90s그리고 적절한 값으로 변경하십시오.