Як ви оцінюєте, скільки пам’яті придбати?

У мене є власна серверна програма, яка працює на Windows 2008 R2. Це домашня послуга Windows, написана в .Net, що підтримує ряд користувальницьких терміналів. У мене є тестова машина, яка має схожі специфікації на сервер в реальному часі, і у мене є набір клієнтських тренажерів, які я можу використовувати для створення навантаження, що є розумним наближенням до реальної системи. Мені потрібно вміти підтримувати 12000 з них, і в даний час у сервера не вистачає пам'яті (Пейджинг проходить дах).

Мій план полягав у тому, щоб запустити лише 100 тренажерів, виміряти використання пам'яті, потім знову запустити ще 100 вимірювань пам’яті та повторити, доки підказка не почне зростати (насправді я візьму більше трьох точок даних.) Це повинно дати мені цифру для обсяг додаткової пам'яті, необхідний для 100 тренажерів, і дозволить мені спроектувати, скільки пам'яті потрібно. Мені потрібна лише орієнтовна ідея +/- 30Gb, щоб уникнути купівлі повних 2Tb ($ 150 000 вартістю), які забирає сервер. Моє запитання - чи це розумний метод використання, і якщо так, то які лічильники продуктивності ви б відстежували, щоб дати обсяг пам'яті, який фактично використовується?

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

Чесно? Я НЕ ДАЮ .
Коли я шукаю сервер, який побачить будь-яку реальну завантаженість, я набиваю стільки оперативної пам’яті, скільки я можу собі дозволити (системи, швидше за все, обмежують оперативну пам’ять, ніж обмежені процесором або диском - єдиним іншим гарантованим вузьким місцем є передня сторона автобус).

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

Якщо ви виконуєте тест навантаження, щоб отримати приблизні цифри та екстраполювати звідти, не забудьте скористатися кількома речами:

1. Крива пам'яті, ймовірно, буде двома окремими сегментами
   (початковий різкий наріст, коли кешуються рамки / спільні бібліотеки, потім трохи меншою крутою кривою, оскільки незмінний код кожного нового додатка поміщається в пам'ять)

2. Вам все ще потрібна безкоштовна оперативна пам’ять для кешування диска та спільної бібліотеки та для ОС.
   (Це має бути принаймні кілька концертів над тим, що потрібно вашому додатку)

3. ВСЕ програмне забезпечення протікає в пам’яті (принаймні, все це практичне програмне забезпечення), тому слідкуйте за цим під час тестування і будьте впевнені, що у вас є місце для усунення витоку.

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

5. Купувати занадто багато оперативної пам’яті сьогодні дешевше, ніж завтра ваше довкілля.

   • Перший слід: Якщо ви купуєте трохи більший сервер, ніж вам потрібно, ви стародавній адміністратор, який підтримував роботу компанії. Вас значною мірою проігнорують і не оцінять.
   • Другий наслідок: Якщо у вас недостатньо розмір машини і виникають проблеми, ви некомпетентний скафандр, який не міг передбачити 500% зростання, і всі вас ненавидять.

Дякую, оновлення принаймні дає всім підказку. Те, що ви розмірковуєте 2 Тб пам'яті, означає, що ви граєте в іншому бальному парку до звичайних налаштувань. Велика система. ненавиджу думати про те, скільки тепла буде здавати.

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

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

Швидкий зворотний розрахунок конверта:

2Tb of memory = 1024Gb = 1024*1024Mb = 1048576Mb
1048576Mb / 13000 connections = around 80mb per session

Це не було б поза діапазоном нормального робочого набору .net exe.

Чи має служба декілька потоків? Якщо вони запускають потік для кожного з'єднання, варто було б подивитися, як вони це роблять. ProcExp.exe від microsoft - це простий спосіб дізнатися, чи є у вас кілька потоків і що споживають ці нитки. Він не знає про .net, але дасть вам win32 лічильники.

Чи можете ви вказати, скільки пам’яті та скільки підключень у вас було під час тестування, перш ніж воно почалося на сторінці?

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

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

Ідея полягає в тому, щоб перевірити, чи сервіс споживає все більше і більше пам’яті з кожним сеансом чи відкриті сеанси провокують все більше використання пам'яті.