데이터베이스를 사랑하는 사람들의 모임 데이터베이스 사랑넷

근데 일단 top으로 보면 메모리에는 여유가 있는데 system이 70%잡아먹는다면 디스크 I/O에서 문제가 생겼을 가능성이 큽니다. system이란 사용자레벨이 아닌 시스템 레벨에 접근하는 경우를 말하는 것인데 무언가 여기에서 병목현상이 발생하고 있는 것이지요. 메모리와 스왑등에는 문제가 없는듯한데 이건 vmstat가지고 정확히 모니터링을 할 수 있겠지요. 하드디스크가 여러개라면 io모니터링의 경우는 iostat라는 프로그램을 사용하면 어떤 하드디스크에서 병목이 발생했는지 알 수 있습니다.

그리고 세팅관련하여 말하면요.

현재 메모리가 1G이지요.

세팅시 필요메모리는 다음과 같이 계산할 수 있습니다.

key_buffer_size + (record_buffer + sort_buffer)*max_connections

님의 키버퍼는 67M. (키버퍼는 256M당 64M할당하면 됨. 그러면 님께서는 1G이므로 256M가 적당)

레코드버퍼와 소트버퍼는 합쳐서 5M인데 여기에 동시접속자수 300을 곱하면 이것만 1.5G가 되지요. status 모니터링하여 Max_used_connections을 확인해보세요. 이게 최대접속했던 것이니깐요. 이걸 기준으로 대략 1.5배에서 2배정도 잡아주면 되는데 위에서 실제 메모리를 초과하면 안되지요.

위에서 키버퍼는 모든 스레드에서 공유하므로 한번만 계산하지만 레코드버퍼(순차검색시 사용), 정렬 버퍼(order, group by 에서 사용)은 각 스레드마다 할당되므로 합쳐서 동시접속자수에 곱하는 것입니다.

아뭏든 현재 님께서는 system이 70%가 되는 이유를 찾는게 급선무입니다.

그리고 db 자체의 튜닝은 extended-status에 나오는 항목들 하나하나의 의미를 이해해야 가능합니다. processlist 등도 확인할 필요가 있습니다. 쿼리가 길어지는 경우는 slow-query라고 하는데 이것은 로그를 별도로 기록할수 있기 때문에 문제가 생기는 질의가 무엇인지 찾을 수 있습니다.

-- 천황산 님이 쓰신 글:

>> 안녕하세요..!

>> 고수님들의 많은 조언 부탁드리닙니다..

>> 문제> cpu 사용률이 너무 높다

>> 1. 웹서버 : xxx.xxx.xxx.12

>> 2. mysql 서버 : xxx.xxx.xxx.13

>> 웹서버(12)에 httpd 데몬 수 : 65개

>> 65개 정도의 접속자가 있는데..

>> mysql서버(13)번의 top 결과는 아래와 같습니다..

>> 9:31am up 90 days, 10 min, 1 user, load average: 9.08, 7.42, 5.57

>> 65 processes: 57 sleeping, 8 running, 0 zombie, 0 stopped

>> CPU states: 0.0% user, 76.2% system, 23.7% nice, 0.0% idle

>> Mem: 1036112K av, 624516K used, 411596K free, 7920K shrd, 197376K buff

>> Swap: 514072K av, 1552K used, 512520K free 337480K cached

>> PID USER PRI NI SIZE RSS SHARE STAT LIB %CPU %MEM TIME COMMAND

>> 22560 root 5 5 63916 62M 1688 S N 0 0.0 6.1 9:49 mysqld

>> 22562 root 16 5 63916 62M 1688 S N 0 0.0 6.1 3:57 mysqld

>> 22563 root 5 5 63916 62M 1688 S N 0 0.0 6.1 3:13 mysqld

>> 16368 root 6 5 63916 62M 1688 S N 0 7.7 6.1 0:01 mysqld

>> 16377 root 8 5 63916 62M 1688 S N 0 12.5 6.1 0:01 mysqld

>> 16379 root 8 5 63916 62M 1688 S N 0 10.6 6.1 0:00 mysqld

>> 16381 root 6 5 63916 62M 1688 S N 0 12.7 6.1 0:00 mysqld

