서버에 실제로 얼마나 많은 RAM이 필요합니까?


12

전 세계에 꽤 많은 서버가 배포되어 있습니다. 6GB RAM이있는 SQL Server 2005 x64가 설치된 Windows 2003 x64를 실행하고 있습니다. 몇 년 전에 주문한 사람이 실제로 무엇을하는지 알지 못했기 때문에 상자에는 최상의 구성 (또는 수용 가능한 구성)이 없습니다.

상자의 메모리가 거의 일정하게 유지되지 않고 페이징 파일을 사용하면 모든 것이 느려집니다. 일반적으로 커밋 요금은 5.8GB이며 누군가가 집중적 인 작업을 수행해야하는 경우 (예 : 보고서 실행) 해당 숫자는 지붕을 통과합니다.

나는 더 많은 메모리를 주문할 수있는 힘을 얻으려고 노력했지만 엄청난 반대를 얻고 있습니다 (예 : 소프트웨어의 성능을 높이거나 모든 서버에 대해 너무 많은 비용을 내거나 상자에 충분한 메모리가 없음을 증명합니다). ..).

기술자가 아닌 사람에게 제공 할 수있는 RAM 용량에 대한 지침 (또는 공식)이있어 더 많은 메모리를 주문할 수 있습니까?


시스템이 사내에서 개발 되었습니까?
Oskar Duveborn

@ 오스카. 예, 저는 개발자이며 코드는 지옥에 맞게 최적화되었습니다. 많은 양의 데이터가 있습니다.
AngryHacker

그런 다음 내 대답을 참조하십시오. 이것은 내가 전문화하는 종류입니다.
mrdenny

답변:


9

사용법과 응용 프로그램에 전적으로 의존하기 때문에 쉽게 알 수있는 방법은 아닙니다. 데이터베이스 서버를 최대로 사용하고 있습니다 ... 데이터베이스가 얼마나 큽니까? 거래 통계는 무엇입니까?

실제 제한 사항은 시나리오에서 분명합니다. 6 기가에서 문제없이 잠시 달리고 있다면 스왑과 스 래싱이 발생하기 때문에 6 기가 충분하지 않습니다.

성능이 비즈니스에 영향을 미칠 정도로 충분하면, 상위업자는 메모리를 늘리는 데 충분한 불만을 듣고 있어야합니다. 서버에 추가 된 메모리가 메모리 비용과 30 분 미만의 시간을 매우 잘 해결할 수있는 경우 시간 비용을 파악한 다음 서버를 "조정"하고 조정 문제를 해결하는 데 드는 비용을 계산하십시오. 중단 시간.

실제 사용량에 실제로 배포하여 작업 할 때까지 필요한 정확한 메모리 양을 알 수 없습니다.

즉, 응용 프로그램이 실제로 병목 현상인지 확인하고 싶을 수 있습니다. 디스크 성능 통계 및 네트워크 처리량을 보려면 Windows 성능 모니터를 실행하십시오. 조각화 수준도 확인하십시오 ( Google은 여기서 좋은 친구입니다 ). 쿼리가 매우 비효율적 인 곳에서도 명백한 문제에 대해 코드 감사를 시도 할 수 있습니다 ( Google 다시 ).

그러나이 모든 것이 비즈니스에 얼마나 나쁜 영향을 미치는지에 달려 있습니다. 튜닝에 투자하는 것이 더 가치가 있습니까, 아니면 먼저 하드웨어를 던져서 튜닝을 시도하기에 충분하지 않습니까?


+1 크기와 통계가 필요
Oskar Duveborn

12

더 많은 RAM이 필요한지 확인하는 쉬운 방법은 Page Life Expectancy perfmon 카운터를 도표화하는 것입니다. 이 카운터는 SQL Server가 다른 데이터를위한 공간을 확보하기 전에 버퍼 풀에 데이터가 유지 될 것이라고 생각하는 시간을 알려줍니다. 이 숫자를 가능한 한 많이 원합니다. 6 기가 바이트의 RAM이 설치되어 있으면 (아마도 4 기가에서 최대로 SQL을 설정해야 함) 아마도 몇 분 동안 만 데이터를 메모리에 보관할 것입니다. 누군가가 큰 보고서를 실행할 때이 숫자 탱크가 표시됩니다 몇 초까지 RAM이 많을수록 더 많은 데이터를 메모리에 보관할 수 있으며 디스크에서 읽는 횟수가 줄어 듭니다.

예를 들어, 현재 작업중 인 시스템에는 256Gig의 RAM이 있으며 약 12000 초 동안 데이터를 메모리에 보관합니다.

목표 번호를 요구하지 말고 가능한 한 높은 숫자를 원하십시오. 당신의 시스템에 대해 더 많이 알지 못하면 나는 쏠 수있는 좋은 숫자를 줄 수 없습니다.


6

