Máy chủ thực sự cần bao nhiêu RAM?


12

Tôi có khá nhiều máy chủ được triển khai trên toàn thế giới. Họ đang chạy Windows 2003 x64 với SQL Server 2005 x64 với 6 GB RAM. Các hộp không có cấu hình tốt nhất (hoặc thậm chí có thể chấp nhận được), bởi vì người đặt hàng chúng nhiều năm trước không thực sự biết mình đang làm gì.

Các hộp tương đối hết bộ nhớ, cuối cùng sử dụng tệp hoán trang và mọi thứ chậm lại. Thông thường, phí cam kết là 5,8 GB và sau đó khi ai đó cần làm gì đó chuyên sâu (ví dụ: chạy báo cáo), con số đó sẽ đi qua mái nhà.

Tôi đã cố gắng để có được sức mạnh để có thêm bộ nhớ, nhưng tôi đang gặp phải sự phản đối lớn (ví dụ: làm cho phần mềm hoạt động hiệu quả hơn, chi phí quá cao cho tất cả các máy chủ này hoặc chứng minh rằng hộp không có đủ bộ nhớ, v.v. ..).

Có hướng dẫn (hoặc một công thức) cho một hộp cần bao nhiêu RAM mà tôi có thể trình bày cho những người không chuyên về công nghệ, để cuối cùng chúng ta có thể đặt mua thêm bộ nhớ?


Là hệ thống phát triển trong nhà?
Oskar Duveborn

@Oskar. Vâng, tôi là nhà phát triển và mã được tối ưu hóa thành địa ngục và trở lại. Đơn giản là có rất nhiều dữ liệu.
AngryHacker

Sau đó xem câu trả lời của tôi. Đây là thứ tôi chuyên.
mrdenny

Câu trả lời:


9

Không thực sự có cách nào để dễ dàng nói vì nó hoàn toàn phụ thuộc vào cách sử dụng của bạn và ứng dụng. Bạn đang tối đa hóa một máy chủ cơ sở dữ liệu ... cơ sở dữ liệu lớn như thế nào? Số liệu thống kê giao dịch của bạn là gì?

Những hạn chế trong thế giới thực là rõ ràng trong kịch bản của bạn. Bạn đang chạy một lúc trong 6 gig mà không gặp vấn đề gì, sau đó đổi chỗ và đập. Vì vậy, 6 gig là không đủ.

Nếu hiệu suất là đủ để nó ảnh hưởng đến kinh doanh, thì những người cấp cao của bạn nên nghe đủ những lời phàn nàn rằng nó là khôn ngoan để tăng bộ nhớ. Chỉ ra chi phí thời gian của bạn là bao nhiêu và sau đó tính xem sẽ tốn bao nhiêu để "điều chỉnh" máy chủ và khắc phục sự cố điều chỉnh, khi bộ nhớ được thêm vào máy chủ có thể giải quyết rất tốt vấn đề về chi phí bộ nhớ và chưa đến nửa giờ thời gian chết

Bạn sẽ không biết chính xác dung lượng bộ nhớ bạn cần cho đến khi bạn thực sự triển khai việc sử dụng thực tế và làm việc từ đó.

Điều đó nói rằng, bạn có thể muốn xác minh rằng ứng dụng của bạn thực sự là nút cổ chai. Chạy trình giám sát hiệu suất windows để xem thống kê i / o đĩa của bạn và thông lượng mạng. Xem mức độ phân mảnh của bạn là tốt ( Google là một người bạn tốt ở đây ). Bạn có thể thử kiểm tra mã cho các vấn đề rõ ràng trong đó một truy vấn đang không hiệu quả ồ ạt ( Google một lần nữa ).

Nhưng một lần nữa, tất cả phụ thuộc vào việc điều này ảnh hưởng xấu đến doanh nghiệp như thế nào. Có đáng để đầu tư vào điều chỉnh không, hay nó đủ tệ để ném phần cứng vào nó trước và sau đó thử điều chỉnh nó?