>> 16382 root 9 5 63916 62M 1688 S N 0 15.8 6.1 0:00 mysqld

>> 16384 root 10 5 63916 62M 1688 S N 0 15.8 6.1 0:00 mysqld

>> 16385 root 9 5 63916 62M 1688 S N 0 14.9 6.1 0:00 mysqld

>> 16386 root 8 5 63916 62M 1688 S N 0 14.1 6.1 0:00 mysqld

>> 16388 root 9 5 63916 62M 1688 S N 0 15.1 6.1 0:00 mysqld

>> 16389 root 12 5 63916 62M 1688 R N 0 11.0 6.1 0:00 mysqld

>> 16390 root 18 5 63916 62M 1688 S N 0 6.0 6.1 0:00 mysqld

>> 16391 root 19 5 63916 62M 1688 R N 0 6.1 6.1 0:00 mysqld

>> 16392 root 11 5 63916 62M 1688 R N 0 2.7 6.1 0:00 mysqld

>> 16393 root 5 5 63916 62M 1688 S N 0 0.3 6.1 0:00 mysqld

>> 16394 root 5 5 63916 62M 1688 S N 0 0.5 6.1 0:00 mysqld

>> 16395 root 5 5 63916 62M 1688 S N 0 0.9 6.1 0:00 mysqld

>> 16397 root 6 5 63916 62M 1688 R N 0 0.7 6.1 0:00 mysqld

>> 16398 root 6 5 63916 62M 1688 S N 0 0.1 6.1 0:00 mysqld

>> 16400 root 6 5 63916 62M 1688 S N 0 0.5 6.1 0:00 mysqld

>> 16401 root 7 5 63916 62M 1688 S N 0 0.5 6.1 0:00 mysqld

>> [root@db bin]# mysqladmin variables;

>> +----------------------------+---------------------------------------+

>> | Variable_name | Value |

>> +----------------------------+---------------------------------------+

>> | back_log | 5 |

>> | connect_timeout | 5 |

>> | basedir | /usr/local/mysql/ |

>> | datadir | /usr/local/mysql/data/ |

>> | delayed_insert_limit | 100 |

>> | delayed_insert_timeout | 300 |

>> | delayed_queue_size | 1000 |

>> | join_buffer | 131072 |

>> | flush_time | 0 |

>> | key_buffer | 67104768 |

>> | language | /usr/local/mysql/share/mysql/english/ |

>> | log | OFF |

>> | log_update | OFF |

>> | long_query_time | 10 |

>> | low_priority_updates | OFF |

>> | max_allowed_packet | 1048576 |

>> | max_connections | 300 |

>> | max_connect_errors | 10 |

>> | max_delayed_insert_threads | 20 |

>> | max_join_size | 4294967295 |

>> | max_sort_length | 1024 |

>> | max_write_lock_count | 4294967295 |

>> | net_buffer_length | 16384 |

>> | pid_file | /usr/local/mysql/data/db.pid |

>> | port | 3306 |

>> | protocol_version | 10 |

>> | record_buffer | 1044480 |

>> | skip_locking | ON |

>> | skip_networking | OFF |

>> | socket | /tmp/mysql.sock |

>> | sort_buffer | 4194296 |

>> | table_cache | 256 |

>> | thread_stack | 65536 |

>> | tmp_table_size | 1048576 |

>> | tmpdir | /tmp/ |

>> | version | 3.22.32 |

>> | wait_timeout | 28800 |

>> +----------------------------+---------------------------------------+

>> 위와 같습니다..

>> 질문1> 단지 몇십명의 접속자 때문에 db서버의 cpu 사용율이 이렇게 높게 나오는지 의문이 갑니다..?

>> 질문2> db튜닝을 할려고 하는데, 어떻게 해야 하는지 궁금해서요..?

>> 고수님의 많은 조언 부탁드리면... 수고하세요

by 문태준 (taejun)

=================================================================

http://database.sarang.net/?inc=read&aid=15167&criteria=mysql&subcrit=qna&record_idx=16&currpg=0

고려사항 및 참고자료 Fri, Feb 15 2002 11:54:34 AM

