Скільки оперативної пам’яті насправді потрібно серверу?


12

У мене досить багато серверів, розгорнутих по всьому світу. У них працює Windows 2003 x64 з SQL Server 2005 x64 з 6 ГБ оперативної пам’яті. Коробки мають не найкращу (або навіть прийнятну) конфігурацію, тому що хлопець, який замовив їх років тому, насправді не знав, що він робить.

У полях досить послідовно втрачається пам'ять, в кінцевому підсумку використовується файл підкачки і все сповільнюється. Зазвичай плата за комісію становить 5,8 Гб, і тоді, коли комусь потрібно зробити щось інтенсивне (наприклад, запустити звіт), це число переходить через дах.

Я намагався отримати повноваження, які б на замовлення більше пам’яті, але я отримую величезне протистояння (наприклад, зробити програмне забезпечення більш ефективним, занадто дорого коштує для всіх цих серверів або довести, що в коробці недостатньо пам’яті тощо). ..).

Чи є вказівки (або формула) про те, скільки потрібно оперативної пам’яті, яку я можу подати нетехнологіям, щоб ми могли нарешті замовити більше пам’яті?


Чи розроблена система власноруч?
Оскар Дювеборн

@Oskar. Так, я розробник, і код оптимізований до пекла і назад. Існує просто багато даних.
AngryHacker

Тоді дивіться мою відповідь. Це те, на що я спеціалізуюся.
mrdenny

Відповіді:


9

Насправді це не так легко зрозуміти, оскільки це повністю залежить від вашого використання та програми. Ви максимізуєте сервер баз даних ... наскільки велика база даних? Які статистичні дані вашої транзакції?

Обмеження у реальному світі очевидні у вашому сценарії. Ви без проблем бігаєте на 6 концертів, тоді це відбувається обмін і молотіння. Таких 6 концертів недостатньо.

Якщо продуктивності достатньо, щоб це вплинуло на бізнес, то ваші вищі зразки повинні почути достатньо скарг, що це доцільно збільшити пам'ять. З'ясуйте, що коштує ваш час, а потім з’ясуйте, скільки коштуватиме "налаштування" сервера та усунення неполадок, коли пам'ять, додана на сервер, може цілком вирішити проблему щодо вартості пам'яті та менше ніж півгодини простої.

Ви не знатимете точний об'єм пам'яті, який вам потрібен, поки ви фактично не розгорнетесь у реальному використанні та не працюєте звідти.

З цього приводу ви можете переконатися, що ваша програма справді вузьким місцем. Запустіть монітор продуктивності Windows, щоб побачити статистику вводу / виводу вашого диска та пропускну здатність мережі. Подивіться, який у вас рівень фрагментації (тут Google є добрим другом ). Ви можете спробувати перевірити код і для очевидних проблем, коли запит стає неефективним ( знову ж таки Google ).

Але знову ж таки все залежить від того, наскільки це сильно впливає на бізнес. Чи варто більше вкладати кошти в налаштування, чи досить погано спочатку кинути на нього обладнання, а потім спробувати його налаштувати?


Розмір +1 і потрібна статистика
Оскар Дювеборн

12

Простий спосіб дізнатися, чи потрібно більше оперативної пам’яті, це скласти графік лічильника кількості сторінок на очікування. Цей лічильник повідомляє вам, як довго SQL Server думає, що дані будуть зберігатися в буферному пулі, перш ніж потрібно звільнити місце для інших даних. Ви хочете, щоб ця кількість була максимально високою. Якщо встановлено 6 гігів оперативної пам’яті (у вас повинен бути встановлений SQL на максимум, мабуть, 4 гіги), ви, ймовірно, будете зберігати дані в пам’яті не більше декількох хвилин, коли хтось запускає великий звіт, ви побачите цей номер резервуара до декількох секунд. Чим більше у вас оперативної пам’яті, тим довше дані можуть зберігатися в пам’яті, і менше читання з дисків потрібно буде зробити.

Наприклад, системи, з якими я працюю на даний момент, мають 256 гігів оперативної пам’яті, і ми зберігаємо дані в пам’яті близько 12000 секунд або близько того.

Будь ласка, не вимагайте, щоб цільове число потрапило, ви просто хочете, щоб це було якомога вище. Не знаючи багато більше про ваші системи, я не можу дати хороший номер для зйомки.


6

