카페24 퀵서버호스팅 관련 질문 드려요.

카페24 퀵서버호스팅 관련 질문 드려요.

QA

카페24 퀵서버호스팅 관련 질문 드려요.

본문

2949618301_1643906932.716.png

2주째 서버 작업 중인듯 하네요. 중간 중간 다른 일도 하면서요...

2949618301_1643910745.9613.png A 서버
A 서버는 2017년부터 사용하는 서버입니다. 당연히 모업체에 서비스를 제공하고 있었습니다.
B 서버 역시 2019년부터 사용했고, 역시 모업체에 서비스를 제공하고 있었구요.

나름 서버를 잘 아는 지인에게 부탁해서 APM 및 기타 모듈들의 설치를 진행했었습니다.

시간이 지나기도 하였고,
두 서버의 비용을 감당하는것도 만만치 않거니와, 각 서버에 남아도는 리소스들을 보고 있자니 아깝기도 했구요. 또 나름 서잘알 지인이 설치는 하였지만, rpm으로 자기만의 방식으로 설치를 해서 무언가 수정할때마다 애먹는것도 싫었구요.
또한 무엇보다 PHP7의 도입이 시급했습니다. 두 서버 모두 5.6 버전이었거든요.

그리하여
고사양의 서버 하나를 구매하여 두 서버에 있는 서비스를 합치기로 마음을 먹었습니다.(무식하면 용감한 법이죠 ㅠㅠ)

그래서!

2949618301_1643907539.6268.png
A+B 서버용으로 신규 구매를 하게 되었습니다. (A+B 서버(신규 구매 1))
나름 우여곡절이 있었지만, 그래도 AAI를 이용하여 APM을 잘 설치하였습니다.
그런데 DB 쿼리 조회 결과가...
A 서버에서 0.25초 나오는 쿼리가... 갑자기 19초가 나오는 겁니다... ㅠㅠ
인덱스도 다시 걸어보고...
덤프도 다시 넣어보고... 뭘 해도 15초 밑으로는 내려가지 않더군요. ㅠㅠ

A 서버의 서비스는 주로 사용하는 테이블이 약 500만건 정도 됩니다.
그 테이블을 4~5개의 테이블과 조인해서 사용하고 있고,
300만건 이상 테이블의 3개 정도 더 있습니다.
(천만건이 넘는것도 있습니다만, 이건 최근 데이터만 쓰니까 큰 영향은 없을 듯 합니다.)

그래서 저는...
대용량 서비스 기업에 적합한 거라서 내 서비스와는 맞지 않구나 라는 생각을 하게 됩니다.
(무식하면 용감하죠? ㅜㅜ)

 

그래서!!!
2949618301_1643907814.05.png
이 놈을 다시 구매하게 됩니다. (나중에 알았지만, 똑같은 NVMe SSD 더군요 ㅜㅜ)
"빠른 DB 처리가 필수" 라는 말에 혹 했나봅니다.
이 서버는 정말이지 심플하게 설치합니다. 한 번 경험했으니 거칠 것이 없더군요~
후루룩 설치하고 쿼리를 수행해본 결과!!!
9.3초가 웬 말인지... (이것도 나름 인덱스 다시 잡고 해서 많이 줄인겁니다. 얘도 15초 이상 나왔었습니다.)

 

서론이 너무 길었네요.

질문 드릴게요. 좀 도와주세요. (꾸뻑)

1. DB이전을 DB서버 새로 셋팅 후 덤프로 옮겼습니다. 이 경우 위와 같이 쿼리의 속도가 느려질 수 있나요? 서버의 성능은 오히려 더 좋아졌는데 말이죠...
2949618301_1643908574.6856.png

 

2. DB 인덱스나 DB 설정 등만 가지고 씨름하다 도저히 안되어서 디스크 성능을 보기로 하고, 테스트를 하니 저런 말도 안되는 결과가 나왔습니다. 아무리 생각해도 말이 안되는 결과인것 같아서요. 제가 뭘 잘못 한걸까요? Cafe24에서 초기 설치만 해주고 전 그저 APM만 설치했을 뿐인데말이죠... 혹시 제가 뭘 더 해야 하는지 알려주시면 감사하겠습니다.

 

3. 위 서버들과 동일한 성능을 제공하는 다른 호스팅 업체 소개 좀 부탁 드립니다. 끝까지 확인하고 싶네요.

 

 

 

 

 

 

 

 

 

이 질문에 댓글 쓰기 :

답변 4

그냥 전문가한테 맡기신게 답입니다.

php 못해도 7.4로 해야하고 8이면 더 좋죠

쿼리는 튜닝쪽을 선호해서.. 전문가한테 맡기세요

 

 

주변에 전문가도 잘 모르겠고,
잘 모르는 누군가에게, 그것도 원격으로 제 속살(코드의 민망함)을 보여주는것도 아찔하구요 ^^
믿으실 만한 분 있으시면 소개 좀 부탁 드려도 될까요? ^^

DB 데이터가 저장되는 곳이 HDD 로 설정된거 아닐까요?

또하나 의심해볼만한 곳은 메모리 설정을 잘못해서 DB가 swap memory 를 사용하는 경우일수도 있습니다.