아래 내용을 보니 mysql 버전이 좀 예전것인듯. 최근버전은 모니터링을 더 상세하게 하거든요. 웬만하면 db부터 먼저 업그레이드하는것이 좋을듯. 모니터링도 상세하게 할 수 있구요.

ㅇ vmstat보니 일단 스왑이 발생하고 있는것은 아니군요. 이건 아까 top에서도 확인을 했지요.

ㅇ 취소된 연결이 많으므로 네트워크 상태에 대한 점검이 필요하다

ㅇ Created_tmp_tables 만 나와있는데 이는 메모리에 생성한 임시테이블수를 의미합니다. 최근 버전에서는 Created_tmp_disk_tables 가 나오는데 이는 디스크에 생성한 임시테이블수로 이것이 크다면 그만큼 임시테이블생성을 디스크에 생성하기 위한 부하가 커짐을 의미합니다. 이 수치가 나오지 않아서 정확한 판단은 들지않지만 님께서 order by를 많이 하신다고하니 여기에서 생기는 과부하일 가능성이 크지 않을까 합니다. mysqld를 시작할때 슬로우 쿼리를 기록하는 옵션이 있는데(이건 찾아보세요) 이걸 기록하여 어떤 쿼리가 느려지는지 찾아야합니다. 그리고 해당 쿼리를 explain 명령으로 돌리면 쿼리 실행방식을 알 수 있습니다. 질의 자체를 최적화하거나 DB 최적화가 필요한 것이지요.

ㅇ

| Key_read_requests | 73882229 |

| Key_reads | 47479 |

위 수치를 비교한것이 캐쉬 히트율로서 Key_reads/key_read_requests 가 0.01보다 작으면 됩니다. 여기서는 작지요? 그만큼 캐쉬버퍼가 충분하여 인덱스를 캐쉬에서 활용하고 있다는 것입니다. key 버퍼 활용은 잘되고 있다는것을 의미하지요.

ㅇ Max_used_connections | 252

실제 동시접속이 252인데 현재 설정된 것이 300이 한계이지요. 현재로서는 최대 동시접속까지는 간것은 아니군요. 근데 무조건 동지접속자수가 많다고 좋은것이 아니라 프로그램과 db를 효율적으로 짜서 처리를 빠르게 하여 동시접속자수를 줄이는게 좋은 것입니다.

ㅇ

| Open_tables | 255 |

| Open_files | 111 |

| Open_streams | 0 |

| Opened_tables | 8065 |

table_cache | 256 |

현재 설정된 테이블 캐쉬가 256인데 이건 열려진 파일 핸들을 캐슁하는 것이지요. 근데 위에서 보면 Opened_tables | 8065 이게 256에 비해서 엄청 크죠? table_cache를 충분히 늘려주어야합니다. 이에 대한 것은 아래 자료 참고.

http://database.sarang.net/?inc=read&aid=15102&criteria=mysql&subcrit=tutorials&record_idx=0&currpg=0

근데 일반적으로 table_cache는 동시접속자수의 1.5배에서 2배정도 맞추어주면 되는데 위에서는 이상하게 수치가 크네요. 쩝.

최근 버전에서는 extended-status에 Select_full_join이 나오는데 이는 인덱스를 사용하지 않은 조인으로 최대한 0에 가깝도록 조정해주어야합니다. 조인에서 인덱스를 사용하지 못하므로 버벅거리는거죠. 이건 테이블디자인 수정이 필요한것이지요. 근데 위에서는 이 수치도 나오지 않는군요.

아뭏든 제 생각으로는 order by문장에서 임시테이블을 하드디스크에 생성하는 경우가 잦아서 디스크 I/O에 심각한 문제가 생기고 있다고 판단이 듭니다. tmp_table_size를 늘리는것은 임시적인 도움이 되겠지만 결국 디비디자인수정이 더 필요할듯.

참고자료는 다음과 같습니다.

http://database.sarang.net/?inc=read&aid=15102&criteria=mysql&subcrit=tutorials&record_idx=0&currpg=0 -> 테이블캐쉬

http://tunelinux.pe.kr/bbs/read.php?table=study&no=67 => mysql 모니터링 (제가 쓴글)

http://tunelinux.pe.kr/bbs/read.php?table=study&no=65 => mysqladmin 정리한 글(여기 dsn에도 올려져있습니다. 튜토리얼)