Гмммм. Ну, 6 гігів - це пристойна кількість оперативної пам'яті, навіть для великої установки MSSQL. Можливо, ви хочете подивитися і переконатися, що ваш код справді ефективний. Операція на 6 концертів трохи незвична ... Я працював над загальнодержавними системами оплати праці, які не перевищували концерт на обробці в кінці року 1099 року ... І щоб часто проводити одну ? Не знаю. З якими даними ви працюєте?

Як сказано, ви можете набрати стільки оперативної пам’яті, скільки вам подобається, в 64-бітну коробку, а оперативної пам’яті дешевий бруд, так що, можливо, також помістіть стільки, скільки, можливо, ви не можете мати занадто багато оперативної пам’яті. сервер бази даних.

Редагувати: Зараз це застаріло. У мене є коробки MSSQL з 256 гігами оперативної пам’яті.


1
На сервері бази даних не може бути занадто багато оперативної пам’яті. Можливо, ні, але ви можете мати оперативну пам’ять, на яку витратили гроші, тому що її не використовують. Хоча я погоджуюсь із загальною думкою про те, що платити потрібно великодушно на скриньках, які виконують певні види завдань, я не думаю, що це стосується просто закидання ресурсів у систему, не розуміючи її вимог.
Роб Моар

2
@robert: Це не так, як я виступаю за придбання блейд-сервера. Досягнення оперативної пам’яті на сервері досить легко, і якщо у вас не вистачає пам’яті, то чому б не додати більше? Я думаю, що проблема, ймовірно, полягає в його коді, але якщо ви зможете виправити проблему за допомогою оперативної пам’яті, яка коштує пару сотень доларів, це ефективно використання грошей.
Satanicpuppy

1
@robert: Я згоден. Але я занадто часто бачив, як люди витрачають тисячі на кодери та консультантів, щоб вирішити проблему з програмним забезпеченням, коли кидати трохи більше апаратного забезпечення на це зробить те саме, що за частку витрат.
Satanicpuppy

1
6 Gigs - це конфігурація пам'яті SQL Server хорошого розміру? Ви використовуєте досить маленькі сервери. У мене встановлені коробки з 256 гігами, і я подружився з 512 гігами. 6 Gigs - це ніщо.
mrdenny

1
@mdmarra: Е-е. У 2012 році точно. У 2009 році? Не так багато.
Satanicpuppy

4

Перш ніж стрибати пістолет про придбання більшої кількості пам'яті (або будь-якого іншого компонента), я б рекомендував запустити аналіз продуктивності на сервері. Ви можете зробити це самостійно, використовуючи perfmon, або можете подивитися за допомогою сторонніх інструментів. Ви повинні проаналізувати продуктивність як ОС, так і SQL-сервера. ІМХО, занадто часто ми готові кинути апаратне забезпечення на проблему до того, як буде зроблено належний аналіз. З усього, що ви знаєте, на даний момент це може бути проблема із запитом, збереженою процедурою, планом виконання, введенням / виведенням диска, використанням процесора тощо, тощо. Тиск пам'яті часто може бути симптомом ще одного вузького місця в системі.


1

як сказав "Satanicpuppy", немає такого поняття, як занадто багато оперативної пам’яті, але 6 Гб має бути нормальним, можливо, вам слід заново подумати над тим, що робить ваш сервер, я не думаю, що у вас є "апаратні" проблеми. зосередитись на вашому програмуванні SQL ...


1

Що стосується серверів баз даних, то тут немає такого поняття, як "достатньо" пам'яті. Звичайно, це залежить від того, що вони насправді роблять і працюють, але якщо це база даних, що постійно використовується, що містить багато даних і виконує складні запити - 6 ГБ легко може бути абсолютно недостатнім.

Я б почав з оновлення одного клопіткого сервера принаймні до 32 або 64 ГБ і побачити, чи це допомагає. Якщо ні, зверніться до налаштування бази даних, усунення несправностей у програмі та налагодження - що все, якщо ідіот не спроектував базу даних, коштувало набагато дорожче, ніж кілька паличок серверної пам’яті (і навіть якщо ідіот спроектував цю річ, отримавши навіть очевидний дизайн помилки, виправлені із збереженою підтримкою, можуть виявитись досить складним завданням).

Це зазначає, як хтось інший заявив - це може бути щось інше, що стримує його (окрім проблем із дизайном програмного забезпечення), як, наприклад, відсутність продуктивності вводу / виводу диска або мережі - наймаючи 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
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.