문제 상황

최근 Tomcat에서 애플리케이션을 실행하던 중, JVM 메모리 관련 에러로 인해 애플리케이션이 정상적으로 작동하지 않는 문제가 발생했습니다. 아래는 당시 발생한 에러 메시지입니다:

 

NOTE: Picked up JDK_JAVA_OPTIONS:  --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.io=ALL-UNNAMED --add-opens=java.base/java.util=ALL-UNNAMED --add-opens=java.base/java.util.concurrent=ALL-UNNAMED --add-opens=java.rmi/sun.rmi.transport=ALL-UNNAMED
OpenJDK 64-Bit Server VM warning: INFO: os::commit_memory(0x0000000600000000, 8589934592, 0) failed; error='Not enough space' (errno=12)
#
# There is insufficient memory for the Java Runtime Environment to continue.
# Native memory allocation (mmap) failed to map 8589934592 bytes for committing reserved memory.
# An error report file with more information is saved as:
# /home/project/apache-tomcat-9.0.54/bin/hs_err_pid23479.log

 

이 메시지는 다음을 나타냅니다:

  • JVM이 8GB의 메모리를 요청했으나, 서버의 물리 메모리가 부족하여 요청이 거부되었습니다.
  • 물리 메모리(7.7GB)가 JVM이 요청한 메모리보다 적었기 때문에, 시스템이 더 이상 JVM의 메모리 요청을 처리할 수 없었습니다.

원인 분석

  1. JVM 메모리 설정 과도
    Tomcat에서 JVM 힙 메모리 설정이 기본값보다 과도하게 높게 설정되어 있었습니다:
    • 초기 힙 메모리(-Xms): 8GB
    • 최대 힙 메모리(-Xmx): 8GB
  2. 물리 메모리 초과
    서버의 물리 메모리(7.7GB)가 JVM 메모리 설정을 감당할 수 없었기 때문에, JVM이 실행 중 메모리 할당 에러를 발생시켰습니다.

문제의 기존 설정

Tomcat의 setenv.sh 파일에 다음과 같은 JVM 메모리 설정이 있었습니다

export CATALINA_OPTS="$CATALINA_OPTS -Xms8192m"
export CATALINA_OPTS="$CATALINA_OPTS -Xmx8192m"
export CATALINA_OPTS="$CATALINA_OPTS -XX:NewSize=4096m"
export CATALINA_OPTS="$CATALINA_OPTS -XX:MaxNewSize=4096m"

 

해결 과정

이 문제를 해결하기 위해 다음과 같이 setenv.sh 파일을 수정했습니다:

수정된 setenv.sh 내용

# 기존 JVM 옵션 (주석 처리)
# export CATALINA_OPTS="$CATALINA_OPTS -Xms8192m"
# export CATALINA_OPTS="$CATALINA_OPTS -Xmx8192m"
# export CATALINA_OPTS="$CATALINA_OPTS -XX:NewSize=4096m"
# export CATALINA_OPTS="$CATALINA_OPTS -XX:MaxNewSize=4096m"

# 새로운 JVM 메모리 옵션 설정
export CATALINA_OPTS="$CATALINA_OPTS -Xms2g"
export CATALINA_OPTS="$CATALINA_OPTS -Xmx4g"
export CATALINA_OPTS="$CATALINA_OPTS -XX:NewSize=512m"
export CATALINA_OPTS="$CATALINA_OPTS -XX:MaxNewSize=1024m"

변경된 설정

  • 초기 힙 메모리(-Xms): 8GB → 2GB
  • 최대 힙 메모리(-Xmx): 8GB → 4GB
  • Young Generation 초기 크기(-XX:NewSize): 4GB → 512MB
  • Young Generation 최대 크기(-XX:MaxNewSize): 4GB → 1GB

 

설정 확인

JVM 메모리 옵션 확인

Tomcat이 올바르게 설정되었는지 확인하려면 아래 명령어를 사용하세요

jps -lvm

#결과 예시
15190 org.apache.catalina.startup.Bootstrap start -Xms2g -Xmx4g -XX:NewSize=512m -XX:MaxNewSize=1024m

 

결론