http://tunelinux.pe.kr/bbs/read.php?table=study&no=41 => Optimizing MySQL (아니면 dsn http://database.sarang.net/database/mysql/tuning/optimize_mysql.html)

기타 제 사이트(tunelinux.pe.kr)나 제가 번역한 매뉴얼중 최적화 부분, 여기 DSN 사이트에서 mysql 튜닝 자료 찾아보시면 됩니다. 영문매뉴얼도 mysqladmin부분 보시구요.

-- 천황산 님이 쓰신 글:

>> 기타 정보를 추출해 보았읍니다..

>> [root@db bin]# mysqladmin extended-status

>> +--------------------------+------------+

>> | Variable_name | Value |

>> +--------------------------+------------+

>> | Aborted_clients | 0 |

>> | Aborted_connects | 47 |

>> | Created_tmp_tables | 15937 |

>> | Delayed_insert_threads | 0 |

>> | Delayed_writes | 0 |

>> | Delayed_errors | 0 |

>> | Flush_commands | 1 |

>> | Handler_delete | 30107 |

>> | Handler_read_first | 1659 |

>> | Handler_read_key | 32083765 |

>> | Handler_read_next | 65244037 |

>> | Handler_read_rnd | 1323104291 |

>> | Handler_update | 1161672 |

>> | Handler_write | 1245645 |

>> | Key_blocks_used | 47935 |

>> | Key_read_requests | 73882229 |

>> | Key_reads | 47479 |

>> | Key_write_requests | 96196 |

>> | Key_writes | 60446 |

>> | Max_used_connections | 252 |

>> | Not_flushed_key_blocks | 0 |

>> | Not_flushed_delayed_rows | 0 |

>> | Open_tables | 255 |

>> | Open_files | 111 |

>> | Open_streams | 0 |

>> | Opened_tables | 8065 |

>> | Questions | 19805091 |

>> | Running_threads | 44 |

>> | Slow_queries | 67 |

>> | Uptime | 469669 |

>> +--------------------------+------------+

>> [root@db bin]# mysqladmin status;

>> Uptime: 470037 Threads: 25 Questions: 19844068 Slow queries: 67 Opens: 8093 Flush tables: 1 Open tables: 255

>> 참고로 mysql>show processilt 해보면 order by절이 많거든요..!

>> order by 절이 많아서.. slow_quries 값이 많이 나올까요..?

>> 레코드버퍼, 정렬 버퍼는 얼마로 해야 하는지요..?

>> 다시한번 답변에 감사드리며, 많은 조언 부탁드립니다..

by 문태준 (taejun)

===============================================================

http://database.sarang.net/?inc=read&aid=15174&criteria=mysql&subcrit=qna&record_idx=8&currpg=0

Re: mysql 서버&튜닝관련 질문사항들.. Fri, Feb 15 2002 5:20:42 PM

음냐 어느정도의 답변을 쓸까말까 하다가 쓰기로 하였습니다. 근데 해당 운영체제가 무엇인지는 없군요. 운영체제에 따라 조금씩 다르니깐요.

-- 장홍창 님이 쓰신 글:

>> 안녕하세요.. 매일 mySQL 공부하느라 머리가 한웅큼씩 빠지는 창압니다. -_-;

>> 제가 관리하는 서버가 사양은 좋은데 몇가지 궁금한 게 있어서 이렇게 올립니다. 고수님들께서는 답변해 주시면 감사하겠습니다.

>> ===top===========================================================

>> 11:37am up 16 days, 4:41, 5 users, load average: 0.96, 0.98, 0.84

>> 117 processes: 115 sleeping, 2 running, 0 zombie, 0 stopped

>> CPU0 states: 2.8% user, 1.7% system, 0.0% nice, 95.2% idle

>> CPU1 states: 2.3% user, 1.2% system, 0.0% nice, 96.2% idle

>> CPU2 states: 3.4% user, 2.1% system, 0.0% nice, 94.3% idle

>> CPU3 states: 3.5% user, 1.0% system, 0.0% nice, 95.3% idle

>> CPU4 states: 1.1% user, 45.8% system, 0.0% nice, 52.8% idle

