MySQL 쿼리가 임의로 지연됨
다음과 같은 질문이 있습니다.
SELECT id FROM user WHERE id='47'
이와 같이 프로파일링 데이터를 사용할 때 ID가 인덱싱되고 이 쿼리에 대한 읽기 속도가 항상 빠릅니다.
SET profiling = 1;
SHOW PROFILES;
쿼리는 항상 약 0.0002초 안에 실행됩니다.
그러나 PHP 쪽에서 쿼리를 프로파일링하면 다음과 같습니다.
$current = microtime(true);
$data = $conn->query($full_query);
$elapsed = microtime(true) - $current;
그런 다음 때때로 이러한 쿼리 중 50개 중 1개는 0.2초 정도 걸립니다.그러나 내 테스트 스크립트에는 SET 프로파일링 = 1을 사용하여 쿼리를 프로파일링하는 코드가 있습니다. PDO를 통한 PHP 왕복이 0.2초임에도 불구하고 쿼리 시간은 0.0002였습니다.
내가 알고 있거나 문제의 원인이 되지 않는 것:
- 쿼리가 느리지 않습니다.제가 동일한 쿼리 실행에서 PHP로 프로파일링하고 SET PROFILING을 사용하여 프로파일링한 동일한 쿼리를 볼 때 쿼리는 항상 빠르고 PHP 측에서 0.2초가 소요되는 것으로 나타나도 느린 쿼리 로그에 기록되지 않습니다.
- 이것은 skip-name-resolve와 관련이 없습니다. 일관성이 없으며 skip-name-resolve가 이미 설정되어 있습니다.
- 이것은 쿼리 캐시와 관련이 없습니다. 동작은 두 가지 모두에 있습니다.
- 이 동작은 캐시에서 나오는 쿼리에서도 발생합니다.
- 쿼리는 실제로 ID를 선택하지 않지만, 이 쿼리는 필드가 확실히 인덱싱되어 있기 때문에 디스크 액세스 문제가 아니라는 것을 보여주기 위해 테스트에 사용합니다.
- 이 표는 1메가 인덱스와 같은 10~20메가밖에 되지 않습니다.기계의 부하가 매우 적으며 innodb가 모든 버퍼를 사용하지 않습니다.
- 이 테스트는 내 테스트 쿼리 외에 다른 작업이 없는 테이블과 비교하여 테스트됩니다.
또 어떤 것을 확인해야 할지 아는 사람이 있습니까?네트워킹 문제인 것 같습니다만, 문제를 확인하고 해결할 문제를 찾아야 하는데 다음에 확인할 수 있는 공간이 부족합니다.아이디어 있어요?
제가 기계를 프로파일링하겠습니다.
이 문제가 50회당 최대 1회 발생하며 각 쿼리에는 0.2초의 벤치마크가 있다고 가정합니다.화면에 상단을 넣은 다음 PHP에서 쿼리 루프를 실행하여 RDBMS를 로드 테스트하고 성능 통계를 수집할 수 있어야 합니다.
당신은 아마도 더 많이 뛰어야 할 것입니다.50 * 0.2 =당신의 "50점 만점에 1점" 통계는 아마도 당신의 설명에서 읽은 것에 근거하여 개별 쿼리를 수동으로 실행하는 것을 기반으로 하기 10 seconds때문입니다.30초 및 90초 부하 테스트를 시도합니다.
동안, 의 이시동주십오시하의안간을 하세요.top프스별화 CPU로렬을 P'누를 소비하는 순서를 ('P'를 -CPU-소비의 정렬 순서가 변경됩니다.)M메모리 사용량별로 정렬합니다.자세한 내용은 man 페이지를 확인하십시오.
부하 테스트를 수행하는 동안 상단으로 거품이 발생하는 부분이 있는지 확인합니다.당신은 순간적으로 무언가가 더 높이 뛰는 것을 봐야 합니다.
로 이러한 하지 못할 도 있습니다. 서버를 할 수 그럴 필요는 없지만 MySQL 서버를 지연시키기에 충분한 디스크 로드 또는 기타 작업이 발생할 수 있습니다.)
저는 제 시스템에서도 같은 현상을 발견했습니다.일반적으로 1밀리초가 소요되는 쿼리는 갑자기 1-2초가 소요됩니다.제 모든 사례는 단순한 단일 테이블 INSERT/UPDATE/REPLACE 문입니다. - 어떤 SELECT에도 없습니다.로드, 잠금 또는 스레드 증가가 분명하지 않습니다.
더러운 페이지를 삭제하거나 디스크 변경 내용을 플러시하거나 숨겨진 뮤텍스 때문이라고 생각했지만, 아직 범위를 좁히지 못했습니다.
또한 배제됨
서버 로드 - 높음과 상관 없음
load Engine -- InnoDB/MyISAM/Memory MySQL 쿼리에서 발생합니다.
캐시 - 설정 또는 해제 여부에 관계없이 발생합니다.
로그 순환 - 이벤트에 상관 없음
쿼리 프로파일러를 이미 사용하고 있어서 다행입니다.MySQL 5.6을 사용하는 경우 PERFORMANCE_SCHEMA의 많은 새로운 성능 측정에 액세스할 수 있습니다.이 기능은 쿼리 프로파일러보다 훨씬 더 세부적으로 측정할 수 있으며, 세션을 하나만 측정하는 대신 전체적으로 측정할 수도 있습니다.P_S가 쿼리 프로파일러를 대체할 것으로 보고되었습니다.
당신의 문제를 진단하기 위해, 저는 TCP/IP 문제를 확인하거나 배제하는 것으로 시작할 것입니다.예를 들어 PHP 스크립트를 테스트하여 UNIX 소켓을 통해 연결할 때 동일한 간헐적 지연 시간이 발생하는지 확인합니다.다음에 연결하여 이 작업을 수행할 수 있습니다.localhost. 즉, PHP는 스크서서실행되어야에합니다버한일동가립트데.TCP/IP를 우회할 때 문제가 해결되면 근본 원인이 TCP/IP일 가능성이 높다는 것을 알 수 있습니다.
클라우드 호스팅과 같은 가상 환경에 있는 경우 동일한 클라우드의 다른 사용자가 간헐적으로 모든 대역폭을 사용하기 때문에 성능 변화를 쉽게 경험할 수 있습니다.이것은 클라우드의 단점 중 하나입니다.
TCP/IP 문제가 의심되는 경우 PHP 또는 MySQL과 독립적으로 TCP/IP 지연 시간을 테스트할 수 있습니다. 수 로는 쉽게사용수있일도는같다다습니음과구는인반적할이 있습니다.ping또는traceroute하지만 다른 것들도 많이 있습니다.넷캣으로 네트워크 속도를 테스트할 수도 있습니다.시간이 지남에 따라 반복적으로 측정할 수 있는 도구를 사용하십시오. 대부분의 시간 동안 성능이 양호하고 가끔 결함이 발생하는 것처럼 들리기 때문입니다.
또 다른 가능성은 PHP에 결함이 있을 수 있습니다.XHProf를 사용하여 PHP 프로파일링을 시도하여 어디에서 시간을 보내고 있는지 확인할 수 있습니다.
문제를 분리해 보십시오.다음과 같은 작은 스크립트를 실행합니다.
https://drive.google.com/file/d/0B0P3JM22IdYZYXY3Y0h5QUg2WUk/edit?usp=sharing
체인의 어떤 단계가 급증하는지 확인합니다.ssh2가 설치되어 있으면 ssh2도 반환됩니다.ps axu가장 오래 실행된 테스트 루프 직후에 무엇이 실행되고 있는지 확인합니다.
홈 개발 상자에서 localhost에 대해 실행한 결과는 다음과 같습니다.
Array
(
[tests summary] => Array
(
[host_ping] => Array
(
[total_time] => 0.010216474533081
[max_time] => 0.00014901161193848
[min_time] => 9.7036361694336E-5
[tests] => 100
[failed] => 0
[last_run] => 9.8943710327148E-5
[average] => 0.00010216474533081
)
[db_connect] => Array
(
[total_time] => 0.11583232879639
[max_time] => 0.0075201988220215
[min_time] => 0.0010058879852295
[tests] => 100
[failed] => 0
[last_run] => 0.0010249614715576
[average] => 0.0011583232879639
)
[db_select_db] => Array
(
[total_time] => 0.011744260787964
[max_time] => 0.00031399726867676
[min_time] => 0.00010991096496582
[tests] => 100
[failed] => 0
[last_run] => 0.0001530647277832
[average] => 0.00011744260787964
)
[db_dataless_query] => Array
(
[total_time] => 0.023221254348755
[max_time] => 0.00026106834411621
[min_time] => 0.00021100044250488
[tests] => 100
[failed] => 0
[last_run] => 0.00021481513977051
[average] => 0.00023221254348755
)
[db_data_query] => Array
(
[total_time] => 0.075078248977661
[max_time] => 0.0010559558868408
[min_time] => 0.00023698806762695
[tests] => 100
[failed] => 0
[last_run] => 0.00076413154602051
[average] => 0.00075078248977661
)
)
[worst full loop] => 0.039211988449097
[times at worst loop] => Array
(
[host_ping] => 0.00014400482177734
[db_connect] => 0.0075201988220215
[db_select_db] => 0.00012803077697754
[db_dataless_query] => 0.00023698806762695
[db_data_query] => 0.00023698806762695
)
[ps_at_worst] => USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.0 2884 1368 ? Ss Sep19 0:29 /sbin/init
root 2 0.0 0.0 0 0 ? S Sep19 0:00 [kthreadd]
root 3 0.0 0.0 0 0 ? S Sep19 0:00 [migration/0]
root 4 0.0 0.0 0 0 ? S Sep19 0:06 [ksoftirqd/0]
root 5 0.0 0.0 0 0 ? S Sep19 0:00 [migration/0]
root 6 0.0 0.0 0 0 ? S Sep19 0:25 [watchdog/0]
root 7 0.0 0.0 0 0 ? S Sep19 7:42 [events/0]
root 8 0.0 0.0 0 0 ? S Sep19 0:00 [cgroup]
root 9 0.0 0.0 0 0 ? S Sep19 0:00 [khelper]
root 10 0.0 0.0 0 0 ? S Sep19 0:00 [netns]
root 11 0.0 0.0 0 0 ? S Sep19 0:00 [async/mgr]
root 12 0.0 0.0 0 0 ? S Sep19 0:00 [pm]
root 13 0.0 0.0 0 0 ? S Sep19 0:23 [sync_supers]
root 14 0.0 0.0 0 0 ? S Sep19 0:24 [bdi-default]
root 15 0.0 0.0 0 0 ? S Sep19 0:00 [kintegrityd/0]
root 16 0.0 0.0 0 0 ? S Sep19 0:47 [kblockd/0]
root 17 0.0 0.0 0 0 ? S Sep19 0:00 [kacpid]
root 18 0.0 0.0 0 0 ? S Sep19 0:00 [kacpi_notify]
root 19 0.0 0.0 0 0 ? S Sep19 0:00 [kacpi_hotplug]
root 20 0.0 0.0 0 0 ? S Sep19 0:00 [ata/0]
root 21 0.0 0.0 0 0 ? S Sep19 0:00 [ata_aux]
root 22 0.0 0.0 0 0 ? S Sep19 0:00 [ksuspend_usbd]
root 23 0.0 0.0 0 0 ? S Sep19 0:00 [khubd]
root 24 0.0 0.0 0 0 ? S Sep19 0:00 [kseriod]
root 25 0.0 0.0 0 0 ? S Sep19 0:00 [md/0]
root 26 0.0 0.0 0 0 ? S Sep19 0:00 [md_misc/0]
root 27 0.0 0.0 0 0 ? S Sep19 0:01 [khungtaskd]
root 28 0.0 0.0 0 0 ? S Sep19 0:00 [kswapd0]
root 29 0.0 0.0 0 0 ? SN Sep19 0:00 [ksmd]
root 30 0.0 0.0 0 0 ? S Sep19 0:00 [aio/0]
root 31 0.0 0.0 0 0 ? S Sep19 0:00 [crypto/0]
root 36 0.0 0.0 0 0 ? S Sep19 0:00 [kthrotld/0]
root 38 0.0 0.0 0 0 ? S Sep19 0:00 [kpsmoused]
root 39 0.0 0.0 0 0 ? S Sep19 0:00 [usbhid_resumer]
root 70 0.0 0.0 0 0 ? S Sep19 0:00 [iscsi_eh]
root 74 0.0 0.0 0 0 ? S Sep19 0:00 [cnic_wq]
root 75 0.0 0.0 0 0 ? S< Sep19 0:00 [bnx2i_thread/0]
root 87 0.0 0.0 0 0 ? S Sep19 0:00 [kstriped]
root 123 0.0 0.0 0 0 ? S Sep19 0:00 [ttm_swap]
root 130 0.0 0.0 0 0 ? S< Sep19 0:04 [kslowd000]
root 131 0.0 0.0 0 0 ? S< Sep19 0:05 [kslowd001]
root 231 0.0 0.0 0 0 ? S Sep19 0:00 [scsi_eh_0]
root 232 0.0 0.0 0 0 ? S Sep19 0:00 [scsi_eh_1]
root 291 0.0 0.0 0 0 ? S Sep19 0:35 [kdmflush]
root 293 0.0 0.0 0 0 ? S Sep19 0:00 [kdmflush]
root 313 0.0 0.0 0 0 ? S Sep19 2:11 [jbd2/dm-0-8]
root 314 0.0 0.0 0 0 ? S Sep19 0:00 [ext4-dio-unwrit]
root 396 0.0 0.0 2924 1124 ? S<s Sep19 0:00 /sbin/udevd -d
root 705 0.0 0.0 0 0 ? S Sep19 0:00 [kdmflush]
root 743 0.0 0.0 0 0 ? S Sep19 0:00 [jbd2/sda1-8]
root 744 0.0 0.0 0 0 ? S Sep19 0:00 [ext4-dio-unwrit]
root 745 0.0 0.0 0 0 ? S Sep19 0:00 [jbd2/dm-2-8]
root 746 0.0 0.0 0 0 ? S Sep19 0:00 [ext4-dio-unwrit]
root 819 0.0 0.0 0 0 ? S Sep19 0:18 [kauditd]
root 1028 0.0 0.0 3572 748 ? Ss Sep19 0:00 /sbin/dhclient -1 -q -lf /var/lib/dhclient/dhclient-eth0.leases -pf /var/run/dhclient-eth0.pid eth0
root 1072 0.0 0.0 13972 828 ? S<sl Sep19 2:13 auditd
root 1090 0.0 0.0 2052 512 ? Ss Sep19 0:00 /sbin/portreserve
root 1097 0.0 0.2 37568 3940 ? Sl Sep19 2:01 /sbin/rsyslogd -i /var/run/syslogd.pid -c 5
rpc 1120 0.0 0.0 2568 800 ? Ss Sep19 0:09 rpcbind
rpcuser 1138 0.0 0.0 2836 1224 ? Ss Sep19 0:00 rpc.statd
root 1161 0.0 0.0 0 0 ? S Sep19 0:00 [rpciod/0]
root 1165 0.0 0.0 2636 472 ? Ss Sep19 0:00 rpc.idmapd
root 1186 0.0 0.0 2940 756 ? Ss Sep19 13:27 lldpad -d
root 1195 0.0 0.0 0 0 ? S Sep19 0:00 [scsi_tgtd/0]
root 1196 0.0 0.0 0 0 ? S Sep19 0:00 [fc_exch_workque]
root 1197 0.0 0.0 0 0 ? S Sep19 0:00 [fc_rport_eq]
root 1199 0.0 0.0 0 0 ? S Sep19 0:00 [fcoe_work/0]
root 1200 0.0 0.0 0 0 ? S< Sep19 0:00 [fcoethread/0]
root 1201 0.0 0.0 0 0 ? S Sep19 0:00 [bnx2fc]
root 1202 0.0 0.0 0 0 ? S< Sep19 0:00 [bnx2fc_l2_threa]
root 1203 0.0 0.0 0 0 ? S< Sep19 0:00 [bnx2fc_thread/0]
root 1206 0.0 0.0 2184 564 ? Ss Sep19 1:08 /usr/sbin/fcoemon --syslog
root 1240 0.0 0.0 8556 976 ? Ss Sep19 1:22 /usr/sbin/sshd
root 1415 0.0 0.1 12376 2088 ? Ss Sep19 6:09 sendmail: accepting connections
smmsp 1424 0.0 0.0 12168 1680 ? Ss Sep19 0:02 sendmail: Queue runner@01:00:00 for /var/spool/clientmqueue
root 1441 0.0 0.0 5932 1260 ? Ss Sep19 0:56 crond
root 1456 0.0 0.0 2004 504 tty2 Ss+ Sep19 0:00 /sbin/mingetty /dev/tty2
root 1458 0.0 0.0 2004 504 tty3 Ss+ Sep19 0:00 /sbin/mingetty /dev/tty3
root 1460 0.0 0.0 2004 508 tty4 Ss+ Sep19 0:00 /sbin/mingetty /dev/tty4
root 1462 0.0 0.0 2004 504 tty5 Ss+ Sep19 0:00 /sbin/mingetty /dev/tty5
root 1464 0.0 0.0 2004 508 tty6 Ss+ Sep19 0:00 /sbin/mingetty /dev/tty6
root 1467 0.0 0.0 3316 1740 ? S< Sep19 0:00 /sbin/udevd -d
root 1468 0.0 0.0 3316 1740 ? S< Sep19 0:00 /sbin/udevd -d
apache 3796 0.0 0.4 32668 9452 ? S Dec16 0:08 /usr/sbin/httpd
apache 3800 0.0 0.4 32404 9444 ? S Dec16 0:08 /usr/sbin/httpd
apache 3801 0.0 0.4 33184 9556 ? S Dec16 0:07 /usr/sbin/httpd
apache 3821 0.0 0.4 32668 9612 ? S Dec16 0:08 /usr/sbin/httpd
apache 3840 0.0 0.4 32668 9612 ? S Dec16 0:07 /usr/sbin/httpd
apache 3841 0.0 0.4 32404 9464 ? S Dec16 0:07 /usr/sbin/httpd
apache 4032 0.0 0.4 32668 9632 ? S Dec16 0:07 /usr/sbin/httpd
apache 4348 0.0 0.4 32668 9460 ? S Dec16 0:07 /usr/sbin/httpd
apache 4355 0.0 0.4 32664 9464 ? S Dec16 0:07 /usr/sbin/httpd
apache 4356 0.0 0.5 32660 9728 ? S Dec16 0:07 /usr/sbin/httpd
apache 4422 0.0 0.4 32676 9460 ? S Dec16 0:06 /usr/sbin/httpd
root 5002 0.0 0.0 2004 504 tty1 Ss+ Nov21 0:00 /sbin/mingetty /dev/tty1
root 7540 0.0 0.0 5112 1380 ? S Dec17 0:00 /bin/sh /usr/bin/mysqld_safe --datadir=/var/lib/mysql --socket=/var/lib/mysql/mysql.sock --pid-file=/var/run/mysqld/mysqld.pid --basedir=/usr --user=mysql
mysql 7642 0.1 1.0 136712 20140 ? Sl Dec17 2:35 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
root 8001 0.0 0.4 31028 9600 ? Ss Dec13 0:18 /usr/sbin/httpd
root 8092 0.0 0.0 0 0 ? S 13:47 0:00 [flush-253:2]
root 8511 0.0 0.0 0 0 ? S 13:48 0:00 [flush-8:0]
root 8551 16.0 0.4 28612 8008 pts/0 S+ 13:49 0:00 php test-mysql-connection.php exit
root 8552 44.0 0.1 11836 3252 ? Ss 13:49 0:00 sshd: root@notty
root 8560 0.0 0.0 4924 1032 ? Rs 13:49 0:00 ps axu
root 12520 0.0 0.1 11500 3212 ? Ss 09:05 0:00 sshd: jonwire [priv]
jonwire 12524 0.0 0.1 11832 1944 ? S 09:05 0:05 sshd: jonwire@pts/0
jonwire 12525 0.0 0.0 5248 1736 pts/0 Ss 09:05 0:00 -bash
root 16309 0.0 0.0 5432 1436 pts/0 S 12:01 0:00 su -
root 16313 0.0 0.0 5244 1732 pts/0 S 12:01 0:00 -bash
apache 16361 0.0 0.5 32908 9836 ? S Dec15 0:08 /usr/sbin/httpd
apache 16363 0.0 0.5 32908 9784 ? S Dec15 0:08 /usr/sbin/httpd
apache 16364 0.0 0.4 32660 9612 ? S Dec15 0:08 /usr/sbin/httpd
apache 16365 0.0 0.4 32668 9608 ? S Dec15 0:08 /usr/sbin/httpd
apache 16366 0.0 0.7 35076 13948 ? S Dec15 0:08 /usr/sbin/httpd
apache 16367 0.0 0.4 32248 9264 ? S Dec15 0:08 /usr/sbin/httpd
apache 16859 0.0 0.5 32916 9844 ? S Dec15 0:08 /usr/sbin/httpd
apache 20379 0.0 0.4 32248 8904 ? S Dec15 0:08 /usr/sbin/httpd
root 28368 0.0 0.0 0 0 ? S Nov01 0:21 [flush-253:0]
apache 31973 0.0 0.4 31668 8608 ? S Dec16 0:08 /usr/sbin/httpd
)
『 』의 ps axu여기 꽤 쓸모없는 것들이 있습니다. 왜냐하면 저는 로컬 호스트에 연결하고 있기 때문입니다.그러나 이러한 결과를 통해 "네트워크" 지연 시간(일부 TCP/IP 버퍼)과 마찬가지로 DB 연결 지연 시간이 때때로 급증한다는 것을 알 수 있습니다.
저라면 테스트 주기를 5,000 또는 5,000회로 늘릴 것입니다.
추측할 수 있을 뿐이지만 서버 로드가 제거되었고 InnoDb-Stats에서 빨간색 플래그를 확인했다고 가정합니다(phpmyadmin은 전문적인 도구가 더 있지만 이에 큰 도움이 됩니다). 남은 것은 일관성 없는 키 사용입니다.쿼리가 약간 다르고 차선의 인덱스가 사용되는 별자리가 있을 수 있습니까?
다음을 추가하십시오.FORCE INDEX PRIMARY테스트를 반복할 수도 있습니다.
이러한 맥락에서 MySQL 문제를 진단하는 데 매우 유용한 것은 mysql tuner입니다.이것은 MySQL의 인스턴스를 살펴보고 다양한 튜닝 개선을 제안하는 PERL 스크립트입니다.솔직히, 당신이 할 수 있는 모든 튜닝을 추적하는 것은 어려워지고 이 스크립트는 잠재적인 초크 포인트에 대한 분석을 제공하는 데 훌륭합니다.
Linux 자체의 작동 방식을 고려해야 합니다. 이는 무작위로 지연되는 이유를 설명할 수도 있습니다.를 할 때topLinux 박스(로드에 관계없이 모든 박스)에서는 메모리가 거의 완전히 사용되고 있음을 알 수 있습니다(재부팅하지 않은 경우).이것은 당신의 상자의 문제나 과부하가 아닙니다.한 한 하지 않는 파일로 전환합니다. 체제RAM이라고 함)와로, 큰 Linux를 입니다. 일반적으로 큰 문제는 아니지만 아마도 사용하고 있을 것입니다.InnoDB테이블 유형(현재 기본값)으로, 시간을 절약하기 위해 RAM에 항목을 로드합니다.쿼리가 RAM에 로드되었지만(속도가 빠름) 스왑 파일로 스왑 아웃될 수 있을 정도로(훨씬 느림) 유휴 상태에 있을 수 있습니다.따라서 Linux가 RAM으로 다시 이동하는 동안 성능이 저하될 수 있습니다(MySQL이 디스크에서 이동하는 것보다 스왑 파일이 더 효율적임).도 MySQL도 ㅠㅠㅠInnoDB그들에 관한 한, 그것은 여전히 RAM에 있기 때문에 이것을 말할 수 있는 방법이 있습니다.문제는 이 블로그에 자세히 설명되어 있으며, 관련 부분은 다음과 같습니다.
일반적으로 약간의 스왑 사용량은 문제가 없을 수 있지만(스왑 인/아웃 작업이 매우 중요함), 대부분의 경우 InnoDB의 버퍼 풀 일부를 비롯한 "실제" 유용한 메모리가 스왑되고 있습니다.다시 한 번 필요한 경우, 이를 다시 스왑하기 위해 큰 성능 저하가 발생하여 임의 쿼리에서 무작위 지연이 발생합니다.이로 인해 프로덕션 시스템에서 전체적으로 예측할 수 없는 성능이 발생할 수 있으며, 스왑이 시작되면 시스템이 성능 저하 스파이럴 상태에 빠질 수 있습니다.
기본 하드웨어의 문제가 이 문제의 원인임을 알게 되었습니다.VMotion을 사용하여 서버를 새 하드웨어로 이동하여 문제가 해결되었습니다.VMware에서 하드웨어 관련 경고나 문제를 표시하지 않았습니다.그럼에도 불구하고 하드웨어에서 벗어나면 문제가 해결되었습니다.매우 이상합니다.
언급URL : https://stackoverflow.com/questions/20590013/mysql-query-randomly-lags
'bestsource' 카테고리의 다른 글
| 플라이웨이 Java 기반 마이그레이션에는 스프링 콩이 주입되지 않습니다. (0) | 2023.07.23 |
|---|---|
| 테이블에 열이 너무 많으면 성능이 저하됩니까? (0) | 2023.07.23 |
| PHP 실제 최대 업로드 크기 가져오기 (0) | 2023.07.23 |
| 동일한 그림에 여러 함수를 표시하는 방법 (0) | 2023.07.18 |
| Spring Boot 사용자 지정 http 오류 응답? (0) | 2023.07.18 |