Máy chủ kho dữ liệu. Làm thế nào để bạn tính toán thông số kỹ thuật RAM / CPU?

Tôi đang cố gắng viết một thông số kỹ thuật cho một máy chủ kho dữ liệu để nâng cấp kho dữ liệu theo kế hoạch của chúng tôi.

Khi chúng tôi chạy các máy chủ ảo trên máy chủ VMWare, chúng tôi có khả năng thêm hoặc xóa tài nguyên khi cần thiết. Trước đây, chúng tôi đã tăng thêm RAM và CPU theo yêu cầu. Khi nhu cầu của chúng tôi tăng lên, chúng tôi đã vận động để có thêm tài nguyên. (chủ yếu là đĩa & RAM).

Chúng tôi yêu cầu thêm. Họ cho chúng tôi ít nhất có thể.

Tuy nhiên, gần đây bất cứ khi nào chúng tôi nói về các tài nguyên, chúng tôi hiện đang bị chỉ trích vì không chỉ định máy ngay từ đầu và bây giờ tôi được thông báo rằng các máy chủ dev đã được tối đa hóa, không còn RAM nữa.

Chúng tôi là một tổ chức Chính quyền địa phương nhỏ với ~ 50 người dùng DW thường xuyên. Trong sử dụng hàng ngày bình thường, nó chạy tốt. Chúng tôi có hiệu suất truy vấn mdx tốt và các báo cáo và bảng điều khiển của chúng tôi rất nhanh. Người dùng hài lòng.

Tuy nhiên, các quy trình ETL của chúng tôi chạy suốt đêm và chúng tôi bắt đầu thấy bằng chứng về áp lực bộ nhớ khi xử lý đồng thời các bảng dữ liệu. Đêm qua SSIS đã thất bại với các cảnh báo về "lỗi hết bộ nhớ".

Máy chủ DW hiện tại của chúng tôi là Win 2008 R2 với 4 CPU và 16Gb RAM chạy SQL 2012 Std. Tôi có bộ nhớ máy chủ tối đa được đặt thành 12GB, còn lại 4GB cho hệ điều hành và dịch vụ, vv DW hiện tại của chúng tôi có 3 khối dữ liệu / OLAP và chúng tôi đang phát triển thêm 2.

+----------+----------+---------------+-----------+---------------+
| Datamart | Files GB |  Fact (Rows)  | Fact (Mb) | ETL & Process |
| OLAP cube|          |               |           | Time (hours)  |
+----------+----------+---------------+-----------+---------------+
| PBI      |       3  |  190,000      |  180      |  0.2          |
| FBI      |      30  |  26,100,000   |  10,000   |  1.5          |
| RBI      |     175  |  62,000,000   |  32,000   |  8.3          |
| ABI*     |     100  |  44,050,000   |  21,000   |  4.0          |
| EBI*     |      11  |  100,000,000  |  6,000    |  2.0          |
+----------+----------+---------------+-----------+---------------+
* Planned/Estimated

Máy chủ mới của chúng tôi được lên kế hoạch là Win 2012 chạy SQL 2016 Enterprise. Nó sẽ chạy SQL, SSIS, SSRS & SSAS. Dung lượng không phải là vấn đề, nhưng tôi không chắc về RAM & CPU.

Theo Hướng dẫn tham khảo kho dữ liệu theo dõi nhanh cho SQL Server 2012 , mức tối thiểu tôi nên có là 128Gb cho máy 2 ổ cắm ... có vẻ hơi quá. Các phần cứng và phần mềm Yêu cầu đối với Cài đặt SQL Server 2016 khuyến cáo tối thiểu 4Gb bộ nhớ RAM cho SQL 2016. Đó là của khá một sự khác biệt!

Vậy .. điểm khởi đầu tốt là gì? 32Gb? 64Gb? Làm thế nào để tôi biện minh cho vị trí bắt đầu của mình (thông số kỹ thuật) cho CNTT?

Có hướng dẫn tốt nào về cách tính tài nguyên máy chủ không?

Có bất kỳ quy tắc tốt của ngón tay cái?

Thành phần / số liệu chính cho kích thước RAM trong ngữ cảnh DW là gì?

• Khối lượng dữ liệu?
• Số khối?
• Thời gian để làm ETL hoặc xử lý một khối?
• Tải xử lý tối đa qua đêm hoặc hiệu suất như người dùng cuối xem trong ngày?

Câu hỏi tuyệt vời và tôi đã thực hiện một phiên về vấn đề này tại TechEd vài năm trước có tên là Xây dựng máy chủ SQL nhanh nhất:

https://channel9.msdn.com/Events/TechEd/NorthAmerica/2012/DBI328