>> CPU5 states: 48.4% user, 10.4% system, 0.0% nice, 41.0% idle

>> CPU6 states: 3.0% user, 1.2% system, 0.0% nice, 95.6% idle

>> CPU7 states: 4.1% user, 1.5% system, 0.0% nice, 94.2% idle

>> Mem: 8241200K av, 8214176K used, 27024K free, 0K shrd, 36756K buff

>> Swap: 1052216K av, 0K used, 1052216K free 7063304K cached

>> =========================================================

>> ===status=================================================

>> Uptime: 1399206 Threads: 64 Questions: 1304093645 Slow queries: 20 Opens: 683 Flush tables: 1 Open tables: 486 Queries per second avg: 932.024

>> ===========================================================

>> == io-stat =======================================================

>> avg-cpu: %user %nice %sys %idle

>> 2.55 0.00 7.50 89.95

>> Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn

>> dev8-0 13.60 0.00 110.40 0 552

>> dev8-1 0.00 0.00 0.00 0 0

>> ================================================================

>> == Status ========================================================

>> +--------------------------+------------+

>> | Variable_name | Value |

>> +--------------------------+------------+

>> | Aborted_clients | 3222 |

>> | Aborted_connects | 218 |

>> | Bytes_received | 790589725 |

>> | Bytes_sent | 878724895 |

>> | Connections | 176449 |

>> | Created_tmp_disk_tables | 0 |

>> | Created_tmp_tables | 16 |

>> | Created_tmp_files | 6 |

>> | Delayed_insert_threads | 0 |

>> | Delayed_writes | 0 |

>> | Delayed_errors | 0 |

>> | Flush_commands | 1 |

>> | Handler_delete | 62529484 |

>> | Handler_read_first | 18800139 |

>> | Handler_read_key | 1215636801 |

>> | Handler_read_next | 610226767 |

>> | Handler_read_prev | 168 |

>> | Handler_read_rnd | 7190427 |

>> | Handler_read_rnd_next | 3120695999 |

>> | Handler_update | 992311878 |

>> | Handler_write | 69247061 |

>> | Key_blocks_used | 40224 |

>> | Key_read_requests | 1079101369 |

>> | Key_reads | 9168 |

>> | Key_write_requests | 19313896 |

>> | Key_writes | 15162478 |

>> | Max_used_connections | 66 |

>> | Not_flushed_key_blocks | 0 |

>> | Not_flushed_delayed_rows | 0 |

>> | Open_tables | 486 |

>> | Open_files | 279 |

>> | Open_streams | 0 |

>> | Opened_tables | 683 |

>> | Questions | 1309319295 |

>> | Select_full_join | 0 |

>> | Select_full_range_join | 0 |

>> | Select_range | 12 |

>> | Select_range_check | 0 |

>> | Select_scan | 6003356 |

>> | Slave_running | OFF |

>> | Slave_open_temp_tables | 0 |

>> | Slow_launch_threads | 0 |

>> | Slow_queries | 20 |

>> | Sort_merge_passes | 3 |

>> | Sort_range | 2 |

>> | Sort_rows | 9705121 |

>> | Sort_scan | 2560 |

>> | Table_locks_immediate | 1291264332 |

>> | Table_locks_waited | 19256142 |

>> | Threads_cached | 0 |

>> | Threads_created | 176448 |

>> | Threads_connected | 64 |

>> | Threads_running | 1 |

>> | Uptime | 1404967 |

>> +--------------------------+------------+

>> ===================================================================

>> 이렇게 구성이 되어 있습니다. 그리고 safe-mysqld 가동시에

>> max_heap_table_size=1024M

>> tmp_table_size=512M

>> max_tmp_tables=256

>> back_log=50

>> table_cache=512

>> join_buffer=4M

>> key_buffer=64M

>> sort_buffer=4M

>> record_buffer=2M

>> 로 세팅이 되어 있습니다. 여기에서 궁금한 점들입니다.

>> (속도를 위해서 대부분의 Table이 heap으로 되어 있고 주기적으로 백업을 합니다. 초당 쿼리수는 1000개 정도 됩니다)

>> 일단 변수에 대한 질문입니다.