이 과정을 통해 Tomcat의 JVM 메모리 설정을 서버 환경에 맞게 조정하였습니다. 변경 후에는 더 이상 메모리 부족 에러가 발생하지 않았으며, 서버 리소스 사용이 안정화되었습니다.

교훈

JVM 메모리 옵션(-Xms, -Xmx)을 설정할 때는:

  1. 서버의 물리 메모리와 애플리케이션의 요구사항을 고려합니다.
  2. 필요 이상으로 높은 설정은 시스템에 오히려 부하를 줄 수 있습니다.
  3. GC 로깅 등을 통해 애플리케이션의 실제 메모리 사용량을 파악하고 설정을 최적화하세요.

최근 Windows 환경에서 Docker를 사용해 Python Django 앱을 실행하던 중 예상치 못한 문제가 발생했습니다. uWSGI를 통해 서버를 구동하려고 했으나, 아래와 같은 에러 메시지가 출력되었습니다

 

Thu Nov 21 16:29:43 2024 - *** uWSGI listen queue of socket ":8000" (fd: 3) full !!! (18956672/16384) ***

 

문제 상황

Docker Desktop for Windows와 WSL 2를 사용 중이었으며, Ubuntu 배포판을 기본 WSL 환경으로 설정해 Docker 컨테이너를 실행하고 있었습니다. 하지만 위와 같은 에러가 지속적으로 발생하며 컨테이너가 제대로 작동하지 않았습니다.

해결 과정

이 문제를 해결하기 위해 다음 단계를 진행했습니다:

    • WSL 설정 확인 및 수정
      • Docker Desktop 설정에서 Resources > WSL integration 항목을 확인했습니다.
      • 아래 이미지처럼 기본 WSL 통합 설정이 활성화되어 있었고, 추가로 Ubuntu 배포판도 통합 대상으로 설정되어 있었습니다.

 

 

 

  • Refetch Distros
    • "Refetch distros" 버튼을 클릭해 WSL 통합 배포판 정보를 다시 가져왔습니다.
  • Docker 재시작
    • Docker Desktop을 완전히 종료하고 다시 실행했습니다.
  • 컨테이너 및 이미지 초기화
    • 문제를 일으킨 컨테이너를 중지하고 삭제했습니다.
    • 관련 이미지를 모두 삭제한 후, docker-compose를 사용해 빌드를 새로 진행했습니다.

 

결과

위 단계를 수행한 후 uWSGI 관련 에러가 더 이상 발생하지 않았습니다. Django 앱은 정상적으로 실행되었고, Docker와 WSL 통합 설정의 문제가 원인이었음을 확인할 수 있었습니다.

결론

Windows에서 Docker와 WSL 2를 활용할 때, 설정 불일치로 인해 다양한 문제가 발생할 수 있습니다. 특히 WSL 통합 설정과 관련하여 문제가 발생했을 경우:

  • WSL 통합 설정을 확인 및 업데이트
  • Docker Desktop 재시작
  • 컨테이너와 이미지를 초기화하고 새로 빌드

 

 

 

드물게 사용자에게 SSMS 설치 문제가 발생하는 경우가 있으며 일반적인 오류 메시지는 다음과 같습니다.

  • "MSI 패키지를 설치할 수 없음"
  • “Microsoft ODBC Driver 17 for SQL Server: 이전 설치에서는 변경 사항을 적용하려면 컴퓨터를 재부팅해야 했습니다.”
  • “설치 중에 오류 발생(0x80070643)”

제안된 해결 방법

앞서 언급한 또는 유사한 오류 메시지 중 하나가 표시되면서 설치가 실패하는 경우 일반적으로 SSMS 설치를 시작하기 전에 다음 단계에 따라 "Microsoft ODBC driver 17 for SQL Server"를 제거하면 설치가 성공할 수 있습니다.

  1. SSMS, Visual Studio 또는 SQL Server Profiler를 비롯한 모든 관련 애플리케이션을 닫습니다.
  2. 제어판 > 프로그램 추가/제거로 이동합니다.
  3. "Microsoft ODBC Driver 17 for SQL Server" 항목을 찾아 제거합니다. 이 단계에서 다시 시작해야 할 수 있습니다.
  4. SSMS 설치를 시작합니다. 최신 버전은 여기에서 사용할 수 있습니다.

 