Trong đó, tôi giải thích rằng đối với kho dữ liệu, bạn cần lưu trữ có thể cung cấp dữ liệu đủ nhanh để SQL Server tiêu thụ. Microsoft đã xây dựng một loạt các trang trắng tuyệt vời có tên là Kiến trúc tham chiếu kho dữ liệu theo dõi nhanh đi sâu vào chi tiết phần cứng, nhưng ý tưởng cơ bản là bộ nhớ của bạn cần có khả năng cung cấp hiệu suất đọc tuần tự 200-300 MB / giây, trên mỗi lõi CPU, trong để giữ cho CPU bận rộn.

Càng nhiều dữ liệu của bạn mà bạn có thể lưu trữ trong bộ nhớ, bạn càng có thể lưu trữ chậm hơn. Nhưng bạn có ít bộ nhớ hơn mức cần thiết để lưu trữ các bảng thực tế mà bạn đang xử lý, do đó tốc độ lưu trữ trở nên rất quan trọng.

Đây là các bước tiếp theo của bạn:

• Xem video đó
• Kiểm tra bộ nhớ của bạn với CrystalDiskMark ( Đây là cách )
• Với 4 lõi, bạn sẽ muốn có ít nhất 800 MB / giây thông lượng đọc tuần tự
• Nếu bạn không có điều đó, hãy cân nhắc thêm bộ nhớ cho đến khi hết đau (và lưu trữ toàn bộ cơ sở dữ liệu trong RAM là không thể tưởng tượng được)

Giả sử bạn đã có cơ sở dữ liệu 200 GB mà bạn đang xử lý và bạn không thể có đủ lưu lượng lưu trữ để giữ cho lõi của mình bận rộn. Không thể nghĩ rằng không chỉ cần 200 GB RAM, mà thậm chí còn nhiều hơn - bởi vì sau tất cả, SSIS và SSAS thực sự muốn thực hiện công việc của họ trong bộ nhớ, vì vậy bạn phải có sẵn dữ liệu của động cơ, cộng với không gian làm việc cho SSIS và SSAS.

Đây cũng là lý do tại sao mọi người cố gắng tách SSIS và SSAS thành các VM khác nhau - tất cả chúng đều cần bộ nhớ cùng một lúc.

Các theo dõi Data Warehouse Hướng dẫn tham khảo nhanh cho SQL Server 2012 thực sự là một chút out-of-date đặc biệt là nếu bạn đang di chuyển đến SQL Server 2016 (thực sự? Hãy gọi cho tôi), không chỉ về mặt thời gian, nhưng cũng có tính năng.

Trong SQL Server 2012, phiên bản dựa trên theo dõi nhanh, bạn chỉ có thể có các chỉ mục cột không phân cụm. Đây là các cấu trúc riêng biệt từ bảng chính vì vậy phải chịu thêm chi phí lưu trữ và xử lý do các bản sao dữ liệu được nén.

Từ SQL Server 2014 trở đi, bạn có thể có các chỉ mục của cửa hàng cột. Chúng cung cấp khả năng nén lớn và tăng hiệu suất tiềm năng cho các truy vấn tổng hợp / tóm tắt. Chúng hoàn toàn phù hợp với các bảng thực tế, vì vậy bảng thực tế 32 GB của bạn có thể trông giống như ~ 8-12GB. YMMV. Điều đó thay đổi cảnh quan một chút phải không? Nhìn vào bàn của bạn (và ngón tay cái trên không) bạn có thể nhận được 32 GB nhưng tôi sẽ bắn 64 GB (không giống như bạn yêu cầu 1TB) và để lại một phòng cho các dịch vụ và tăng trưởng khác, điều này biện minh cho phép bạn giữ bàn lớn nhất trong bộ nhớ, cho phép tăng trưởng và phòng cho các dịch vụ khác. Bạn không cần phải nói với họ về việc nén. Một điều bạn phải ghi nhớ với kích thước là, bây giờ bạn không chỉ định cỡ cho dữ liệu của mình, mà là nó sẽ như thế nào, nói một năm kể từ bây giờ. Tuy nhiên, cũng cần lưu ý, hiệu suất cho tìm kiếm điểm có thể rất tệ, nhưng khi bạn chuyển sang SQL Server 2016, bạn có thể thêm các chỉ mục bổ sung hoặc bạn luôn có thể xem xét Chỉ mục của Nhà kho cho Phân tích hoạt động theo thời gian thực mặc dù bạn sẽ cần nhiều bộ nhớ hơn cho điều đó :)

Bằng cách nào bạn bắt đầu sử dụng CTP, hiện tại tại CTP3.3, nó có hầu hết các tính năng bạn có thể muốn sử dụng, vì vậy bạn nói rằng bạn không có tài nguyên để dùng thử, nhưng bạn có thể dùng thử Windows Azure , quay một VM, tạo một số dữ liệu mẫu, kiểm tra độ nén, hiệu năng của các tính năng chính và truy vấn, v.v. Hoặc nếu bạn có giấy phép MSDN thì nó được tích hợp sẵn.

Tóm lại, kích thước để cho phép bảng lớn nhất của bạn nằm trong bộ nhớ (cộng với các nội dung khác) hoặc thiết lập một bản dùng thử đơn giản (miễn phí trên đám mây) để có được bằng chứng cứng mà bạn đang theo dõi. Nhớ sắp xếp lại VM của bạn khi bạn hoàn thành :)

