참고 문서 : http://www.mysql.com/doc/L/i/Linux.html

MySQL 은 기본적으로 동시 접속수가 500 connection 이하에 최적화가 되어 있다.  MySQL 홈의
문서 중 http://www.mysql.com/doc/L/i/Linux.html 문서에 의하면, 500 connection 이상을 설
정 할 경우 glibc 의 linuxthreads 에 패치를 하지 않았을 경우 상당히 불안하다고 보고 되고
있다.

이 문서에서는 이 문제에 관한 부분을 언급하게 된다. 동시 접속수 500 이상을 위해서는 일단
glibc 를 리빌드해야 하며, 재컴파일된 libpthread.a 를 링크하여 MySQL 을 리빌드해야 한다.

그럼 500 이상의 동시접속수를 위해 필요한 사항들을 언급하도록 하겠다. 일단 500 이상의 동
시접속을 위해서 MySQL 에서 권장하는 바는 다음과 같다.

SMP system
over Glibc 2.2.2
over MySQL 3.23.36
Kernel 2.4

500 이상의 동시 접속수를 위해서는 STACK_SIZE 를 작게 해 줘야 하는데, STACK_SIZE 를 작게
하는 대신 thread 수를 늘려 이를 커버하기위해 다중 CPU를 권장하고 있다. 또한 Glibc 2.1.3
의 경우에는 mutex 에 문제가 있기 때문에 mutex patch 를 제공하고 있다. 즉 RH 6.2 의 경우
에는 glibc 2.1을 사용하기 때문에 6.x 대에서 500 이상의 동시접속을 위해서는 이 패치를 꼭
해 줘야 한다. 해당 패치는 아래에서 받을 수 있다.

http://www.mysql.com/Downloads/Linux/linuxthreads-2.1-patch
http://www.mysql.com/Downloads/Linux/linuxthreads-2.2.2-patch

일단 위의 패치를 glibc에 하도록 한다. glibc 2.2.4 의 경우에는 패치를 할 필요가 없다. 패
치를 마쳤으면 다시 glibc 소스에서 2가지를 수정해 주도록 한다.

glibc-version/sysdeps/unix/sysv/linux/bits/local_lim.h

에서 PTHREAD_THREADS_MAX 값을 4096 으로 수정하며,

glibc-version/linuxthreads/internals.h

에서 STACK_SIZE 의 값을 256 KB 로 변경한다. 기본값은 2 MB 이다. 이 2 가지를 수정한 후에
glibc 를 리빌드 하여 설치를 하도록 한다.

glibc 리빌드를 마쳤으면 리빌드된 glibc 의 libpthread.a 를 이용하여 MySQL 을 다시 빌드하
도록 한다. 이 말을 어렵게 생각할 필요는 없다.  위에서 리빌드한 glibc 하에서 MySQL 을 리
빌드 하면 되는 것이다.

MySQL 리빌드 후에는 다음 사항을 주의하여 MySQL 설정을 한 다음 운영을 하도록 한다. MySQL
의 동시 접속수는 다음의 식에 의해 구할 수 있다. (다음의 식의 단위는 byte 이다.)

max_connections = (Real_Memory-key_buffer_size)/(record_buffer+sort_buffer)

로 구할수 있다. key_buffer_size 는 보통 실 메모리의 1/4 정도로 설정을 하며, 적당하게 늘
리거나 줄여서 설정을 하면 된다.

또한 table_cache 는 최대 동시 접속의 1.5-2 배 정도를 잡아주면 무난하다.  table_cache 를
200 으로 설정을 했을 경우, DB 의 모든 table 중 200 개의 table 을 동시에 캐싱이 가능하다
는 의미이다. table_cache 의 최대값은

(MaxFileOpen-MaxConnection-(temporary table 에 사용되는 파일핸들) ) / 2

로 구할 수 있으나, 꼭 최대값을 지정할 필요는 없다. 위에서 언급했던 대로 최대 동시접속의
1.5-2 배 정도로 잡아 주면 된다.

또하나 주의 할 것은 위의 식에서 나온 MaxFileOpen 인데,  500 이상의 동시 접속을 위해서는 
시스템과 MySQL 이 동시에 열수 있는 파일의 수를 조절해 주는 것이 중요하다. 이에 대해서는
http://oops.org/?t=lecture&sb=kernel&n=3 의 fr.file-max 를 참조 하도록 한다.


[참고]

이 문서는 일반적인 mysql 의 운영에서는 별로 해당사항이 없을것 같다. 하지만 DB 서버가 매
우 고사양이며 동시 접속자를 400명 이상 처리를 해야할 경우가 있다면 참고가 될 것이다. 다
시 말하자면 이 문서의 내용을 적용하기 보다는 SQL 이나 프로그램에서의 SQL 의 최적화를 통
한 동시 접속자를 줄이거나 또는 서버의 증설을 고려하는 것이 더 좋은 방벙이라 생각이 된다.

MySQL 문서에 의하면 특별한 설정이나 빌드를 할 필요가 없다면, MySQL 에서 제공하는 바이너
리를 사용하도록 권장하고 있다. 일단 모든 시스템에서 최적화를 해 놓은채로 빌드해 놓은 바
이너리이기 때문에 그 어느것을 사용하는것 보다 더 낳은 성능을 보일 수 있다고 장담하고 있
다.

또한 glibc 의 리빌드가 버거운 사람들을 위하여 RH 7.2 와 6.2 사용자들을 위해 RPM 으로 패
키징을 해서 제공을 하고 있으니 아래에서 받아서 업그레이드를 하면 되겠다.

ftp://mirror.oops.org/pub/Linux/Redhat/RPMS/6.x/glibc
ftp://mirror.oops.org/pub/Linux/Redhat/RPMS/7.x/glibc

7.2 사용자들은 glibc 를 업그레이드 했다면 gcc 를 다운그레이드 하는것을 권장한다. 7.2 에
있는 gcc 2.96 은 gcc 홈에서 조차 사용을 권장하지않는 버젼이기 때문에 안정적인 2.95.3 으
로 다운그레이드 하기를 권장한다.  위의 7.2 용 glibc 역시 2.95.3 하에서 빌드를 한 것이고
gcc 와 glibc 는 생성한 환경을 맞춰 주는 것이 좋기 때문이다.

7.2 용 gcc 2.95.3 은

ftp://mirror.oops.org/pub/Linux/Redhat/RPMS/7.x/gcc/7.2

에서 받을 수 있다.

참고로 하나 더 언급하자면 동시 접속자 500 이상으로 설정하려면 4 Way 에 4G 정도의 ram 이
면 시도해 볼 만하다고 생각이 된다.

혹시 Oracle 과 MySQL 을 같이 운영하는 서버라면 Glibc patch 시도를 하지 마시기 바랍니다.
Glibc patch 시 Oracle 이 비정상적 작동을 합니다.


>> 이전 : Forgotten MySQL Password