>> 1. max_heap_table_size가 1G로 잡혀 있는데, 이것은 heap table하나당 최대 잡을 수 있는 크기 아닌가요? 그렇다면 이 값은 커도 관계가 없는지 궁금합니다.

=> 최대 크기니깐 메모리가 허용하는한 상관없겠지요.

>> 2. join이나 group by등의 작업이 별로 없습니다(거의 모든 작업이 insert, update이고 단순 select가 조금 있습니다). tmp_table_size가 너무 큰 것이 아닌가 궁금합니다.

=> 메모리의 임시테이블이 이 크기를 초과할 경우에만 자동으로 변환하므로 그다지 신경을 쓰지 않아도 될 듯 합니다. 이런 경우에는 굳이 설정하지 않고 기본값으로 쓰면 되지 않을까요.

>> 3. key_buffer가 256M에 64M정도라고 하셨는데.. 저희같은 경우는 메모리가 8G니까 더 크게 잡아야 하는지요. 이 값이 status의 read_key_requests, read_key와 관련이 있다고 하는데(비가 0.02보다 작아야 한다고 하네요), 지금 시스템에서는 1/10000정도 되거든요. 그렇다면 이 값을 바꿀 필요가 없지 않은지요??

=> DB전용으로 쓴다면 더 크게 잡아주는게 좋겠지요. 그리고 캐시 히트율을 0.01보다 작게 유지하라고 했는데 현재는 아주 훌륭하네요. 바꿀 필요 없겠죠.

>> 4. mysqld이 60개 정도 돌고 있습니다. (record+buffer + sort_buffer) * max_connection = (4+2) * 100 = 600M로 메모리가 사용되는 것이 맞나요?

=> 글을 정확히 보시지요.

key_buffer_size + (record_buffer + sort_buffer)*max_connections

64M + (2M+4M)*100 = 64M + 600M = 664M. 현재 max_connections이 100인가보지요? 이 공식을 외우는게 중요한게 아니라 왜 이렇게 사용하는가를 이해하는게 중요합니다. 키버퍼(인덱스버퍼)는 모든 스레드에서 공유하지만 레코드버퍼와 소트버퍼는 각 스레드마다 따로 할당되기 때문입니다.

>> 시스템에 관한 질문입니다.

>> 1. top에서 메모리의 사용이 너무나 많습니다. variable과 관계가 있는지 궁금합니다.

==>

메모리 사용량이 많은것은 아니네요.

Mem: 8241200K av, 8214176K used, 27024K free, 0K shrd, 36756K buff

Swap: 1052216K av, 0K used, 1052216K free 7063304K cached

위에서 실제 사용하는 메모리는 used-cache-buff 인데 그렇게 따지면 8214176-36756-7063304 = 1,114,116 이네요. 8G중 7G가 펑펑 놀고 있는것이니 절대 메모리 부족은 아닙니다.

>> 2. 초당 쿼리수가 1000개 정도 되고, table_lock_immediate는 query수랑 비슷하고 table+locks_waited는 lock처리량의 1/100 수준입니다. 이 정도의 wait는 원래 일어나는 것인가요?

==> table_locks_waited (위에 오타군요) 는 아래와 같은 설명으로 되어 있지요.

Number of times a table lock could not be acquired immediately and a wait was needed. If this is high, and you have performance problems, you should first optimise your queries, and then either split your table(s) or use replication. Available after 3.23.33.

아마도 락이 해제되지 못하고 지체된 시간을 의미하는 듯한데 너무 높으면 성능에 문제가 있다고 하지만 어떤 기준으로 높다는 것인지는 내용이 없습니다.

>> 3. table이 130개 정도 되고. 60개 정도의 index가 걸린 테이블에 계속해서 insert, update작업이 걸립니다. 어떤 추가 작업으로 작업속도를 향상시킬 수 있는지 궁금합니다.

>> (delayed_insert라는 것이 있던데.. 실시간 시스템에서 사용가능한지 궁금합니다. table이 close될때, 처리된다고 하는데. 정확한 의미가 분간이 되지 않네요)

==> delayed_insert 는 어떤 스레드에서도 그 테이블을 사용하지 않을때 한꺼번에 모아서 입력하는것을 의미할 것입니다. 그렇다면 분명히 디스크 I/O작업에는 효과가 있겠지만 자료의 무결성이 중요한 곳에서는 사용하기엔 위험할 듯 합니다.

