DB 연산시 서버용 CPU vs 일반 PC용 CPU 성능 및 안정성 문의

   조회 5079   추천 0    

안녕하세요.
통계 처리용 CPU를 구축시에 제온과 같은 서버용 CPU를 사용할 때와 일반 CPU용 CPU를 사용했을 때 성능 차이가 많이 날까요?
물론 어떤류의 통계냐, 데이터량이 얼마나 되냐, 쿼리는 어느정도 효율적이냐에 따라 모두 달라지겠지만.
모든 조건이 동일하고 단순히 씨피유만 다르다는 가정 하에, 서비스용이 아닌 통계용 서버를 돌리는 경우 사양 높은 일반 PC용 CPU를 사용해도
무난한가에 대해 궁금증이 생겼습니다.

감사합니다.


------- 추가 ---------

통계는 MySQL에 데이터들을 적재해두고 Python으로 필요한 조건들을 쿼리하여 처리하고 있습니다.
여러 테이블들을 조인하여 필요한 결과들을 뽑아내서 저장하는 등의 연산을 합니다. 복잡한 수치연산은 없습니다.

짧은글 일수록 신중하게.
dateno1 2023-02
시퓨자첸 문제가 없지만, ECC 지원같은건 문제됩니다
     
오월의행복 2023-02
감사합니다. ECC가 어떤 경우에 유용한가요?
뭔가 bit단위의 연산시 발생하는 error correction이 자주 발생하나요?
그분까지는 잘 몰라서..
          
박문형 2023-02
          
dateno1 2023-02
에러 자주는 안 생겨요

문젠 그걸로 데이터 손상되서 치명적일 수 도 있음

예를 들어 수량 0000 0001이야 할게 1000 0001이 되보세요

1비트만 맛 가도 이꼴입니다
          
제온프로 2023-02
통계적으로 한달에
한 두번 생긴다고 합니다
주 원인은 태양풍 문제가
가장 크다고 합니다

PC는 큰 지장 없죠
게임위주이니
               
한효석 2023-02
일반 none-ECC RAM 을 장착한 PC는  한 달 동안 켜 두면 한 두번 정도는 ECC 에러가 발생한다는 말씀이신가요?
혹시 인터넷 등에 그런 근거의 글이 있으면 좀 알려 주세요.

그렇다면 큰 일 인데...
박문형 2023-02
통계 처리용 프로그램은 어떤 것을 사용하시나요??

보통 전문프로그램들은 프로그램 제조사에서 호환되는 사양이나 시스템 리스트를 공개하는 경우가 많습니다..

아니면 그 프로그램 영업기술 담당자에게 문의하여 추천 받는 것이 좋습니다..
     
오월의행복 2023-02
아 제가 디테일을 안올렸네요..
통계처리 전용 프로그램을 사용하는건 아니고 MySQL DB에 데이터들을 적재해두고
필요한 조건들을 python으로 쿼리 날려서 처리하고 있습니다.

현재 사용하는 장비가 오래된거라 좀더 빠른 성능을 위해 새로운 장비 구매를 생각중인데,
엄청난 정밀성을 요하는 작업이 아니기에 가성비로 가는게 좋을지, 그래도 워크스테이션에 준하는 서버를 구축해야할지 고민이 됩니다.
          
김제연 2023-02
지금 cpu 막 피크찍는거 아니면 다른걸로 바꿔도 거기서 거기입니다.
               
오월의행복 2023-02
그런가요?
전체 통계에 걸리는 시간이 오래 걸리는 상황인데, 서버 여러대에 같은 데이터를 넣어두고
통계 범위를 다르게 해서 전체 시간을 1/n으로 만드는게 최선이 되겠군요...
                    