흠. 글쎄, 6 gigs는 대규모 MSSQL 설치의 경우에도 상당한 양의 램입니다. 실제로 코드를 효율적으로보고 확인하고 싶을 수도 있습니다. 6 공연 거래는 조금 드문 일입니다 ... 1099 년 연말 처리에서 공연을하지 않은 주 전역의 급여 시스템에서 일했습니다 ... 그리고 자주 운영 하는 것이 있습니까? 모르겠어요 어떤 종류의 데이터로 작업하고 있습니까?

즉, 64 비트 상자에 원하는만큼 많은 RAM을 넣을 수 있으며 램은 먼지가 저렴하므로 가능한 한 많이 넣을 수 있습니다 ... RAM을 너무 많이 가질 수는 없습니다. 데이터베이스 서버.

편집 : 이것은 현재 오래되었습니다. 256GB의 RAM이있는 MSSQL 상자가 있습니다.


1
데이터베이스 서버에 RAM이 너무 많을 수 없습니다. 아마도 그렇지는 않지만, 사용되지 않기 때문에 돈을 낭비한 RAM을 가질 수 있습니다. 특정 종류의 작업을 수행하는 상자에 관대하다는 일반적인 아이디어에 동의하지만 요구 사항을 이해하지 않고 시스템에 리소스를 던지는 것으로 확장되지는 않습니다.
Rob Moir

2
@ robert : 블레이드 서버 구매를 옹호하는 것과는 다릅니다. 서버에서 RAM을 최대화하는 것은 매우 쉽습니다. 메모리가 부족하면 더 추가하지 않겠습니까? 코드에 문제가 있다고 생각하지만 수백 달러에 달하는 RAM으로 문제를 해결할 수 있다면 돈을 효율적으로 사용하는 것입니다.
Satanicpuppy

1
@robert : 동의합니다. 그러나 사람들이 소프트웨어 문제를 해결하기 위해 코더와 컨설턴트에게 수천 달러를 소비하는 것을 너무 자주 보았습니다.
Satanicpuppy

1
6 Gigs는 적당한 크기의 SQL Server 메모리 구성입니까? 아주 작은 서버를 사용하고 있습니다. 256 Gigs가 설치된 상자가 있고 512 Gigs가 설치된 친구가 있습니다. 6 Gigs는 아무것도 아닙니다.
mrdenny

1
@mdmarra : Eh. 2012 년에는 물론입니다. 2009 년에? 별로.
Satanicpuppy 2016 년

4

더 많은 메모리 (또는 다른 구성 요소)를 구입하기 위해 총을 치기 전에 서버에서 성능 분석을 실행하는 것이 좋습니다. perfmon을 사용하여 직접 수행하거나 타사 도구를 사용하여 볼 수 있습니다. OS와 SQL Server의 성능을 모두 분석해야합니다. IMHO는 적절한 분석을 수행하기 전에 문제가 발생했을 때 하드웨어를 던질 준비가되어있는 경우가 많습니다. 이 시점에서 아는 것은 쿼리, 저장 프로 시저, 실행 계획, 디스크 I / O, CPU 사용률 등과 같은 문제 일 수 있습니다. 메모리 압력은 종종 시스템의 또 다른 병목 현상의 증상 일 수 있습니다.


1

"Satanicpuppy"가 말했듯이 RAM이 너무 많지는 않지만 6GB는 괜찮을 것입니다. 아마도 서버의 기능을 다시 생각해야합니다. "하드웨어"문제가 있다고 생각하지 않습니다. SQL 프로그래밍에 집중하십시오 ...


1

데이터베이스 서버에 관해서는 "충분한"메모리와 같은 것은 없습니다. 물론 실제로 수행하고 실행하는 작업에 따라 달라 지지만 많은 데이터를 포함하고 복잡한 쿼리를 수행하는 지속적으로 사용되는 데이터베이스 인 경우 6GB가 쉽게 부적절 할 수 있습니다.

번거로운 서버 하나를 32GB 또는 64GB 이상으로 업그레이드하고 도움이되는지 확인하십시오. 그렇지 않다면 데이터베이스 튜닝, 응용 프로그램 문제 해결 및 디버깅으로 전환하십시오. 바보가 데이터베이스를 설계하지 않는 한 서버급 메모리의 스틱보다 훨씬 많은 비용이 든다. 유지 된 지원으로 수정 된 오류는 상당히 어려운 문제 일 수 있습니다.

다른 누군가가 말했듯이 디스크 또는 네트워크 I / O 성능 부족과 같은 소프트웨어 설계 문제를 제외하고는 그것을 방해 할 수 있습니다 .DBA 전문가를 고용하여 기본 SQL 성능 모니터링을 수행합니다. 하루가 유용 할 수 있습니다.


0

더 많은 색인을 작성해야합니다. 나는 일반적으로 대부분의 사람들이 자신의 데이터베이스를 색인화하지 못한다고 생각합니다.

이것은 여전히 ​​에어 코드이며 아직 완전히 테스트하지는 않았지만 올바른 방향으로 안내해야합니다.

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
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.