추가작업 향상시키는 것은 본인이 직접 자료들 참고하셔서 해보세요. 오라클쓰다가 mysql쓰니 적응이 안된다고 했지만 기존에 다른 디비를 써보셨다면 큰틀에서의 개념은 적용할 수 있을 것입니다. 튜닝도 마찬가지지요. 물론 세부적으로 들어가면 각 디비마다 차이점은 있겠지만요.

그리고 솔직히 저는 튜닝 자체보다는 모니터링해서 나오는 결과도 제대로 모르는 사람이 너무 많아서 이것부터 바뀌어야 하지 않을까 생각합니다. 위에서 메모리 부분 말을 한대로 실제 사용하고 있는 메모리는 캐쉬와 버퍼로 사용되는것을 빼야하는데 이것을 모두 실제 사용하고 있다고 해버리면 메모리 계산이 엉뚱해집니다. 엄청난 결과를 초래할 수 있지요.

근데 님께서는 너무 하드웨어가 빵빵해서 오히려 심심할듯. 좀 삐리해야 원래 이것저것 더 고민하고 경험을 많이 하는데요.

>> ==

>> 질문을 하나 하나씩 모으다 보니까 엄청 많아졌네요.. ^^;

>> oracle을 쓰다가 mysql을 쓰니까 아직은 적응이 되지 않는 부분도 많고, 특히 performance를 측정하는 것이 쉽지 않군요. manual에도 (이 값이 크다면 -_-)이라는 식의 애매한 표현들이 많구요.

>> 게다가 실시간으로 움직이는 모듈이다 보니까. 중간에 이런 저런 세팅을 바꾸고 재부팅한다던가. 이 방법이 좋은가 시험하는 것도 쉽지만은 않네요.

>> 고수님들의 많은 도움 부탁드립니다.

by 문태준 (taejun)

=========================================================

http://database.sarang.net/?inc=read&aid=15187&criteria=mysql&subcrit=qna&record_idx=25&currpg=1

Re: mysql서버의 과부하..! db튜닝은 어떻게..하는게 좋을가요..? Sat, Feb 16 2002 10:31:34 PM

[root@db bin]# vmstat 5

procs memory swap io system cpu

r b w swpd free buff cache si so bi bo in cs us sy id

10 0 0 1552 330440 208940 399616 0 0 0 1 2 2 1 2 1

8 0 0 1552 331332 208940 399648 0 0 1 6 455 1553 23 77 0

17 0 0 1552 331160 208940 399728 0 0 5 7 487 996 22 77 1

11 0 0 1552 329224 208940 399728 0 0 0 4 327 1665 24 76 0

7 0 0 1552 332836 208940 399732 0 0 0 7 428 1164 25 75 0

...

vmstat 를 보면 cs (context switching) 이 지나치게 높습니다.

그리고, 초당 쿼리수에 비하면 mysql thread 의 수가 많은 편입니다.

mysql version 이 3.22.32 이던데, 가장 최근 mysql (3.23.xx) 로 바꾸시고,

컴파일할때 혹시 linux native thread 가 아닌 다른 thread library 를 사용하게 설정되어 있는지 확인해 보십시요.

-- 천황산 님이 쓰신 글:

>> 안녕하세요..!

>> 고수님들의 많은 조언 부탁드리닙니다..

by 이창훈

[Top]

No.	제목	작성자	작성일	조회
16214	FILE Upload 와 MySQL BLOB 화일 입출력 [1]	정재익	2002-06-11	17749
16213	MySQL Table Joins	정재익	2002-06-11	8807
15438	mysqld_error code [1]	김순석	2002-03-12	11224
15180	[참고자료-질문/답] mysql 최적화 관련	문태준	2002-02-16	11704
15102	mysql 에서 open file caching	이창훈	2002-02-06	11604
14900	mysqladmin 총정리	정재익	2002-01-23	17724
14867	mysqlfs (MySQL filesystem) [1]	정재익	2002-01-20	8590

작업시간: 0.017초, 이곳 서비스는
PostgreSQL v16.4로 자료를 관리합니다