Có lẽ trong khi phát triển và duy trì các gói ETL trên các máy phát triển cục bộ, đôi khi bạn sử dụng dữ liệu thử nghiệm có quy mô tương tự hoặc lớn hơn so với những gì bạn mong đợi trong sản xuất và nếu không thì có lẽ bạn sẽ cân nhắc làm như vậy (dữ liệu thực được ẩn danh hoặc dữ liệu thử nghiệm được tạo bằng thuật toán, nếu dữ liệu thực của bạn nhạy cảm cả).

Nếu đây là trường hợp bạn có thể chạy quy trình trong các điều kiện bộ nhớ khác nhau và cấu hình nó, để xem điểm mà RAM dừng lại tạo ra sự khác biệt lớn - hữu ích như quy tắc ngón tay cái và phỏng đoán có giáo dục, không có điểm chuẩn và hồ sơ nào có thể cung cấp câu trả lời cụ thể hơn nhiều và như một phần thưởng có thể làm nổi bật các nút thắt rõ ràng có thể dễ dàng tối ưu hóa. Tất nhiên, môi trường dev / test của bạn có thể không khớp chính xác với sản xuất, vì vậy bạn có thể cần sử dụng kinh nghiệm để diễn giải kết quả có thể thay đổi như thế nào.

Nếu bạn đang chạy SSIS trên cùng một máy với cơ sở dữ liệu thì bạn chắc chắn phải đảm bảo các phiên bản động cơ SQL Server được đặt thành không bao giờ yêu cầu tất cả bộ nhớ. Việc bỏ đói bộ nhớ không chỉ có thể gây ra lỗi OOM trong SSIS, rất lâu trước thời điểm đó, nó có thể gây ra các vấn đề hiệu năng đáng kể khi nó đệm bộ đệm vào đĩa khi nó có thể giữ chúng trong RAM. Bạn cần dự trữ bao nhiêu cho SSIS và các nhiệm vụ khác sẽ thay đổi rất nhiều tùy thuộc vào quy trình của bạn, vì vậy một lần nữa hồ sơ là một cách tốt để đánh giá điều này. Chúng tôi thường khuyên bạn nên chạy SSIS trên một máy riêng biệt để giúp việc này dễ quản lý hơn, mặc dù bạn có thể có các vấn đề về thông lượng và cấp phép mạng để xem xét ở đó.

Cập nhật

Nếu, theo nhận xét của bạn, không có tài nguyên có sẵn để thực hiện các điểm chuẩn thực tế để đánh giá hiệu suất giảm (và / hoặc lỗi OOM và các vấn đề liên quan bắt đầu xảy ra) nếu phân bổ quá ít RAM, mọi thứ trở nên sóng hơn đáng kể không có kiến ​​thức sâu sắc về các quy trình kho và ETL. Một nguyên tắc nhỏ cho chính cơ sở dữ liệu kho: bạn muốn có đủ RAM để có thể chứa toàn bộ tất cả các chỉ mục được sử dụng phổ biến nhất, và sau đó một số để cho phép dữ liệu ít được sử dụng hơn và một lần nữa cho phép tăng trưởng dự kiến ​​trong gần / tương lai trung bình.

Tính toán điều này có thể là faf - sp_spaceUsed sẽ không phá vỡ mọi thứ theo chỉ mục để bạn phải tự mình truy vấn sys.allocation_units và bạn bè. Có một vài ví dụ ngoài kia để giúp bạn bắt đầu, http://blog.sqlauthority.com/2010/05/09/sql-server-size-of-index-table-for-each-index-solution-2 / trông giống như tốt nhất trong số ít đầu tiên đến từ một tìm kiếm nhanh.

Ngoài nhu cầu tự chạy DB kho, hãy nhớ thêm vào các yêu cầu RAM cho SSIS nếu nó chạy trên cùng một máy và đảm bảo SQL Server có giới hạn RAM để đảm bảo rằng bộ nhớ này thực sự có sẵn SSIS.

Từ các kích thước dữ liệu tổng thể, bạn liệt kê ruột của tôi cho thấy rằng 32Gb sẽ là mức tối thiểu tuyệt đối mà tôi khuyên dùng cho công cụ cơ sở dữ liệu và SSIS, đặt (các) phiên bản SQL để sử dụng tối đa 26 của nó và vì bạn cũng đang chạy SSRS và các dịch vụ khác trên cùng một máy tối thiểu hợp lý với một số bằng chứng trong tương lai sẽ là 64Gb (hai phần ba dữ liệu hiện tại của bạn sẽ phù hợp với điều đó sau khi các dịch vụ và đặt chỗ khác bị cắt). Rõ ràng trích dẫn ruột của tôi sẽ không giúp bạn tiến xa trong các cuộc thảo luận với những người cơ sở hạ tầng của bạn mặc dù ...