김제연 2023-02
지금 문제가 되는게 오래되서 문제가 되시는건가요 ? -> 새 하드웨어로의 이사 
쿼리속도가 문제가 되는건가요? -> 싱글코어 높은 적당한 cpu 로
계산 속도가 느린건가요 ? -> 싱글코어 높은 적당한 cpu
100% 다 찍고 있나요? -> 모든 코어를 다 활용하는 프로그램 인거 같으니 .. 싱글코어 성능 좋고 코어 많은것으로 이사

저라면 5600 같은 흔한 컴퓨터에서 지금껄 테스트 해볼것 같습니다..
                         
오월의행복 2023-02
디테일한 답변 감사드립니다!
현재 놀고있는 일반 PC에 세팅해서 먼저 테스트를 해봐야겠습니다.
비슷한 속도나 결과를 낸다면 여러대 세팅해서 병렬로 돌려야겠네요.
지금 직면한 문제는 장비가 오래되서라기보다, 해당 서버로 통계만 돌리는게 아니라 여러 용도로 사용하고 있어서
전체적으로 느려지는 경우가 종종 있기에 전용 장비를 갖추기 위해 알아보는 중이었습니다.
말씀하신대로 일반적인 장비로도 커다란 차이가 나는게 아니라면 남는 구형 PC등을 여러대 활용하는 것을 고려해봐야겠네요.
                         
박문형 2023-02
사용하시는 시스템 플랫폼이나 사양 CPU 종류/ 메모리 크기등을 알려주세요..

남는 구형 PC 여러 개 연결해서 클러스터링을 구축하시려는 듯한데 어떨 때는 그것이 돈이 더 듭니다..

그리고 구형 PC든 구형 서버든 사용하는 프로그램이 돌아갈 수 있는 최소한 마지노선이 있습니다..

요즘 중고 서버에서 최소 마지노선은 대략 E5-2600 V3/V4 정도 이고 그보다 한단계 내려갈 수는 있지만

그렇게 되면 OS 지원부터 문제가 되고 능률보다 전기만 저묵처묵 할 뿐입니다..
          
DAP박인호 2023-02
통계 처리 쿼리면
통계처리에 사용되는
데이터 양이 얼마인지에 따라 다르겠지만
램이 많을 수록 효율적일 때가 많기때문에
램을 많이 달 수 있는 서버용 CPU를 : DB에서는 코어가 많은 것 보다는 동작속도가 높은 것이 효율적인 걸로 알려져 있습니다.
               
오월의행복 2023-02
감사합니다. 현재 수백기가에 달하는 데이터를 대상으로 통계를 돌리는 상황이라 메모리도 영향을 많이 받겠군요.
참고하겠습니다.
현재 메모리를 128GB 사용하고 있습니다.
생각해보니 CPU 종류에 따라 지원하는 최대 메모리 용량도 다르군요.
                    
박문형 2023-02
데이터가 커서 디스크 I/O 가 더 걸림돌이 될 수도 있겠네요..
                    
한효석 2023-02
수백기가의 데이터에 메모리 128GB 라면 비율이 10:1 정도인데..

모든 MySQL DB 내용 중 10% 정도만 on-memory 되면 충분할 것으로 보입니다.
물론 Query 에 따라 다르기는 하지만, DB 전체 혹은 1%~10%를 Access 하지 않는 한 절대로 메모리 부족은 아닐 것으로 보이고요.
문제는 DB 자체를 SSD 에 넣는 것도 생각해 보시고요.
2nd idx 로 query 가 제대로 되는지 아니면 index 를 제대로 활용하지 못하고 상당 부분 disk I/O 가 일어나지 않는가 잘 살펴 보십시요.
CPU 를 제대로 100% 다 못쓰는데, Disk 만 깜빡이면서 response 가 느리다면 이건 DB 설계 문제일 가능성이...

혹시, 여러 테이블 조인하면 경우에 따라서 엄청난 I/O 가 발생하는 것 잘 아시죠?
약간의 data redundancy 가 발생하더라도 조인 연산이 덜 일어나도록 하는 것도 tunning 검토 대상이 된답니다.
박문형 2023-02
서버나 워크스테이션은 작업량이 많고 그에 따라 장시간 동안 시스템을 끄지 않고 구동시킵니다..

