Nhiều lõi CPU hơn so với đĩa nhanh hơn


13

Tôi là một phần của một công ty nhỏ nên như thường lệ, đảm nhiệm một số vai trò khác nhau. Cái mới nhất trong số đó là mua một hộp SQL Server chuyên dụng cho ứng dụng web .NET của chúng tôi. Chúng tôi đã được trích dẫn trên cấu hình CPU Xeon E5-2620 (sáu lõi) 2,00 GHz (tổng cộng 12 lõi), với 32 GB RAM. Điều này đã khiến chúng tôi có ngân sách hạn chế cho mảng đĩa, về cơ bản sẽ bao gồm hai ổ đĩa 2,5 "SAS 300 GB (15k RPM) trong cấu hình RAID 1.

Tôi biết rằng thiết lập đĩa là tối ưu phụ cho SQL Server và tôi thực sự muốn đẩy RAID 10 để chúng tôi có thể đặt cơ sở dữ liệu, tệp nhật ký và tempdb vào ổ đĩa của riêng họ. Để làm cho điều này tương thích với ngân sách của chúng tôi, tôi có nên xem xét giảm số lượng lõi CPU không? hoặc tôi sẽ nhận được ngân hàng tốt hơn cho việc giữ các lõi và sử dụng ít ổ đĩa hơn, có lẽ là 4 trong thiết lập RAID 1 kép?

Dưới đây là một số thống kê bổ sung

  • Cơ sở dữ liệu SQL Server nghiêng về số lượng đọc và ghi cao, có thể tương ứng là 80% so với 20%. Kích thước DB hiện tại là khoảng 10 GB 26 GB hiện tại, tăng trưởng với tốc độ 250 MB mỗi tháng.

  • Hiện đang chạy trên SQL Server 2008 R2 Standard trên hộp Xeon lõi tứ đơn được chia sẻ với máy chủ web (12 GB Ram, 2 x 10k 300GB ổ đĩa SAS trong RAID 1), đang tìm cách chuyển sang Tiêu chuẩn SQL Server 2012.

  • Cơ sở dữ liệu phục vụ khoảng 100-150 người dùng đồng thời với một số tác vụ lập lịch nền được đưa vào. Đọc này, tôi nghĩ rằng 12 lõi là quá mức cần thiết!


Tôi đã triển khai toàn bộ ứng dụng cho dịch vụ đám mây Azure (2 trường hợp nhỏ) được liên kết với SQL Azure DB. Mặc dù hiệu suất là hợp lý khi thử nghiệm (tải gần như bằng 0) Tôi đã mất can đảm để sử dụng trong sản xuất do không thể đoán trước được tôi đã đọc rất nhiều về nó. Nó có thể hoạt động tốt hơn với cách tiếp cận mở rộng, nhưng chỉ với cơ sở dữ liệu 10 GB, tôi có thể thoát khỏi việc mở rộng ngay bây giờ và tiết kiệm một số tiền mặt.

Ban đầu tôi đã bỏ qua chi phí cấp phép và không nhận ra rằng việc cấp phép SQL Server 2012 dựa trên số lượng lõi. Tôi có đăng ký BizSpark MSDN với giấy phép Tiêu chuẩn SQL Server 2012 vì vậy tôi cần đọc xem có bao nhiêu lõi sẽ sử dụng ngoài hộp.


7
10 GB? Đĩa nhanh hơn sẽ không giúp bạn rất nhiều. Tất cả dữ liệu của bạn hầu như luôn luôn nằm trong bộ nhớ ... còn RAID 10 thực sự tốn bao nhiêu tiền? Và phiên bản / phiên bản nào của SQL Server? Tôi nghi ngờ việc cấp phép phần mềm sẽ dễ dàng gấp 10-20 lần chi phí phần cứng.
Aaron Bertrand

2
Nói chung, khuyến nghị của tôi là ưu tiên RAM hơn IO và CPU. Viết khối lượng công việc lớn đòi hỏi IO tốt, nhưng cân nhắc quan trọng nhất đối với ngân sách của bạn là CPU yêu cầu thêm chi phí cấp phép. Bạn đã xem xét khía cạnh đó?
Remus Rusanu

4
Cân nhắc mua SSD. Xin lỗi, nhưng giá của 15k SAS làm cho SSD trở thành một đề xuất tốt hơn. Trên thực tế, hiện tại tôi đang ở vị trí tương tự và tôi thay thế Velciraptors 300G 10k bằng ổ 450G 10k SAS và ổ SSD 500G (được nhân đôi). Giá / lợi ích của ổ đĩa 15k SAS khiến tôi co rúm lại.
TomTom

4
@TomTom đồng ý. 15K SAS giống như phụ gia nhiên liệu cho một chiếc Datsun năm 1972 - vâng, nó sẽ tốt hơn một chút, nhưng sự khác biệt là không đáng kể, và chi phí thêm của SSD sẽ đáng giá hơn.
Aaron Bertrand