방법이 안된다면

레지스트리 에디터 (실행 win + R -> regedit)

 

컴퓨터\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager

위 경로로 이동

PendingFileRenameOperations 삭제 후 재설치

소개

FTP 서버는 액티브 모드와 패시브 모드를 지원합니다. 패시브 모드는 클라이언트가 서버에 연결할 때 방화벽 및 NAT(Network Address Translation) 환경에서의 문제를 줄이기 위해 사용됩니다. 이 블로그 포스트에서는 패시브 모드를 설정하고, 일반적인 문제를 해결하는 방법을 안내합니다.

 

패시브 모드란?

패시브 모드는 클라이언트가 서버에 연결할 때, 서버가 클라이언트에게 데이터 전송을 위한 포트 정보를 제공하는 방식입니다. 액티브 모드와 달리, 패시브 모드에서는 클라이언트가 데이터 연결을 설정하므로 방화벽과 NAT 환경에서의 문제를 줄일 수 있습니다.

 

패시브 모드 설정 방법

1. vsftpd.conf 파일 설정

패시브 모드를 활성화하려면 /etc/vsftpd/vsftpd.conf 파일에서 적절한 설정을 추가해야 합니다.

  1. 패시브 모드 활성화
  2. 패시브 모드를 활성화하려면 다음 설정을 추가합니다:
pasv_enable=YES

 

포트 범위 지정

패시브 모드에서는 서버가 클라이언트에 사용할 포트 범위를 알려줘야 합니다. 다음 설정을 통해 포트 범위를 지정합니다:

pasv_min_port=12000
pasv_max_port=12100

 

 

EC2 인스턴스에서 포트 방화벽 설정

AWS EC2에서는 보안 그룹(Security Groups)과 네트워크 ACLs(Network Access Control Lists)를 사용하여 인스턴스의 네트워크 트래픽을 제어합니다. 패시브 모드 포트를 열어주려면 다음 단계를 따르세요.

1. 보안 그룹 설정

  1. AWS Management Console에 로그인합니다.
  2. EC2 대시보드에서 '보안 그룹'을 선택합니다.
  3. 해당 보안 그룹을 선택하고, '인바운드 규칙' 탭을 클릭합니다.
  4. '편집' 버튼을 클릭하여 인바운드 규칙을 추가합니다:
    • 프로토콜: TCP
    • 포트 범위: 21, 12000-12100
    • 소스: 원하는 IP 범위 (예: 0.0.0.0/0 또는 특정 IP)
  5. '저장' 버튼을 클릭하여 규칙을 적용합니다.

2. 네트워크 ACLs 설정

  1. AWS Management Console에 로그인합니다.
  2. VPC 대시보드에서 '네트워크 ACLs'를 선택합니다.
  3. 해당 네트워크 ACL을 선택하고, '인바운드 규칙' 탭을 클릭합니다.
  4. '편집' 버튼을 클릭하여 인바운드 규칙을 추가합니다:
    • 소스: 원하는 IP 범위 (예: 0.0.0.0/0 또는 특정 IP)
    • 프로토콜: TCP
    • 포트 범위: 21, 12000-12100
    • 허용: 허용
  5. '저장' 버튼을 클릭하여 규칙을 적용합니다.

 

계정의 홈 디렉토리가 디폴트와 다른 경우 아래 포스팅 설정을 적용합니다.

https://yes5.tistory.com/60

 

FTP 서버 설정 문제 해결 가이드: 21번 포트와 22번 포트에서의 디렉토리 접근 문제

소개FTP 서버를 설정할 때, 여러 가지 문제에 직면할 수 있습니다. 특히 포트 21번과 22번에서의 디렉토리 접근 문제는 자주 발생하는 이슈 중 하나입니다. 이 포스트에서는 포트 21번에서 디렉토

yes5.tistory.com

 

소개

FTP 서버를 설정할 때, 여러 가지 문제에 직면할 수 있습니다. 특히 포트 21번과 22번에서의 디렉토리 접근 문제는 자주 발생하는 이슈 중 하나입니다. 이 포스트에서는 포트 21번에서 디렉토리 접근이 제대로 되지 않는 문제를 해결하기 위한 단계별 가이드를 제공합니다.

 