보통 꼭 재부팅이나 시스템을 꺼야 하는 상황이 아니라면 끄지 않고 데이터가 들어 있는 디스크도 시스템을 끄지 않아도

뽑아낼 수 있도록 핫플러깅 베이를 사용하고 디스크 데이터 복구/보호를 위해 레이드 장치도 사용합니다..

이렇게 장시간 시스템을 돌리게 되면 컴퓨터의 어떤 부분이라도 데이터 에러가 발생할 수 있는데 이것을 실시간으로 보정하는 것이 ECC 기능입니다..

그러나 요즘 기술이 좋아져서 PC에 사용하는 ECC 기능이 없는 메모리라도 그리 메모리 에러가 나지는 않습니다..

(PC 시스템을 사용해서 서버 프로그램을 돌려도 왠만해서는 메모리 에러가 안납니다..)

그러나 컴퓨터에서는 언제 어디서 에러가 날 수 있기에 그것을 방지하고자 ECC 기능을 사용하고 ECC 기능은 일종의 보험이라고 생각하시면 됩니다..


그 외 서버를 사용하는 이유는 많은 코어와 대용량 메모리를 사용하기 위함입니다..

일반적으로 서버CPU는 PC CPU보다 한두세대 늦은 코어 플랫폼을 사용하고 있는데 그만큼 테스트및 검증을 해야 하기 때문이라고 보시면 됩니다..
     
오월의행복 2023-02
자세한 설명 감사드립니다.
말씀해주신 내용을 종합해보면 장시간 지속적으로 작동해야하고 안정성이 필수인 경우 서버나 워크스테이션에 적합한 장비를 갖추는게 필수이고,
그렇지 않다면 일반 PC급을 이용해도 성능 면에 있어서 큰 문제는 없다는걸로 이해해도 되겠군요!
술이 2023-02
통계는 RDBMS 역할과는 달리 계산하는 부분이 강세입니다. 그래서 CPU 빨이 영향이 크고 메모리야 대부분 128G 정도(데스크탑기준) 맞추면 엥간한건 다 소화하고 그리고 통계가 많은 데이터를 기준으로 계산하기 때문에 디스크 IO쪽도 점유율이 높습니다.

즉 CPU 메모리 디스크(SSD) 전부 좋아야 됩니다. 단 CPU 처리 자체로만 봤을때는 16코어 32쓰레드 까지로도 충분하게 제온과 떨어지지 않게 데스크탑 성능 좋습니다. 단 오랫동안 CPU 점유율을 사용하기 때문에 쿨링에 많이 신경써야됩니다.
     
오월의행복 2023-02
감사합니다. CPU 성능과 SSD IO 쪽으로 접근 해보겠습니다.
쿨링 중요 메모...
박문형 2023-02
어떨 때는 PC가 최신코어라서 PC가 더 빠릅니다..

메모리 128GB 면 거의 PC에서는 최고 용량입니다..
     
오월의행복 2023-02
그렇네요 일반 PC영역에서는 128이 거의 맥시멈이군요.
위에 댓글에 더이상 댓글이 달리지 않아 이곳에 답변 드립니다.
서버 여러개를 클러스터링 하려는 것은 아니고 각각의 시스템에 같은 데이터를 넣어두고 각기 다른 범위의 통계를 진행하고
최종 결과만 한곳으로 통합하려 합니다.
     
dateno1 2023-02
최근 밝혀진건데 12/13세대 192기가 됩니다

Micron DDR5 48G*4@Gigabyte/MSI로 된답니다 (인증샷도 있음)
          
한효석 2023-02
메모리 스틱 한개당 48GB 라...
곧 64GB 도 출현 할 것 같은데요..