Kích thước +1 và số liệu thống kê cần thiết
Oskar Duveborn

12

Một cách dễ dàng để xem bạn có cần thêm RAM hay không là lập biểu đồ bộ đếm perfmon Expectancy của Life Life Expectancy. Bộ đếm này cho bạn biết SQL Server nghĩ rằng dữ liệu sẽ được lưu giữ trong vùng đệm bao lâu trước khi nó cần nhường chỗ cho các dữ liệu khác. Bạn muốn con số này càng cao càng tốt. Với 6 Gigs RAM được cài đặt (bạn nên cài đặt SQL ở mức tối đa có thể là 4 hợp đồng), có lẽ bạn sẽ chỉ lưu giữ dữ liệu trong bộ nhớ trong vài phút, khi ai đó chạy một báo cáo lớn, bạn sẽ thấy bể số này xuống vài giây Bạn càng có nhiều RAM, dữ liệu có thể được lưu giữ trong bộ nhớ càng lâu và việc đọc từ đĩa sẽ càng ít phải thực hiện.

Ví dụ: các hệ thống tôi đang làm việc tại thời điểm này có 256 Gigs RAM và chúng tôi giữ dữ liệu trong bộ nhớ trong khoảng 12000 giây hoặc lâu hơn.

Xin đừng yêu cầu số mục tiêu để đạt được, bạn chỉ muốn số càng cao càng tốt. Nếu không biết nhiều về hệ thống của bạn, tôi không thể đưa ra một con số tốt để thực hiện.


6

Hừm. Chà, 6 hợp đồng biểu diễn là một lượng ram khá lớn, ngay cả đối với cài đặt MSSQL lớn. Bạn thực sự có thể muốn xem và đảm bảo rằng mã của bạn thực sự hiệu quả. Giao dịch 6 gig là một chút bất thường ... Tôi đã làm việc trên các hệ thống bảng lương toàn tiểu bang không đạt được hợp đồng cao nhất vào cuối năm 1099 khi xử lý ... Và để có một hoạt động thường xuyên không? Tôi không biết. Bạn đang làm việc với loại dữ liệu nào?

Điều đó đang được nói, bạn có thể nhét RAM nhiều như bạn muốn trong hộp 64 bit và ram rất rẻ, vì vậy cũng có thể đặt nhiều vào đó nếu bạn có thể ... Không thể có quá nhiều RAM trên đó một máy chủ cơ sở dữ liệu.

Chỉnh sửa: Điều này đã hết hạn ngay bây giờ. Tôi có các hộp MSSQL với 256 hợp đồng RAM.


1
Không thể có quá nhiều RAM trên máy chủ cơ sở dữ liệu. Có lẽ là không, nhưng bạn có thể có RAM mà bạn đã lãng phí tiền vì nó không được sử dụng. Mặc dù tôi đồng ý với ý kiến ​​chung rằng nó trả tiền để hào phóng cho các hộp thực hiện một số loại nhiệm vụ nhất định, tôi không nghĩ rằng việc mở rộng tài nguyên vào một hệ thống mà không hiểu các yêu cầu của nó.
Rob Moir

2
@robert: Không giống như tôi ủng hộ việc mua một máy chủ phiến. Tối đa RAM trong máy chủ là khá dễ dàng và nếu bạn hết bộ nhớ, vậy tại sao không thêm nhiều hơn? Tôi nghĩ vấn đề có thể nằm ở mã của anh ta, nhưng nếu bạn có thể khắc phục vấn đề với RAM trị giá vài trăm đô la, thì đó là cách sử dụng tiền hiệu quả.
Satanicpuppy

1
@robert: Tôi đồng ý. Nhưng tôi thường thấy mọi người chi hàng ngàn tiền cho các lập trình viên và chuyên gia tư vấn để khắc phục sự cố phần mềm, khi ném thêm một chút phần cứng vào nó sẽ làm điều tương tự với một phần chi phí.
Satanicpuppy

