... Hy vọng tôi có thể có được ... một ước tính sơ bộ về những gì chúng ta nên chạy.
Không có thêm thông tin về các truy vấn và kích thước dữ liệu của bạn, thực sự rất khó để cung cấp cho bạn bất kỳ loại ước tính nào, chứ chưa nói đến ước tính chính xác.
Cơ sở dữ liệu: máy chủ sql 2008 r2 cơ sở dữ liệu doanh nghiệp
Windows: Windows 2008 r2 Enterprise 64 bit, khá chắc chắn chạy trên VMware.
Bộ xử lý: Intel (R) Xeon (R) CPU E7-4860 @ 2.27GHz 2.26 GHz (2 bộ xử lý)
Bộ nhớ đã cài đặt: 4GB
Hai bộ xử lý (tôi cho rằng điều này được phơi bày trong VM là 2 lõi) có thể hoặc không được cung cấp dưới mức. Các lõi được gán cho VM không nhất thiết phải ánh xạ trực tiếp vào lõi vật lý (hoặc thậm chí được phép sử dụng 100% lõi đơn khi cần!), Vì vậy bạn có thể thấy đây là tài nguyên linh hoạt hơn bộ nhớ. Nếu không có thêm thông tin nào về khối lượng công việc hoặc cấu hình phần cứng / ảo hóa của bạn, tôi sẽ nói rằng việc tăng lên 4 sẽ rất tốt.
Cấp phát bộ nhớ. Oh Boy. Đây là hiển nhiên dưới được cung cấp cho khối lượng công việc. Bản thân Windows cần tối thiểu 2-3 GB để luôn vui vẻ và mỗi trong số 2 người dùng chạy BIDS trên hộp sẽ cần ít nhất 500 MB mỗi cái. Và với điều đó, hộp đã được tối đa hóa và tôi thậm chí không bắt đầu tìm hiểu cơ sở dữ liệu sẽ cần bao nhiêu .
Phần lớn người dùng tương tác với cơ sở dữ liệu thông qua trang web asp.net và trang web máy chủ Báo cáo.
Bạn đã không nói, nhưng nếu những thứ này đang chạy trên cùng một hộp, thì cũng cần phải tính đến các yêu cầu về bộ nhớ cho chúng.
Cuối cùng, chúng tôi có một hoạt động lưu trữ dữ liệu khá liên quan, có thể mang lại 3 triệu bản ghi mỗi ngày bằng các gói SSIS cũng chạy trên máy chủ.
Giả sử điều này chạy vào ban đêm khi không có người dùng trực tiếp trên hệ thống, tôi không xem đây là sự cố trừ khi mất quá nhiều thời gian để chạy. Phần này của những điều là ít lo lắng nhất của bạn; người dùng trực tiếp là quan trọng hơn.
Các yêu cầu trước đây của chúng tôi về bộ nhớ bổ sung đã bị từ chối với phản hồi chung rằng chúng tôi cần thực hiện nhiều tối ưu hóa truy vấn hơn.
Như tôi đã trình bày ở trên, lượng bộ nhớ hiện tại được cung cấp là hoàn toàn không đủ. Tuy nhiên, đồng thời, ở đầu kia của quang phổ, cực kỳ khó có khả năng bạn sẽ có đủ bộ nhớ được cung cấp để có thể giữ toàn bộ cơ sở dữ liệu trong bộ nhớ cùng một lúc.
Mặc dù bạn đã nhận được phản hồi như vậy (nhân tiện, có lẽ có liên quan nhiều hơn đến mức độ thuyết phục của bạn đối với các tài nguyên bổ sung, và không phải là việc sử dụng tài nguyên thực tế ), rất có thể hiệu quả của cơ sở dữ liệu có thể được cải thiện. Tuy nhiên, không có số lượng điều chỉnh một mình có thể khắc phục các vấn đề bạn gặp phải bây giờ; gợi ý về điều đó là hoàn toàn không bắt đầu với tôi.
Tôi sẽ sử dụng cách tiếp cận tổng thể rằng lượng bộ nhớ hiện được cung cấp thấp hơn mức tối thiểu cần thiết (cần được sửa ASAP) và có thể cần thêm tài nguyên để cải thiện trải nghiệm người dùng đến mức có thể sử dụng được trong khi cải tiến được thực hiện để tăng hiệu quả các hệ thống.
Dưới đây là một vài suy nghĩ (theo thứ tự tấn công):
Bạn sẽ giành chiến thắng nếu bạn có thể chứng minh hiệu suất cải thiện bao nhiêu mỗi khi bạn nhận được nhiều tài nguyên hơn. Theo dõi các số liệu hiệu suất bằng cách sử dụng ghi nhật ký theo dõi hiệu suất (lưu ý: phần ghi nhật ký là rất quan trọng), bao gồm cả thời gian phản hồi của trang web nếu bạn có thể. Bắt đầu làm điều này bây giờ , trước khi làm bất cứ điều gì khác. Khi cuối cùng bạn cũng đạt được dung lượng bộ nhớ tối thiểu (bạn sẽ không nhận được 32 GB ngay lập tức), đột nhiên bây giờ bạn có bằng chứng cho thấy bộ nhớ được thêm vào đã cải thiện mọi thứ ... điều đó có nghĩa là thêm nhiều hơn nữa cũng có thể giúp ích! Nếu bạn không thu thập đường cơ sở trên cấu hình hiện tại, bạn sẽ bỏ lỡ chiếc thuyền khi mọi thứ được nâng lên đến mức tối thiểu được đề xuất.
Phân tích số liệu thống kê chờ máy chủ của bạn . Điều này sẽ cho bạn biết nút thắt lớn nhất trong hệ thống là gì. Bạn có thể có PAGEIOLATCH_XXthời gian chờ phổ biến nhất / cao nhất, cho biết quá nhiều I / O đang được thực hiện để tìm nạp các trang từ đĩa. Điều này có thể được giảm bớt bằng cách thêm bộ nhớ, do đó, I / O vật lý trở nên ít thường xuyên hơn vì dữ liệu cần thiết đã có trong bộ nhớ. Mặc dù phân tích này gần như là một kết luận bỏ qua, nhưng thực tế bạn đã thu thập các số liệu thống kê này mang lại cho bạn nhiều đạn hơn khi chứng minh sự cần thiết của tài nguyên.
Như tôi đã đề cập ở trên, yêu cầu tối thiểu cho bộ nhớ không được đáp ứng. Thu thập tập hợp các yêu cầu phần cứng được đề xuất cho tất cả phần mềm bạn đang chạy và cũng có thể chụp ảnh màn hình của Trình quản lý tác vụ. Chỉ riêng điều này là đủ để biện minh cho ít nhất 4-8 GB, ngay tại chỗ. Nếu họ vẫn từ chối, hãy cố gắng thuyết phục họ cho phép bạn dùng thử trong một tuần và trả lại sau đó (bạn đang thu thập số liệu thống kê hiệu suất, vì vậy bạn sẽ không cần phải trả lại vì giữa tuần bạn ' sẽ có thể chứng minh tình hình đã cải thiện bao nhiêu). Nếu họ vẫn từ chối, bạn sẽ bị thất bại; URLT .
Nếu bạn có thể giảm tải một số khối lượng công việc (đặc biệt, tránh từ xa nếu có thể), điều này sẽ tăng lượng bộ nhớ có sẵn cho cơ sở dữ liệu, điều này quan trọng hơn.
Bạn sẽ không thể điều chỉnh toàn bộ cơ sở dữ liệu trong bộ nhớ cùng một lúc, điều đó có nghĩa là bạn cần phải thiết lập cài đặt bộ nhớ tối đa của SQL Server rất cẩn thận để ngăn chặn quá mức bộ nhớ , điều này sẽ giết chết hiệu năng như mọi thứ khác . Over-commit thực sự thậm chí còn tệ hơn là không thể phù hợp với tất cả dữ liệu trong bộ nhớ. Rất có khả năng bạn đang ở trong kịch bản này ngay bây giờ đơn giản vì hoàn toàn không có bộ nhớ và có thể cài đặt bộ nhớ tối đa được đặt thành mặc định (không giới hạn).
Vì bạn đang chạy SQL Server Enterprise Edition và bộ nhớ ở mức cao, tôi sẽ cân nhắc mạnh mẽ việc thực hiện nén dữ liệu . Điều này sẽ đánh đổi sự gia tăng sử dụng CPU để tiết kiệm bộ nhớ (và do đó giảm truy cập đĩa, tương đối chậm).
Điều chỉnh cơ sở dữ liệu. Có khả năng các cấu trúc và truy vấn có thể sử dụng các cải tiến cho đến khi lập chỉ mục và các mẫu truy cập. Ngoài ra, nếu nhiều dữ liệu thường xuyên được quét và tổng hợp, việc tạo các chế độ xem được lập chỉ mục, bảng tóm tắt hoặc báo cáo được tính toán trước có thể rất hữu ích.
Đây có thể là một khoảng thời gian dài bởi vì nó có thể có nghĩa là cung cấp phần cứng nhiều hơn, nhưng thực hiện một giải pháp bộ đệm. Truy vấn nhanh nhất là một truy vấn bạn không bao giờ thực hiện .
Đó chỉ là một vài ý tưởng. Điểm mấu chốt là điều chỉnh một mình sẽ không giải quyết được các vấn đề ở đây, cũng như một mình phần cứng, mặc dù điều sau có lẽ sẽ làm giảm bớt phần lớn các vấn đề trước mắt. Đó thực sự là cách nó diễn ra: ném phần cứng vào vấn đề trong thời gian ngắn để dập tắt đám cháy và điều chỉnh vấn đề trong dài hạn để khắc phục nguyên nhân gốc rễ tốt nhất có thể.