그런데 인텔 CPU spec 에 max memory 제한 수치는 관계가 없을까요?
인텔이 안전하게 max memory 를 128GB 로 발표한 것일까요? 아니면 장사속?
               
dateno1 2023-02
아마 256기가라고 생각되니 그럴꺼같네요

공홈에는 아직도 128기가라 적혀있는데 옛날부터 수시로 저거 안 맞는지라... (제미니던가 8기가라 적혀있는데, 16기가 잘 먹었음)
제온프로 2023-02
성능차이는 좀 납니다.. 최신 i9 13세대, i7 13세대 가 CPU는 빨라서..
응답성은 좋겠죠..  순간적인 빠바박 !!!!~!~!

그러나..... ECC의 부제
서버 플렛폼의 견고함과 내구성..의 차이
여러 장치의 이중화 -- 파워,메모리,CPU
여러 NIC 지원.
고용량 메모리 지원 여부
RAID구성(데이터보호) 정책 여부등...

등 플렛폼의 차이가 큽니다.

그리고 사무실 내에서 사용한다면.. PC 플렛폼도 고려..
전산실 랙으로 입고 한다면 그냥 랙서버 형태로..

테스트 시스템이라면 PC형도 가능
실전 서비스용이라면 랙서버로 구성
     
오월의행복 2023-02
ECC의 효용은 제가 경험해보지 못해서 와닿지 않나봅니다 ㅠㅠ
최종 서비스용  서버는 별도로 운영하기에 현재 문의한 시스템은 PC형이든 랙타입이든 문제는 안되는데,
CPU 선택에 있어서 고민이 되었었어요..ㅎㅎ
여러 분들의 답변 종합해서 결정을 내려야겠습니다 :)
          
한효석 2023-02
제 경험입니다.

ASUS X88-E WS 보드, i7-6850K, DDR4 non-ecc memory 16GB x 8 = 128GB
SSD + HDD 10개 이상 설치
Windows 2016, Hyper-V VM 20개 이상, mongo db 등

상기 구성에서 6개월간 계속 가동하여도 down 한번 되지 않았습니다.
다른 분 말씀대로 요즘 메모리 좋아서 non-ecc 라고 문제 없었습니다.
다만, 최초 설치 후에 memory check program (한 2~3 시간은 돌아갑니다) 은 한번 돌려보고 사용하세요.

따라서 요즘 최신 PC 용 CPU 쓰시면 아주 빠릿하다고 느끼실 겁니다.
참고로 12세대 이후 CPU 는 ECC memory support 하는 기능이 들어있습니다.
다만 chip set 과 ECC memory 를 끼워야 그 기능이 쓰여지기는 하겠지만.....

아이디가 "오월의" 로시작해서 소스라치게 놀랐습니다.
               
오월의행복 2023-02
앗 '오월의' 라는 것에 왜 놀라셨는지요 ^^; 아시는 분 성함이라든가...ㅎㅎ
암튼 구체적인 스펙과 함께 답변 감사드립니다.
참고가 될 것 같습니다! 메모리 체크 프로그램은 꼭 돌려봐야겠네요.
gowork 2023-02
db서버는 큰 메모리 + 플래시디스크(nvme 이상) 가... 체감향상이 큰것 같아요..

대용량 자료 불러올때 일반 디스크로 1분이상 소요되던게 플래시로 변경하니 몇초 이내로 빨라지는 놀라운 경험을 해봤습니다.....
     
오월의행복 2023-02
오 좋은 정보 감사합니다!
지금은 일반 SSD를 디스크로 사용중인데 nvme도 고려해봐야겠습니다.
          
한효석 2023-02
그래도 수백GB 를 전부 nvme 화 하는 것은 좋은데...
저는 8TB mongo db 의 access 를 빨리하려고 고민에 빠져있습니다.
               
오월의행복 2023-02
아이코 큰 고민되시겠어요 용량이 용량인지라..
제온프로 2023-02
메모리 중요한데