맞아요. 새로 구매한 서버 모두 DB의 데이터 폴더가 NVMe SSD가 아닌 SSD에 있더군요... 헐...
그래서 NVMe SSD에 마운트 되어 있는 /home 디렉토리 밑으로 DB 데이터 폴더를 이동시켰답니다.
그래도 속도가 아주 조금 좋아졌어요. 20초에서 15초로... ㅠㅠ
그런데 생각해보니 0.25초 나오는 서버는 애초에 SSD더군요.
같은 SSD인데 속도 차이가???
NVMe SSD로 옮겼는데도 이거 밖에 안나온다고???

그래서 디스크 읽기/쓰기 테스트를 해본건데요...
저 데이터 정말 이상하죠...
어케 판단해야 하는건지 잘 모르겠어서 난감합니다. 흠냐...

디비의 환경 설정 그러니까 메모리 설정은...
검색을 통하여 처음엔 서버의 사양에 맞게(?) 셋팅했다가...
속도가 안나오니 자꾸 자꾸 바꿔보고...
그러다가 결국은 원래 서버대로도 해보고...
하... 사실 이 부분도 검색을 통해서 한거라 확신은 없답니다.... (무식하면 용감하죠? ㅜㅜ)

셋팅의 변화... 아래거에서 이거 저거 마구 바꿔봤어요.
[mysqld]
init_connect="SET collation_connection = utf8_general_ci"
init_connect="SET NAMES utf8"
character-set-server = utf8
collation-server = utf8_general_ci
slow_query_log = 1
long_query_time = 3

general_log=ON
log-err=/var/lib/mysql/error.log

innodb_file_per_table
innodb_buffer_pool_size=10G
innodb_buffer_pool_instances = 10
innodb_write_io_threads = 8
innodb_read_io_threads = 8
innodb_log_file_size = 1G

tmp_table_size=256m
max_heap_table_size = 256M

event_scheduler = ON


innodb_sort_buffer_size=64m
#innodb_force_recovery = 4

read_only=0
slave-skip-errors=all
skip-name-resolve

key_buffer_size = 768M
join_buffer_size = 4M

max_allowed_packet = 10M
table_open_cache = 512
sort_buffer_size = 64M
read_buffer_size = 64M
myisam_sort_buffer_size = 128M
thread_cache_size = 20

# Try number of CPU's*2 for thread_concurrency
thread_concurrency = 8
max_connections = 2048
table_cache = 512

# Query Cache
query_cache_limit=16M
query_cache_size=512M
query_cache_type=1




에서... 원 서버의 셋팅대로도 해보고...
[mysqld]
init_connect="SET collation_connection = utf8_general_ci"
init_connect="SET NAMES utf8"
character-set-server = utf8
collation-server = utf8_general_ci

open_files_limit = 10240
table_open_cache = 5120

max_connections = 30
key_buffer_size = 128M
join_buffer_size = 4M
sort_buffer_size = 2M
read_buffer_size = 2M
read_rnd_buffer_size = 4M
tmp_table_size = 256M
max_heap_table_size = 256M

innodb_file_per_table
innodb_buffer_pool_size = 1024M
innodb_log_file_size = 1G

thread_cache_size = 4
event_scheduler = ON

slow_query_log = 1
long_query_time = 3

general_log=ON
log-err=/var/lib/mysql/error.log

max_allowed_packet = 10M

#log-bin=/var/log/mysql/bin.log
binlog_cache_size=2M
max_binlog_size=512M
expire_logs_days=10

혹시 mysql engine이 바뀐 건 아닌가요?

원서버와 새로 설치한 서버들이 다른 점은... compact와 dynamic이군요... 무슨 차이지... 얼렁 찾아봐야겠군요...

구 서버
 table_type | engine | version | ROW_FORMAT | TABLE_COLLATION |
+------------+--------+---------+------------+-----------------+
| BASE TABLE | InnoDB |      10 | Compact    | utf8_general_ci |
| BASE TABLE | InnoDB |      10 | Compact    | utf8_general_ci |

신 서버
+------------+--------+---------+------------+-----------------+
| table_type | engine | version | ROW_FORMAT | TABLE_COLLATION |
+------------+--------+---------+------------+-----------------+
| BASE TABLE | InnoDB |      10 | Dynamic    | utf8_general_ci |
| BASE TABLE | InnoDB |      10 | Dynamic    | utf8_general_ci |
| BASE TABLE | InnoDB |      10 | Dynamic    | utf8_general_ci |
| BASE TABLE | InnoDB |      10 | Dynamic    | utf8_general_ci |
| BASE TABLE | InnoDB |      10 | Dynamic    | utf8_general_ci |

해결되었습니다. 속도도 거의 똑같이 나오구요.

해결방법은...

1. 같은 버전의 데이터 베이스를 설치하자.

2. 덤프니 뭐니 그러지 말고, mysql data 폴더를 통째로 압축하여 옮기는 것

인덱스도 완전히 똑같이 타고 쿼리 속도도 같이 나오는 것을 확인하였습니다.

답변을 작성하시기 전에 로그인 해주세요.
전체 1

회원로그인

(주)에스아이알소프트 / 대표:홍석명 / (06211) 서울특별시 강남구 역삼동 707-34 한신인터밸리24 서관 1404호 / E-Mail: admin@sir.kr
사업자등록번호: 217-81-36347 / 통신판매업신고번호:2014-서울강남-02098호 / 개인정보보호책임자:김민섭(minsup@sir.kr)
© SIRSOFT