저는 게임 서버 (플레이어 정보, 저장 데이터, 물건)를 MySQL (InnoDB)과 함께 NodeJS를 실행하고 있습니다. 서버는 HTTP (S) 기반이므로 아무 것도 실시간으로 볼 수 없습니다. 아래의 그래프에서 볼 수 있듯이MySQL 쿼리 시간에 이상한 스파이크가 발생했습니다.
내가 이상한 스파이크가 있어요 당신과 함께 최대 응답 시간을 볼 수 있습니다 응답 시간 그래프에
(첫번째 그래프/초 요청/초와 마지막 그래프는 쿼리입니다) 자주색 및 평균 응답 시간은 파란색으로 표시됩니다. 심지어 10 ~ 20k 봉우리의 평균값은 50 ~ 100ms이며 요청의 95 %를 유지합니다.
나는 주변을 파고 들었고 느린 쿼리가 특별한 것이 없음을 발견했습니다. 일반적으로 savedata (~ 2kb의 BLOB) 또는 사용자 이름과 같이 수정하는 플레이어 프로필 업데이트로 쿼리를 업데이트하십시오. 조인이나 그와 같은 어떤 것도 없습니다. 우리는 100K 행 이하의 테이블에 대해 이야기하고 있습니다.
서버는 4 코어 및 7GB RAM을 사용하여 MySQL 5.7을 사용하는 우분투 14.04의 Azure에서 실행됩니다.
MySQL의 설정 :
innodb_buffer_pool_size=4G
innodb_log_file_size=1G
innodb_buffer_pool_instances=4
innodb_log_buffer_size=4M
query_cache_type=0
tmp_table_size=64M
max_heap_table_size=64M
sort_buffer_size=32M
wait_timeout=300
interactive_timeout=300
innodb_file_per_table=ON
편집 : 그것은 문제가 SQL 쿼리 전에 결코 MySQL의 성능하지만 Node.js를 성능이라고 밝혀졌다. 여기에 더 많은 정보 : Node.js multer and body-parser sometimes extremely slow
디스크 처리량도 확인할 수 있습니까? 때로는 디스크도 사용 중일 수 있으며 이로 인해 스파이크가 발생할 수 있습니다. 또한 이것은 무거운 시스템을 작성하는 경우 잠금 대기, 교착 상태 등과 같은 백그라운드에서 많은 일이 발생할 수 있습니다. 이러한 행위는 이러한 종류의 결과로 이어질 수 있습니다. – Aruna
IO쪽에 이상한 일이 없습니다. 서버가 백엔드보다 많이 실행되고 있지 않습니다. –
자원을 사용하고있는 시간당 cronjob은 고정 간격으로 보입니다. 어쩌면 logrotation 또는 무언가 – verhie