PC는 메모리 많이 넣어도
듀얼체널이죠 4개가 다고.

제온은 6체널로
각 cpu당 12개씩 꽂으니까요
총 24개이고
64개 꽂는 쿼드시스템은 CPU도 4개 꽂습니다

그래서 여러 작업을 같이 할수 있죠
앙드레준 2023-02
MYSQL이라시니 버전을 잘 모르겠지만... Maria라고 치고, 수백GB라면 큰 용량으로 볼 수도 있지만 그렇게 큰 것도 아닙니다.
질문을 CPU에 국한하셔서 얘기하기가 조심스럽기는 합니다만, CPU를 교체해서 뭔가 성능 향상을 기대하시는 건 아니시죠?
CPU는 적당히 안정적인 것으로 고르고 SW적인 해결이 필요하지 않을까 싶습니다.
통계를 할 때 시일이 지나면 점점 느려지는 것을 느낀다면, DB나 쿼리를 튜닝한다던가 하는 식으로요.
웨스트미어급의 구형장비로도 꽤 큰 용량의 작업도 무리가 없는게 보통이거든요.
지금도 괜찮은 사양의 장비를 운영하시는것 같은데, 하드웨어 사양이 어느 정도되면 업그레이드해도 작업 속도에 큰 차이 없습니다.
     
한효석 2023-02
+1
튜닝만이 살길이다.
          
오월의행복 2023-02
+1 살길이다!
     
오월의행복 2023-02
감사합니다. MySQL 5.7 버전 사용중입니다.
쿼리 튜닝이나 인덱스 조정도 틈틈이 같이 진행중이지만 쉽지 않군요 ㅠㅠ
말씀하신대로 사양을 업그레이드 한다고 해결될 문제가 아니라면 여러대에서 동시에 각기 다른 범위의 통계를 돌려서 시간을 줄이는 방법이 최선인 듯 하네요.
단일 쿼리 속도 문제라기보단 뽑아내야하는 결과값의 총 수량이 너무 많아서 그걸 시스템 한대로 다 뽑아내느냐, 나눠서 총 시간을 줄이느냐 문제네요.
술이 2023-02
통계는 우선순위가 CPU > 디스크 > 메모리 순으로 영향이 큽니다. RDBMS는 반대입니다. 그러나 대용량 데이터일 경우는 또 달라집니다. 그래서 저 3가지가 같이 좋아야 되고 데이터가 대용량이고 조인하는 테이블이 많아지게 되면 인덱스를 안타고 풀스캔 하는 경우가 대부분입니다.
RDBMS 는 데이터 정합성
통계나 DW 는 데이터 집중성
이렇게 생각하는게 편합니다. 통계 및 DW 같은 경우는 일반적인 인덱스를 잘 안쓰고 컬럼스토어 인덱스를 주로 사용합니다.
     
오월의행복 2023-02
감사합니다. 말씀하신대로 풀스캔 되는 경우들이 종종 있는 것 같아요.
파티셔닝이다 뭐다 다 조합해서 튜닝해보고 있습니다.
컬럼스토어 인덱스에 대해 알아보겠습니다.


QnA
제목Page 2535/5718
2014-05   5206318   정은준1
2015-12   1738285   백메가
2016-07   5059   NAS고장났다…
2018-07   5059   metaljw
2007-05   5059   조봉덕
2015-08   5059   전설속의미…
2013-07   5059   왕용필
2013-11   5059   겨울나무
2022-06   5059   sdlfkjwer
2007-07   5059   윤호용
2007-05   5060   한태동
2019-05   5060   길가던뉴비
2006-10   5060   양찬경
2016-05   5060   방o효o문
2008-06   5060   윤호용
2016-07   5060   하셀호프
2016-08   5060   매니아1
2012-08   5060   김상일
2017-08   5060   전설속의미…
2016-05   5060   신은왜
2016-07   5060   레나
2015-04   5060   용재님