CPU에 쓰레드 풀링이 있듯 DB에도 커넥션 풀링이 있다
일정량의 리소스를 미리 만들어놓고 재사용하는 것이 풀링이라고 생각하자.
지금 사용중인 DB가 있다면 SHOW VARIABLES LIKE 'max_connection' 이라고 입력해보자
보통 105나 60이 나오는 것 같다.
그러면 저 수치를 그냥 수정해버리면 많이 연결할 수 있는 거 아닌가요?
당신의 컴퓨터가 불타는 모습을 볼 수 있을 것이야
max_connections를 무한정으로 설정할 수는 없다. 거기에 innodb_buffer_pool_size 같은 DB 파라미터들도 조정해줘야 한다.
운영체제 상에서 많은 커넥션을 허용하려면 파일 디스크립터 제한도 늘려야 하는 것이 일반적이다. 우리가 지금 서버와 연결하는 것 자체가 소켓을 통해 이루어지는데, 이 소켓은 파일과 마찬가지로 파일 디스크립터를 사용한다. 이 파일 디스크립터는 쉽게 말하면 프로세스 자체가 파일 혹은 소켓과 같은 I/O 리소스에 접근할 수 있게 해주는 추상화된 핸들(고유 식별자) 그 자체라는 것.
엥 그래서 File Descriptor가 뭔가요😵
리눅스에서는 /proc/특정 프로세스 ID/fd 경로로 이동 후 ls -al 명령어로 확인할 수 있다.
여기서 0, 1, 2는 표준 입력, 출력, 오류를 고정으로 담당하는 File Descriptor이다. 얘네가 소켓으로 연결되어 있다는 건 네트워크 기반으로 입력을 받는다는 뜻이고, 클라이언트로부터 네트워크를 이용해 데이터를 받는다는 얘기.
네트워크 커넥션이 늘어나면 파일 디스크립터들은 선형적으로 늘어날 수 밖에 없다. 기본적으로 세팅된 커넥션 외에 커넥션을 더 받기 위해서는 File Descriptor의 총량도 늘려줘야 한다.
->
위 얘기가 뭔 소리냐면 챌린지반 수업자료에 이런 이미지가 있었다.
/dev/pts/1 은 뭔가요 -> 일반 서버가 아니라 로컬에서 뭔가를 돌릴 때.
사용자가 프로그램과 상호작용 할 수 있다는 얘기. 터미널을 통해 입력도 가능하고 결과를 볼 수도 있고 에러 메시지 또한 터미널에 뜬다는 얘기.
ulimitg -n 같은 명령어를 사용해서 File Descriptor 제한을 변경할 수 있다. 그러나 그렇게 조치하는 경우는 흔치 않고, 이런 상황은 발생하지 않는 게 최선. 그래서 요약은 다음과 같다.
커넥션 풀을 사용하여 제한된 수의 커넥션을 효율적으로 관리하는 것이 시스템의 성능을 보장하고 안정성을 높일 수 있는 지름길!
쿼리 실행 계획 확인하고 최적화 해보기 - MySQL의 EXPLAIN이라는게 있다
RDB에는 쿼리엔진, 혹은 스토리지엔진 이라고 불리는 게 있다. 그 안에는 쿼리 옵티마이저 라는 게 있는데, 이 옵티마이저를 돌리려면 SELECT절 앞에 EXPLAIN을 붙여보면 된다.
풀 테이블 스캔이 일어나는 것은 DB에서 매우 안좋은 신호이다. 이런 부분이 없는 지 찾아봐야 함.
동시 접속자 수가 1000명을 넘으면 어떻게 될까? -> 이건 다음 시간에!