Câu trả lời:


10

Phát biểu từ kinh nghiệm khiêm tốn nhưng tôi nghĩ đáng để chia sẻ, nút thắt lớn với cơ sở dữ liệu SQL (Sybase và máy chủ SQL ở đây) là lưu trữ.

Nhưng tôi nghĩ thật công bằng khi ai đó lần đầu tiên điểm chuẩn thiết lập của họ trước khi đưa ra bất kỳ giả định sai nào. Trong trường hợp của tôi, việc sử dụng CPU chưa bao giờ tăng đủ cao để biện minh cho việc nâng cấp CPU bất cứ lúc nào sớm. Thay vào đó, tôi đã nâng cấp từ ổ đĩa đơn lên RAID 1 và sau đó lên RAID 10 + một lần nâng từ 8GB lên 16GB RAM.

Tất cả các nâng cấp RAID này đã giúp giảm thời gian chờ đợi trước đó xuống 2 đến 6. Tôi nghi ngờ việc nâng cấp lên SSD sẽ còn tốt hơn nữa. Nếu bạn nghĩ về nó, tất cả có thể được giảm xuống băng thông (lý thuyết). Kết hợp [(Tốc độ RAM + Kích thước RAM + Bộ điều khiển bộ nhớ) của bạn với CPU] có giới hạn băng thông sẽ là yếu tố quan trọng nhất trong hoạt động đọc khi dữ liệu của bạn phải luôn được lưu trong bộ nhớ cache, bộ nhớ (RAID) cụ thể của bạn có giới hạn băng thông ( ảnh hưởng đến việc đọc khi bộ nhớ cache bị mất và ghi khi xóa hoặc với nhiều máy khách ghi nhiều dữ liệu kết hợp).