문제 설명

FTP 서버를 설정한 후, 포트 22번에서는 홈 디렉토리 접근이 잘 되지만 포트 21번에서는 디렉토리 접근이 제대로 되지 않는 경우가 있습니다. 특히, uploaduser라는 계정의 홈 디렉토리가 기본 디렉토리가 아닌 /home/upload로 설정된 경우, 포트 22번에서는 정상적으로 접근되지만, 포트 21번에서는 루트 디렉토리(/)만 보이는 문제가 발생할 수 있습니다.

 

문제 원인

포트 21번의 문제는 chroot 설정과 관련이 있습니다. chroot는 사용자가 자신의 홈 디렉토리 외부로 접근하지 못하도록 제한하는 기능입니다. chroot가 적용되면, 사용자는 홈 디렉토리의 루트(/)를 볼 수 있게 됩니다.

 

문제 해결 방법

1. vsftpd.conf 파일 수정

  1. chroot_local_user 설정 확인: vsftpd.conf 파일에서 chroot_local_user와 관련된 설정을 확인합니다.
sudo vi /etc/vsftpd/vsftpd.conf

 

 

  • chroot_local_user=YES가 설정되어 있으면, 모든 로컬 사용자가 자신의 홈 디렉토리로 제한됩니다.
  • allow_writeable_chroot=YES는 홈 디렉토리에서 쓰기 권한을 허용합니다.
chroot_local_user=YES
allow_writeable_chroot=YES

 

 

 

특정 사용자에 대한 예외 설정: rankingfiles와 같은 특정 사용자에게 예외를 설정할 수 있습니다.

  • chroot_list_enable=YES와 chroot_list_file 옵션을 활성화합니다.
chroot_list_enable=YES
chroot_list_file=/etc/vsftpd/chroot_list

 

  • /etc/vsftpd/chroot_list 파일에 rankingfiles 사용자를 추가합니다.
sudo echo "uploaduser" >> /etc/vsftpd/chroot_list

 

1. Git 설치

1.1. Git 다운로드

  • Git 공식 웹사이트로 이동합니다.
  • 다운로드 페이지에서 Windows용 Git 설치 파일을 다운로드합니다.

1.2. Git 설치

  • 다운로드한 설치 파일을 실행합니다.
  • 설치 마법사의 지침에 따라 기본 설정을 유지하면서 설치를 완료합니다.

 

2. AWS CLI 설치 및 설정

AWS CLI는 AWS 서비스와 상호작용하기 위해 필요한 도구입니다.

2.1. AWS CLI 다운로드 및 설치

2.2. AWS CLI 설정

  • 명령 프롬프트 또는 PowerShell을 열고 다음 명령어를 실행하여 AWS CLI를 설정합니다:
aws configure
  • AWS 액세스 키, 시크릿 액세스 키, 기본 리전 이름(ap-northeast-2 등), 출력 형식을 입력합니다.

 

3. Git 자격 증명 캐시 설정

AWS CodeCommit에 HTTPS를 통해 접근할 때 Git 자격 증명을 올바르게 설정해야 합니다.

3.1. Git 자격 증명 캐시 설정

  • 다음 명령어를 실행하여 Git이 AWS CLI 자격 증명을 사용하도록 설정합니다:
git config --global credential.helper '!aws codecommit credential-helper $@'
git config --global credential.UseHttpPath true

 

 

4. 로컬 리포지토리 설정 및 원격 리포지토리 추가

로컬에 이미 소스가 있는 경우, 기존 리포지토리와 AWS CodeCommit을 연결할 수 있습니다.

4.1. 로컬 리포지토리 초기화

  • Git 리포지토리 디렉토리로 이동합니다:
  • 로컬 디렉토리가 Git 리포지토리가 아닌 경우, Git 리포지토리로 초기화합니다:
git init

 

4.2. 원격 리포지토리 추가

  • AWS CodeCommit의 HTTPS URL을 사용하여 원격 리포지토리를 추가합니다:
git remote add origin https://git-codecommit.ap-northeast-2.amazonaws.com/v1/repos/test

 

5. 브랜치 생성 및 푸시

