전체 글

MySQL 버퍼 풀을 물리 메모리 크기 만큼 설정하면 안되는 이유

1. MySQL 공식 메뉴얼에 따르면, 전용 데이터베이스 서버의 경우 innodb_buffer_pool_size는 전체 시스템 물리 메모리의 80% 수준으로 설정할 것을 권장2. 물리적 메모리에 대한 경쟁은 운영 체제에서 페이징을 유발3. InnoDB는 버퍼 및 제어 구조체를 위해 추가적인 메모리를 예약하므로 실제 할당되는 전체 공간은 설정된 버퍼 풀 크기보다 약 10%더 큼참고자료- https://dev.mysql.com/doc/refman/8.4/en/innodb-buffer-pool.html- https://dev.mysql.com/doc/refman/8.4/en/innodb-parameters.html- https://dev.mysql.com/doc/refman/8.4/en/memory-use.h..

MySQL 데몬의 메모리 사용량이 지속적으로 증가하는 원인

1. MySQL 프로세스의 메모리 점유율이 지속적으로 우상향하는 것은 메모리 누수가 아닌 MySQL의 고유한 메모리 아키텍처 및 동적 할당 방식 때문2. MySQL은 버퍼 풀 외에도 수 많은 메모리를 점유하고 있음 a. 글로벌 버퍼 증가 - InnoDB는 서버가 시작될 때 버퍼 풀 설정 값 만큼의 메모리를 한번에 물리적으로 모두 점유하지 않음 - 데이터 조회 요청이 들어올 때마다 디스크에서 블록을 읽어오며 조금씩 메모리를 할당 받음 - 따라서 설정된 최대 한도에 도달할 때 까지 메모리 사용량은 계속해서 우상향 곡선을 그림 b. Thread별 동적 메모리 할당 - 쿼리가 실행될 때마다 MySQL은 스레드 단위로 추가 메모리를 동적으로 할당 c. 내부 임시 테이블 - group by, order by 등의 ..

systemd-run으로 프로세스 cpu 사용율 제한하기

systemd-run —-scope -p CPUQuota=160% nohup /home/user/agent/start.sh > agent.log 2>&1 CPUQuota 계산법 - 리눅스에서 1코어의 최대치는 100%입니다. - 따라서 시스템 전체 CPU의 80%로 제한하려면 (전체 코어 수 × 100) × 0.8 로 계산 - 2코어 장비: CPUQuata=160% - 4코어 장비: ⁠CPUQuota=320% - 8코어 장비: CPUQuota=640%⁠

가상화 기술(cgroups, namespace)

cgroups (control groups) 프로세스들이 사용할 수 있는 컴퓨팅 자원들을 제한하고 격리 아래 자원들을 제한 - memory - cpu - network - device - i/o namespace 하나의 시스템에서 프로세스를 격리시킬 수 있는 가상화 기술 종류 - mnt - pid - net - ipc - uts - user

Docker Container에서 프로세스 백그라운드 실행

1. vi start.sh 생성 #!/usr/bin/env bash nohup /bin/bash -c “/usr/bin/dockerd 1>/dev/null&2>/dev/null &” 2. Dockerfile CMD /home/start.sh