안녕Ȣ16;세요.
통계 처리용 CPU를 구축시에 1228;온과 같1008; 서버용 CPU를 사용할 ǐ12;와 1068;0152; CPU용 CPU를 사용했1012; ǐ12; 성능 차1060;가 많1060; DŽ16;까요?
물론 Ǻ12;떤류1032; 통계냐, 데1060;터량1060; 얼마나 .104;냐, 쿼리lj16; Ǻ12;lj12;1221;도 효율1201;1060;냐에 따라 모.160; 달라1648;,192;1648;만.
모든 1312;,148;1060; ᇼ1;1068;Ȣ16;고 단순7176; 씨피유만 다르다lj16; 가1221; Ȣ16;에, 서비스용1060; 아닌 통계용 서버를 돌리lj16; ᅆ1;우 사양 높1008; 1068;0152; PC용 CPU를 사용해도
무DŽ12;한가에 대해 Ƽ17;금1613;1060; 생겼습니다.
감사합니다.
------- 추가 ---------
통계lj16; MySQL에 데1060;터들1012; 1201;1116;해.160;고 Python1004;/196; 필요한 1312;,148;들1012; 쿼리Ȣ16;여 처리Ȣ16;고 1080;습니다.
여러 테1060;블들1012; 1312;1064;Ȣ16;여 필요한 결과들1012; 뽑아내서 1200;1109;Ȣ16;lj16; መ1;1032; 연산1012; 합니다. 복1105;한 수치연산1008; 없습니다.
뭔가 bit단위의 연산시 발생하는 error correction이 자주 발생하나요?
그분까지는 잘 몰라서..
오류정정코드 나무위키
문젠 그걸로 데이터 손상되서 치명적일 수 도 있음
예를 들어 수량 0000 0001이야 할게 1000 0001이 되보세요
1비트만 맛 가도 이꼴입니다
한 두번 생긴다고 합니다
주 원인은 태양풍 문제가
가장 크다고 합니다
PC는 큰 지장 없죠
게임위주이니
혹시 인터넷 등에 그런 근거의 글이 있으면 좀 알려 주세요.
그렇다면 큰 일 인데...
보통 전문프로그램들은 프로그램 제조사에서 호환되는 사양이나 시스템 리스트를 공개하는 경우가 많습니다..
아니면 그 프로그램 영업기술 담당자에게 문의하여 추천 받는 것이 좋습니다..
통계처리 전용 프로그램을 사용하는건 아니고 MySQL DB에 데이터들을 적재해두고
필요한 조건들을 python으로 쿼리 날려서 처리하고 있습니다.
현재 사용하는 장비가 오래된거라 좀더 빠른 성능을 위해 새로운 장비 구매를 생각중인데,
엄청난 정밀성을 요하는 작업이 아니기에 가성비로 가는게 좋을지, 그래도 워크스테이션에 준하는 서버를 구축해야할지 고민이 됩니다.
전체 통계에 걸리는 시간이 오래 걸리는 상황인데, 서버 여러대에 같은 데이터를 넣어두고
통계 범위를 다르게 해서 전체 시간을 1/n으로 만드는게 최선이 되겠군요...
쿼리속도가 문제가 되는건가요? -> 싱글코어 높은 적당한 cpu 로
계산 속도가 느린건가요 ? -> 싱글코어 높은 적당한 cpu
100% 다 찍고 있나요? -> 모든 코어를 다 활용하는 프로그램 인거 같으니 .. 싱글코어 성능 좋고 코어 많은것으로 이사
저라면 5600 같은 흔한 컴퓨터에서 지금껄 테스트 해볼것 같습니다..
현재 놀고있는 일반 PC에 세팅해서 먼저 테스트를 해봐야겠습니다.
비슷한 속도나 결과를 낸다면 여러대 세팅해서 병렬로 돌려야겠네요.
지금 직면한 문제는 장비가 오래되서라기보다, 해당 서버로 통계만 돌리는게 아니라 여러 용도로 사용하고 있어서
전체적으로 느려지는 경우가 종종 있기에 전용 장비를 갖추기 위해 알아보는 중이었습니다.
말씀하신대로 일반적인 장비로도 커다란 차이가 나는게 아니라면 남는 구형 PC등을 여러대 활용하는 것을 고려해봐야겠네요.
남는 구형 PC 여러 개 연결해서 클러스터링을 구축하시려는 듯한데 어떨 때는 그것이 돈이 더 듭니다..
그리고 구형 PC든 구형 서버든 사용하는 프로그램이 돌아갈 수 있는 최소한 마지노선이 있습니다..
요즘 중고 서버에서 최소 마지노선은 대략 E5-2600 V3/V4 정도 이고 그보다 한단계 내려갈 수는 있지만
그렇게 되면 OS 지원부터 문제가 되고 능률보다 전기만 저묵처묵 할 뿐입니다..
통계처리에 사용되는
데이터 양이 얼마인지에 따라 다르겠지만
램이 많을 수록 효율적일 때가 많기때문에
램을 많이 달 수 있는 서버용 CPU를 : DB에서는 코어가 많은 것 보다는 동작속도가 높은 것이 효율적인 걸로 알려져 있습니다.
참고하겠습니다.
현재 메모리를 128GB 사용하고 있습니다.
생각해보니 CPU 종류에 따라 지원하는 최대 메모리 용량도 다르군요.
모든 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 검토 대상이 된답니다.
보통 꼭 재부팅이나 시스템을 꺼야 하는 상황이 아니라면 끄지 않고 데이터가 들어 있는 디스크도 시스템을 끄지 않아도
뽑아낼 수 있도록 핫플러깅 베이를 사용하고 디스크 데이터 복구/보호를 위해 레이드 장치도 사용합니다..
이렇게 장시간 시스템을 돌리게 되면 컴퓨터의 어떤 부분이라도 데이터 에러가 발생할 수 있는데 이것을 실시간으로 보정하는 것이 ECC 기능입니다..
그러나 요즘 기술이 좋아져서 PC에 사용하는 ECC 기능이 없는 메모리라도 그리 메모리 에러가 나지는 않습니다..
(PC 시스템을 사용해서 서버 프로그램을 돌려도 왠만해서는 메모리 에러가 안납니다..)
그러나 컴퓨터에서는 언제 어디서 에러가 날 수 있기에 그것을 방지하고자 ECC 기능을 사용하고 ECC 기능은 일종의 보험이라고 생각하시면 됩니다..
그 외 서버를 사용하는 이유는 많은 코어와 대용량 메모리를 사용하기 위함입니다..
일반적으로 서버CPU는 PC CPU보다 한두세대 늦은 코어 플랫폼을 사용하고 있는데 그만큼 테스트및 검증을 해야 하기 때문이라고 보시면 됩니다..
말씀해주신 내용을 종합해보면 장시간 지속적으로 작동해야하고 안정성이 필수인 경우 서버나 워크스테이션에 적합한 장비를 갖추는게 필수이고,
그렇지 않다면 일반 PC급을 이용해도 성능 면에 있어서 큰 문제는 없다는걸로 이해해도 되겠군요!
즉 CPU 메모리 디스크(SSD) 전부 좋아야 됩니다. 단 CPU 처리 자체로만 봤을때는 16코어 32쓰레드 까지로도 충분하게 제온과 떨어지지 않게 데스크탑 성능 좋습니다. 단 오랫동안 CPU 점유율을 사용하기 때문에 쿨링에 많이 신경써야됩니다.
쿨링 중요 메모...
메모리 128GB 면 거의 PC에서는 최고 용량입니다..
위에 댓글에 더이상 댓글이 달리지 않아 이곳에 답변 드립니다.
서버 여러개를 클러스터링 하려는 것은 아니고 각각의 시스템에 같은 데이터를 넣어두고 각기 다른 범위의 통계를 진행하고
최종 결과만 한곳으로 통합하려 합니다.
Micron DDR5 48G*4@Gigabyte/MSI로 된답니다 (인증샷도 있음)
곧 64GB 도 출현 할 것 같은데요..
그런데 인텔 CPU spec 에 max memory 제한 수치는 관계가 없을까요?
인텔이 안전하게 max memory 를 128GB 로 발표한 것일까요? 아니면 장사속?
공홈에는 아직도 128기가라 적혀있는데 옛날부터 수시로 저거 안 맞는지라... (제미니던가 8기가라 적혀있는데, 16기가 잘 먹었음)
응답성은 좋겠죠.. 순간적인 빠바박 !!!!~!~!
그러나..... ECC의 부제
서버 플렛폼의 견고함과 내구성..의 차이
여러 장치의 이중화 -- 파워,메모리,CPU
여러 NIC 지원.
고용량 메모리 지원 여부
RAID구성(데이터보호) 정책 여부등...
등 플렛폼의 차이가 큽니다.
그리고 사무실 내에서 사용한다면.. PC 플렛폼도 고려..
전산실 랙으로 입고 한다면 그냥 랙서버 형태로..
테스트 시스템이라면 PC형도 가능
실전 서비스용이라면 랙서버로 구성
최종 서비스용 서버는 별도로 운영하기에 현재 문의한 시스템은 PC형이든 랙타입이든 문제는 안되는데,
CPU 선택에 있어서 고민이 되었었어요..ㅎㅎ
여러 분들의 답변 종합해서 결정을 내려야겠습니다 :)
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 를 끼워야 그 기능이 쓰여지기는 하겠지만.....
아이디가 "오월의" 로시작해서 소스라치게 놀랐습니다.
암튼 구체적인 스펙과 함께 답변 감사드립니다.
참고가 될 것 같습니다! 메모리 체크 프로그램은 꼭 돌려봐야겠네요.
대용량 자료 불러올때 일반 디스크로 1분이상 소요되던게 플래시로 변경하니 몇초 이내로 빨라지는 놀라운 경험을 해봤습니다.....
지금은 일반 SSD를 디스크로 사용중인데 nvme도 고려해봐야겠습니다.
저는 8TB mongo db 의 access 를 빨리하려고 고민에 빠져있습니다.
PC는 메모리 많이 넣어도
듀얼체널이죠 4개가 다고.
제온은 6체널로
각 cpu당 12개씩 꽂으니까요
총 24개이고
64개 꽂는 쿼드시스템은 CPU도 4개 꽂습니다
그래서 여러 작업을 같이 할수 있죠
질문을 CPU에 국한하셔서 얘기하기가 조심스럽기는 합니다만, CPU를 교체해서 뭔가 성능 향상을 기대하시는 건 아니시죠?
CPU는 적당히 안정적인 것으로 고르고 SW적인 해결이 필요하지 않을까 싶습니다.
통계를 할 때 시일이 지나면 점점 느려지는 것을 느낀다면, DB나 쿼리를 튜닝한다던가 하는 식으로요.
웨스트미어급의 구형장비로도 꽤 큰 용량의 작업도 무리가 없는게 보통이거든요.
지금도 괜찮은 사양의 장비를 운영하시는것 같은데, 하드웨어 사양이 어느 정도되면 업그레이드해도 작업 속도에 큰 차이 없습니다.
튜닝만이 살길이다.
쿼리 튜닝이나 인덱스 조정도 틈틈이 같이 진행중이지만 쉽지 않군요 ㅠㅠ
말씀하신대로 사양을 업그레이드 한다고 해결될 문제가 아니라면 여러대에서 동시에 각기 다른 범위의 통계를 돌려서 시간을 줄이는 방법이 최선인 듯 하네요.
단일 쿼리 속도 문제라기보단 뽑아내야하는 결과값의 총 수량이 너무 많아서 그걸 시스템 한대로 다 뽑아내느냐, 나눠서 총 시간을 줄이느냐 문제네요.
RDBMS 는 데이터 정합성
통계나 DW 는 데이터 집중성
이렇게 생각하는게 편합니다. 통계 및 DW 같은 경우는 일반적인 인덱스를 잘 안쓰고 컬럼스토어 인덱스를 주로 사용합니다.
파티셔닝이다 뭐다 다 조합해서 튜닝해보고 있습니다.
컬럼스토어 인덱스에 대해 알아보겠습니다.