1
6 Gigs là một cấu hình bộ nhớ SQL Server kích thước tốt? Bạn đã sử dụng một số máy chủ nhỏ. Tôi đã có các hộp với 256 Gigs được cài đặt và tôi đã có bạn bè với 512 Gigs được cài đặt. 6 hợp đồng biểu diễn là không có gì.
mrdenny

1
@mdmarra: Ơ. Năm 2012, chắc chắn. Vào năm 2009? Không nhiều lắm.
Satanicpuppy

4

Trước khi bạn nổ súng mua thêm bộ nhớ (hoặc bất kỳ thành phần nào khác), tôi khuyên bạn nên chạy phân tích hiệu suất trên máy chủ. Bạn có thể tự làm điều này bằng perfmon hoặc bạn có thể xem xét bằng cách sử dụng các công cụ của bên thứ ba. Bạn nên phân tích hiệu suất của cả máy chủ OS và SQL. IMHO, quá thường xuyên, chúng tôi sẵn sàng ném phần cứng vào một vấn đề trước khi phân tích thích hợp được thực hiện. Đối với tất cả những gì bạn biết tại thời điểm này, nó có thể là một vấn đề với truy vấn, thủ tục được lưu trữ, kế hoạch thực hiện, I / O đĩa, sử dụng CPU, v.v., ... Áp lực bộ nhớ thường có thể là một triệu chứng của một nút cổ chai khác trong hệ thống.


1

như "Satanicpuppy" đã nói, không có gì là quá nhiều RAM, nhưng 6GB sẽ ổn, có lẽ bạn nên suy nghĩ lại về những gì máy chủ của bạn làm, tôi không nghĩ rằng bạn có vấn đề về "phần cứng", bạn nên tập trung vào lập trình SQL của bạn ...


1

Khi nói đến máy chủ cơ sở dữ liệu, không có bộ nhớ "đủ". Chắc chắn, nó phụ thuộc vào những gì họ thực sự làm và chạy nhưng nếu đó là cơ sở dữ liệu được sử dụng liên tục chứa nhiều dữ liệu và thực hiện các truy vấn phức tạp - 6 GB có thể dễ dàng bị thiếu.

Tôi sẽ bắt đầu bằng cách nâng cấp một máy chủ rắc rối lên ít nhất 32 hoặc 64 GB và xem nó có giúp ích không. Nếu không, hãy chuyển sang điều chỉnh cơ sở dữ liệu, khắc phục sự cố và gỡ lỗi ứng dụng - tất cả, trừ khi một kẻ ngốc thiết kế cơ sở dữ liệu, tốn hơn rất nhiều so với một vài bộ nhớ cấp máy chủ (và ngay cả khi một kẻ ngốc thiết kế mọi thứ, thậm chí còn có thiết kế rõ ràng lỗi được sửa với hỗ trợ giữ lại có thể chứng minh một thách thức khá lớn).

Điều đó nói rằng, như một người khác đã nói - nó có thể là một thứ gì đó cản trở nó (ngoài các vấn đề về thiết kế phần mềm), như thiếu hiệu năng I / O của đĩa hoặc mạng - thuê một chuyên gia DBA chỉ để theo dõi hiệu suất SQL cơ bản cho ngày có thể chứng minh hữu ích.


0

Bạn nên nhìn vào việc xây dựng nhiều chỉ mục hơn. Tôi nghĩ rằng nói chung, hầu hết mọi người đánh giá thấp cơ sở dữ liệu của họ.

Đây vẫn là mã không khí, tôi chưa thử nghiệm đầy đủ, nhưng nó sẽ giúp bạn đi đúng hướng

http://accessadp.com/2011/08/22/missing-indexes-great-script-for-determining-roi/