Bình thường hóa tất cả các giới hạn đó càng nhiều càng tốt (mang chúng lại gần để bạn không lãng phí tài nguyên) và nâng chúng càng nhiều càng tốt (nâng cấp khi cần và chỉ khi cần, đừng để tài nguyên bị lãng phí nếu hệ thống giành chiến thắng ' t có thể sử dụng chúng bởi vì một số nút cổ chai khác đang cản trở). Cuối cùng, nút cổ chai tồi tệ nhất của bạn sẽ là hệ thống con máy chủ hoạt động kém nhất (với băng thông ít nhất) trong cấu hình cụ thể của bạn.

Tôi cũng có thể thêm rằng, trong quá trình nâng cấp, tôi đã tạo các cấu hình RAID riêng cho các tệp cơ sở dữ liệu và các tệp nhật ký cơ sở dữ liệu. Lý do là các tệp nhật ký cơ sở dữ liệu có xu hướng được viết chuyên sâu. Một tệp nhật ký được sử dụng để khôi phục cơ sở dữ liệu từ sự cố và nó luôn được ghi ngay lập tức vì một giao dịch được thực hiện trước khi bất kỳ dữ liệu nào được ghi vào tệp cơ sở dữ liệu.

Một tệp nhật ký cũng được sử dụng bởi một số máy chủ sao chép cơ sở dữ liệu nhưng hầu hết sao chép không được thực hiện ngay lập tức mà thường xuyên do đó tác động hiệu suất đọc là tối thiểu ở đây. IT nhât thi tôi nghi vậy. Tôi đã thực hiện đo điểm chuẩn tối thiểu trong khi thực hiện nâng cấp này một lần nữa, tôi khuyên mọi người trước tiên nên điểm chuẩn các cấu hình khác nhau của họ và trước tiên nâng cấp lưu trữ của họ, sau đó là RAM và liên kết mạng, trước khi nghĩ đến việc nâng cấp CPU của họ.

Sau khi nâng cấp mở rộng hơn trên hơn 5 máy chủ, tôi đã quay lại để chia sẻ kinh nghiệm của mình. Tôi chắc chắn vẫn ủng hộ cho lần đầu tiên nâng cấp lưu trữ, sau đó là RAM và sau đó là CPU. Lý do là sự chênh lệch về băng thông trong hệ thống giữa bộ nhớ, RAM và CPU, theo thứ tự từ thấp nhất đến cao nhất. Vì vậy, tôi đã nâng cấp một loạt các máy chủ từ RAID10 và RAID1 kép lên SSD.

Cách tôi đã làm vì lo ngại về chi phí (tôi có thêm 20 máy chủ để nâng cấp) là chuyển dữ liệu cơ sở dữ liệu và các tệp đối tượng sang SSD (vâng, chỉ một SSD trong RAID0) và chuyển nhật ký giao dịch cộng với tempdb sang RAIDHD 4xHDD cấu hình. Tôi đã thử nghiệm với tempdb trên SSD cũng cho kết quả tuyệt vời (thực tế là kết quả rất tốt với đôi khi truy vấn nhanh hơn 15 lần, thu được một số báo cáo mất vài giây thay vì vài phút trước đây) nhưng sau đó đã chuyển tempdb sang đĩa RAID10 vì mối quan tâm sâu sắc về ghi-viết cho SSD.

Vì vậy, bây giờ về cơ bản tôi đã quan sát thời gian phản hồi nhanh hơn 10 - 15 lần cho một số truy vấn dài nhất. SSD rất tốt để đọc dữ liệu vào RAM nhanh vì SQL Server không đưa dữ liệu vào RAM cho đến khi được yêu cầu và tất nhiên trước tiên dữ liệu cần được nạp vào RAM để được CPU xử lý (sau này, trong bộ đệm L1, L2, L3) , do đó, SSD giúp giảm thời gian chờ đợi ban đầu bởi một yếu tố rất lớn. Và SSD cũng giúp giảm thời gian tráo đổi ... xóa RAM và tải dữ liệu mới, đặc biệt nếu cơ sở dữ liệu của bạn lớn hơn có thể vừa với RAM.

Nói chung, chúng tôi rất hài lòng và đã chạy như vậy trong vài tháng trong một quá trình di chuyển chậm để cho phép các máy chủ chạy để tôi có thể thu thập thông tin cấp độ hao mòn trước khi tôi chuyển tất cả các máy chủ của mình sang cấu hình này. Và đây chỉ là SQL Server Express! : D - Chỉ cần đảm bảo rằng SSD của bạn có thể cung cấp IOPS không đổi bởi vì đó là một thứ khác tạo ra sự khác biệt lớn (chỉ cần google nó). Đó là lý do tại sao tôi chọn SSD loạt Intel DC (DataCenter).


0

Phần nào đó không phải là câu trả lời mà bạn có thể đang tìm kiếm trong phần đầu tiên, nhưng: bạn đã cân nhắc việc đẩy nó lên đám mây chưa? AWS có thể cho phép bạn cung cấp hầu hết các nhu cầu trên và mở rộng sức mua của bạn mà không phải đối phó với phần cứng.

Phần thứ hai - Phần cứng thực sự phụ thuộc vào các nhiệm vụ. Tôi có xu hướng nghiêng về nhiều CPU hơn khi tôi có thể thực hiện tích hợp CLR tùy chỉnh, vì sau đó tôi có thể tối ưu hóa cho các giải pháp thực sự song song cho các vấn đề. Hầu hết thời gian mặc dù tốt hơn là nên đặt các giải pháp dựa trên tôi thấy rằng RAM và tốc độ ổ cứng là nút cổ chai lớn nhất và dường như thứ hai là trường hợp của bạn. (Trường hợp ý tưởng SSD ở trên sẽ hữu ích)

Nếu không có bất kỳ số liệu thống kê thực tế nào từ máy chủ của bạn, tôi sẽ đề nghị bạn xem xét một số giải pháp bộ đệm để giảm ghi, (trừ khi bạn đang thực hiện một số cách ghi nhật ký với ghi hoặc những thứ cần lịch sử) và bỏ thêm tiền vào ổ cứng của bạn hơn CPU. Máy chủ SQL khá tốt trong việc truy cập song song các truy vấn (nếu chúng được viết cho nó) nhưng nếu bạn nặng về ghi, thì ổ cứng của bạn là nút cổ chai thực sự.


1
Man, bạn đã bao giờ nhìn vào CHI PHÍ của điều đó? Tỷ lệ hàng giờ cho clout là bảo hiểm khi bạn chạy 24/7. Băng thông để làm cho dữ liệu lớn lên và tải xuống là điên rồ. Chi phí cho 1gbit - thậm chí không nói 10gbit - internet để có một liên kết tương đương khi bạn cần di chuyển 50gb dữ liệu vào và ra khỏi cơ sở dữ liệu là điên rồ. Đám mây rất đẹp và bảnh bao nếu bạn (a) không SỬ DỤNG cơ sở dữ liệu từ cục bộ - tức là nó ở trong đám mây hoặc (b) nhỏ.
TomTom

Đúng là tôi đã xuống tuyến đường đám mây công cộng, thực tế tôi đã đi xuống! Hiệu suất là tầm thường, như bạn mong đợi .. nhưng với chi phí, nó không ảnh hưởng đến tôi. Tôi là tất cả để phát triển các mô hình quy mô nhưng Colo thì rẻ và bạn cần phải chi rất nhiều tiền để đến gần với bất kỳ nhà cung cấp đám mây phổ biến nào. Chắc chắn nó trừu tượng hóa cơ sở hạ tầng, nhưng ngay cả khi bạn thêm vào chi phí bảo trì phần cứng, nó vẫn là một việc khó bán.
QFDev
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.