Точно тенденція довільних показників вводу / виводу для планування потужностей

Там, де я працюю, ми маємо численні «великі залізні» сервери, які використовуються для розміщення багатьох віртуальних машин за допомогою Xen Hypervisor. Зазвичай вони налаштовані на 32 ГБ оперативної пам’яті, двоядерних процесорах і швидких дисках із заготовками ємності вводу / виводу.

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

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

Однак, досліджуючи новіше обладнання, очевидно, що ви можете отримати більше і більше оперативної пам’яті в межах однієї машини з 64, 72 або навіть 96 Гб в одному шасі. Очевидно, це дозволить нам отримати більше машин для даного господаря, який завжди є виграшним. Наразі завершений аналіз говорить про те, що обмежуючий фактор тепер буде зміщений на дискову підсистему.

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

Тепер це суть питання, яке я задаю, чи хтось знає про спосіб точно відстежувати / відстежувати наявну продуктивність вводу / виводу конкретно стосовно кількості виконаних випадкових операцій вводу / виводу?

Те, що я насправді намагаюся отримати метрику, - це "ця конфігурація може успішно обробляти X кількість випадкових запитів вводу / виводу, і ми в даний час (в середньому) робимо Y ops з піком Z ops".

Спасибі заздалегідь!

sarдобре справляється тут робота; він збирає кількість транзакцій, а також сектори, прочитані / записані в секунду, які можна використовувати для повторного відтворення робочого навантаження вводу-виводу з відносно пристойною точністю (з точки зору коефіцієнта читання / запису, а також розміру транзакції, який є визначальний фактор, наскільки "випадковим" є ваш IO). Це не ідеально, але, на мій досвід, він робить достатньо хорошу роботу, щоб зробити таку оцінку, яку ви дивитесь.

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

Що стосується інструментів, у вас є ганглії, zenoss, nagios тощо у світі відкритих джерел та численні інші товари постачальників.

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

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

Після того, як ви збираєте дані, ви можете зберігати все це в хорошому великому БД для звітування, можливо, підтверджуючи історичні дані, наприклад. зберігайте кожні 5 секунд метрику протягом 6 місяців, потім хвилини, потім 5, потім за годину, як ви йдете далі. Такі речі можна сценаріювати та пропускати через cron, autysys тощо.

Ці звіти дадуть вам те, чого хоче управління - тобто. щось із гарними графіками.

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

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

Це чудовий інструмент для огляду загальної продуктивності системи. Удачі, за спостереженнями диски SATA зазвичай виходять між 200-300 IOPS при довільному доступі.

Ми записуємо та графікуємо введення / виведення дискових дисків так само, як і всі інші показники:

• Дані витягуються з хостів за допомогою SNMP. Наші коробки NAS / SAN роблять це вдома. Ми використовуємо net-snmp на всіх хостах Linux, що надає цю інформацію від USB-DISKIO-MIB .

• Дані зберігаються (у форматі RRD) та схоплюються за допомогою кактусів . Деякі шаблони дискового вводу-виводу дають нам кількість та розмір транзакцій у звичайному поточному, середньому та піковому форматі.

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

Ми використовуємо ці дані, щоб сповіщати про незвичні тенденції на операційній основі та завжди озиратися на них, коли виконуємо планування потужностей.

Те, що я дійсно намагаюся отримати метрику, - це "ця конфігурація може успішно обробляти X кількість випадкових запитів вводу / виводу [..]".

З цим є кілька проблем:

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

• Запис показників дасть вам дуже гарне уявлення про те, якими є сьогодні ваші зобов’язання, як вони змінюються з часом та, як вони змінюватимуться в майбутньому. Те, що вам не скаже, це те, що таке стеля. Принаймні, не до того, як пізно. Для того, щоб визначити це, вам потрібно зробити математику (з ваших технічних специфікацій), бенчмаркінг (я захоплююсь bonnie++собою), і корисно мати певне логістичне уявлення про те, для чого ці домівки роблять / для чого використовують.

Залежно від вашого резервного місця зберігання (IBM SVC / DS8000), можливо, ви зможете безпосередньо отримувати статистику щодо випадкових IOPS.

Для витягу статистики з сервера ви можете використовувати nmon . Це безкоштовно (як у пиві). Спочатку розроблений IBM для AIX, також працює на Linux.

Якщо люди використовують SAR, я, принаймні, сподіваюся, що ви збираєте свої дані за кілька секунд. Під час використання collel я пробиваю один раз / секунду. Щодо вимірювання того, наскільки добре ви робите у випадковому вході / виводу, використовуйте такий інструмент, як dt Robin Miller (google it), і ви можете легко створити багато випадкових вводу / виводу, а потім просто виміряти за допомогою collel, щоб побачити, скільки ви може робити за секунду. Типовий диск, як правило, максимум 200-300 в / в / сек, в значній мірі заснований на затримці обертання. Розмір блоку мав мінімальний ефект, оскільки очікування 1/2 обертання диска в потрібному місці перекриває все інше.

btw - iowait - одне з найбільш неправильно зрозумілих вимірювань. Він не має нічого спільного з завантаженням процесора, це просто означає, що процесор не робив нічого іншого під час вводу / виводу. Насправді, якщо ви на 100% безперервно, це означає, що ви майже 100% простоюєте!

-знак