Select ‘create index IX_’ +
 sys.objects.name +
 isnull(replace(‘_’ + equality_columns, ‘,’, ‘_’), ”) +
 isnull(replace(‘_’ + inequality_columns, ‘,’, ‘_’), ”) + ‘ on ‘ +
 sys.objects.name +
 ‘(‘ +
 coalesce(equality_columns + ‘,’ + inequality_columns, equality_columns , inequality_columns ) +
 ‘) ‘ +
 isnull(‘ include (‘ + included_columns + ‘)’, ”)
 as CreateIndexSql,
 (CONVERT(Numeric(19,6), sys.dm_db_missing_index_group_stats.user_seeks)+CONVERT(Numeric(19,6), sys.dm_db_missing_index_group_stats.unique_compiles))*CONVERT(Numeric(19,6), sys.dm_db_missing_index_group_stats.avg_total_user_cost)*CONVERT(Numeric(19,6), sys.dm_db_missing_index_group_stats.avg_user_impact/100.0) AS Score,
 sys.schemas.schema_id,
 sys.schemas.name AS schema_name,
 sys.objects.object_id,
 sys.objects.name AS object_name,
 sys.objects.type,
 partitions.Rows, partitions.SizeMB,
 sys.dm_db_missing_index_details.equality_columns,
 sys.dm_db_missing_index_details.inequality_columns,
 sys.dm_db_missing_index_details.included_columns,
 sys.dm_db_missing_index_group_stats.unique_compiles,
 sys.dm_db_missing_index_group_stats.user_seeks, sys.dm_db_missing_index_group_stats.user_scans,
 sys.dm_db_missing_index_group_stats.avg_total_user_cost, sys.dm_db_missing_index_group_stats.avg_user_impact,
 sys.dm_db_missing_index_group_stats.last_user_seek, sys.dm_db_missing_index_group_stats.last_user_scan,
 sys.dm_db_missing_index_group_stats.system_seeks, sys.dm_db_missing_index_group_stats.system_scans,
 sys.dm_db_missing_index_group_stats.avg_total_system_cost, sys.dm_db_missing_index_group_stats.avg_system_impact,
 sys.dm_db_missing_index_group_stats.last_system_seek, sys.dm_db_missing_index_group_stats.last_system_scan
 FROM
 sys.objects
 JOIN (
 SELECT
 object_id, SUM(CASE WHEN index_id BETWEEN 0 AND 1 THEN row_count ELSE 0 END) AS Rows,
 CONVERT(numeric(19,3), CONVERT(numeric(19,3), SUM(in_row_reserved_page_count+lob_reserved_page_count+row_overflow_reserved_page_count))/CONVERT(numeric(19,3), 128)) AS SizeMB
 FROM sys.dm_db_partition_stats
 WHERE sys.dm_db_partition_stats.index_id BETWEEN 0 AND 1 –0=Heap; 1=Clustered; only 1 per table
 GROUP BY object_id
 ) AS partitions ON sys.objects.object_id=partitions.object_id
 JOIN sys.schemas ON sys.objects.schema_id=sys.schemas.schema_id
 JOIN sys.dm_db_missing_index_details ON sys.objects.object_id=sys.dm_db_missing_index_details.object_id
 JOIN sys.dm_db_missing_index_groups ON sys.dm_db_missing_index_details.index_handle=sys.dm_db_missing_index_groups.index_handle
 JOIN sys.dm_db_missing_index_group_stats ON sys.dm_db_missing_index_groups.index_group_handle=sys.dm_db_missing_index_group_stats.group_handle
 WHERE
 sys.dm_db_missing_index_details.database_id=DB_ID()
 AND (CONVERT(Numeric(19,6), sys.dm_db_missing_index_group_stats.user_seeks)+CONVERT(Numeric(19,6), sys.dm_db_missing_index_group_stats.unique_compiles))*CONVERT(Numeric(19,6), sys.dm_db_missing_index_group_stats.avg_total_user_cost)*CONVERT(Numeric(19,6), sys.dm_db_missing_index_group_stats.avg_user_impact/100.0) > 100
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.