튜닝 프라이머에서 나오는 max_connections정보는 MySQL Status / Variable 값을 기준으로 결과를 보여주는데, max_used_connections수가 max_connections 값의 10% 보다 작으면, max_connections값을 줄이라고 알려줍니다.

per_thread_buffers = (read_buffer_size+read_rnd_buffer_size+sort_buffer_size+thread_stack+join_buffer_size+binlog_cache_size) * max_connections

위 공식에서 보시는 것과 같이, thread당 사용하는 버퍼의 크기는 max_connections를 어떻게 가져가느냐에 달려 있습니다.

실제로 튜닝시 max_connections를 무조건 늘리는 것은 별 도움이 되지 못합니다. 설계와 쿼리를 개선해서 각 프로세스가 더 빨리 처리되도록 하는 부분이 중요합니다.

결론 : 메모리만 많으면 높게 잡으셔도 상관 없지만, 튜닝을 목적으로 무조건 늘리는 것은 의미가 없습니다.

max_connection을 2000으로 잡았을때 tuning-primer.sh에서 메모리 부분이 아래와 같이 나와요.

MEMORY USAGE
Max Memory Ever Allocated : 53.65 G
Configured Max Per-thread Buffers : 65.18 G
Configured Max Global Buffers : 2.03 G
Configured Max Memory Limit : 67.21 G
Physical Memory : 7.79 G

nMax memory limit exceeds 90% of physical memory
 

사용량이 워낙 많아 한번에 1000 이상씩 튀는 경우가 문제가 됩니다. 실제 서비스를 해보면 threads가 1000이 넘어가도 메모리는 3기가정도만 쓰고 있구요. tuning-primer.sh에서는 메모리를 너무 많이 잡았다고 하는데요. 실제 서비스를 해보면 너무 달라서요. 튜닝목적보다는 서비스가 되도록 하는게 목적인데요. 쿼리는 간단한 select문이고 시스템에 부하는 거의 주지 않습니다. threads만 순간 튀는 현상이 있습니다.