5.1. 브랜치 생성 및 커밋

  • 새 브랜치를 생성하고 체크아웃합니다:
  • 변경 사항을 커밋합니다:
  • 원격 리포지토리에 브랜치를 푸시합니다:
git checkout -b dev
git add .
git commit -m "new branch dev"
git push -u origin dev

 

 

6. 오류 해결

6.1. 403 Forbidden 오류

  • IAM 권한 확인: AWS IAM 사용자에게 AWSCodeCommitPowerUser 정책 또는 필요한 권한이 부여되어 있는지 확인합니다.
  • AWS CLI 자격 증명 확인: aws configure 명령어로 자격 증명을 올바르게 설정했는지 확인합니다.
  • 자격 증명 캐시 설정: 위의 credential.helper 명령어로 자격 증명 캐시가 올바르게 설정되었는지 확인합니다.

SSH 키를 사용하면 비밀번호 입력 없이 안전하게 서버에 접속할 수 있습니다. 이 글에서는 로컬 머신에서 SSH 키를 생성하고, 타겟 서버에 적용하여 패스워드 없이 로그인하는 방법을 단계별로 설명합니다.

 

1. 로컬 머신에서 SSH 키 생성하기

우선, 로컬 머신에서 SSH 키를 생성합니다. 이미 SSH 키가 생성되어 있다면 이 단계를 생략해도 됩니다.

SSH 키 생성 명령어:

ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

위 명령을 실행하면 id_rsa (비밀 키)와 id_rsa.pub (공개 키) 파일이 생성됩니다. 기본적으로 ~/.ssh/ 디렉토리에 저장됩니다.

  • id_rsa: 비밀 키 (Private Key)
  • id_rsa.pub: 공개 키 (Public Key)

 

2. 타겟 서버에 공개 키 추가하기

SSH 키를 생성한 후, 타겟 서버에 공개 키를 추가해야 합니다. 이를 위해 두 가지 방법을 사용할 수 있습니다.

ssh-copy-id 명령어 사용하기

ssh-copy-id -i /root/.ssh/id_rsa.pub 사용자명@타겟서버주소

이 명령어는 자동으로 공개 키를 타겟 서버의 ~/.ssh/authorized_keys 파일에 추가합니다.

 

 

3. 패스워드 없는 접근 확인하기

타겟 서버에 공개 키를 성공적으로 추가한 후에는 SSH 비밀 키를 사용하여 패스워드 없이 타겟 서버에 접속할 수 있습니다.

접속 명령어:

ssh -i /root/.ssh/id_rsa 사용자명@타겟서버주소

이 명령어는 비밀 키 파일을 사용하여 타겟 서버에 접속합니다. 패스워드를 입력할 필요 없이 안전하게 서버에 접근할 수 있습니다.

Dockerfile을 작성할 때 Amazon Linux 2 이미지를 사용하려면, 보통 Docker Hub에서 다음과 같은 명령어를 사용해 가져옵니다:

FROM amazonlinux:2

 

이 명령어는 Docker Hub에서 Amazon Linux 2 이미지를 다운로드합니다. 하지만 이미지 요청 수 제한으로 인해 에러가 발생할 수 있습니다.

 

요청 수 제한 문제

Docker Hub는 익명 사용자와 무료 계정 사용자의 이미지 풀 요청 수에 제한을 두고 있습니다. 이에 따라 다음과 같은 에러 메시지를 볼 수 있습니다:

toomanyrequests: too many requests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit

익명 사용자는 6시간 동안 100개의 요청 제한, 무료 계정 사용자는 6시간 동안 200개의 요청 제한을 받습니다.

 

해결 방법: AWS ECR Public Gallery 사용

이 문제를 해결하는 한 가지 방법은 Docker Hub 대신 AWS ECR Public Gallery에서 이미지를 가져오는 것입니다. AWS ECR은 이미지에 대한 요청 제한이 없으며, 특히 Amazon Linux 이미지를 제공하는 신뢰할 수 있는 리포지토리입니다. 다음과 같이 Dockerfile을 수정하여 AWS ECR에서 이미지를 가져올 수 있습니다:

FROM public.ecr.aws/amazonlinux/amazonlinux:2

 

+ Recent posts