Там, где я работаю, у нас есть множество «больших железных» серверов, которые используются для размещения множества виртуальных машин с использованием гипервизора Xen. Обычно они сконфигурированы с 32 ГБ ОЗУ, процессами Dual Quad core и быстрыми дисками с большой емкостью ввода-вывода.
Мы находимся в тот момент, когда существующая конфигурация оборудования становится немного длиннее, и пора выйти и закупить новое, более крупное, быстрое и блестящее новое оборудование.
Как упоминалось выше, существующий комплект был развернут с 32 ГБ ОЗУ, и это эффективно ограничило количество виртуальных машин, которые мы можем развернуть на хосте.
Однако при исследовании нового оборудования становится очевидным, что вы можете получить все больше и больше оперативной памяти на одной машине с 64, 72 или даже 96 ГБ в одном шасси. Очевидно, это позволит нам подключить больше машин к данному хосту, что всегда является выигрышем. Завершенный анализ показывает, что теперь ограничивающий фактор будет перенесен на дисковую подсистему.
Теперь проблема в том, чтобы понять, где мы находимся ... Благодаря использованию мы знаем, что мы не ограничены с точки зрения пропускной способности ввода-вывода, более того, количества случайных I / O операции, которые могут быть завершены .. Мы знаем по анекдотам, что как только мы достигнем этой точки, iowait взлетит до небес, и все характеристики машины перейдут к собакам.
Теперь это суть вопроса, который я задаю: знает ли кто-нибудь способ точного отслеживания / анализа тенденций существующей производительности ввода-вывода, особенно в отношении количества выполняемых случайных операций ввода-вывода?
Что я действительно пытаюсь получить метрику, так это «эта конфигурация может успешно обрабатывать X случайных запросов ввода-вывода, и в настоящее время мы (в среднем) выполняем операции Y с пиком Z операций».
Заранее спасибо!
sar здесь хорошо работает; он будет собирать количество транзакций, а также количество секторов, прочитанных / записываемых в секунду, которые можно использовать для последующего воспроизведения вашей рабочей нагрузки ввода-вывода с относительно приличной точностью (с точки зрения соотношений чтения / записи, а также размера транзакции, который является определяющий фактор того, насколько «случайным» является ваш ввод-вывод). Он не идеален, но, по моему опыту, он выполняет достаточно хорошую работу, чтобы делать такую оценку, на которую вы смотрите.
Мы записываем и наносим на график дисковый ввод-вывод так же, как и все другие показатели:
Данные извлекаются с хостов с помощью SNMP. Наши боксы NAS / SAN делают это изначально. Мы используем net-snmp на всех хостах Linux, который предоставляет эту информацию из USB-ДИСКИО-MIB.
Данные сохраняются (в формате RRD) и отображаются в виде графика с использованием Кактусы. Некоторые Дисковые шаблоны ввода-вывода предоставьте нам количество и размер транзакций, отображаемые в обычном текущем, среднем и пиковом формате.
Эти метрики не обязательно такие конечные, как использование iostat/dstat/sar на хосте. Но это «выстрелил и забыл», который настраивается автоматически при вводе новой машины в эксплуатацию, хранится централизованно и остается доступным для использования в будущем.
Мы используем эти данные для оперативного оповещения нас о необычных тенденциях и всегда обращаемся к ним при планировании мощностей.
Что я действительно пытаюсь получить метрику, так это «эта конфигурация может успешно обрабатывать X случайных запросов ввода-вывода [..]».
С этим есть пара проблем:
Довольно сложно отделить и количественно оценить случайный ввод-вывод от последовательного ввода-вывода. Поскольку принципиальное различие между ними заключается в физическом расположении блоков, хранящихся на пластине диска. Вы можете сделать обоснованное предположение по размеру транзакций, исходя из того, что множество мелких транзакций наверное относятся к небольшим файлам, разбросанным по диску. Но гарантии нет. Это мощь читать небольшие объемы данных последовательно из одного файла или соседних блоков на диске.
Запись показателей даст вам очень хорошее представление о ваших сегодняшних обязательствах, о том, как они меняются с течением времени и, следовательно, как они будут меняться в будущем. Чего он вам не скажет, так это того, что такое потолок. По крайней мере, пока не стало слишком поздно. Чтобы определить это, вам нужно выполнить некоторую математику (исходя из характеристик вашего оборудования), провести сравнительный анализ (мне нравится bonnie++ я), и полезно иметь некоторое логистическое представление о том, что эти domU делают / для чего используются.
Мы используем собирать поскольку мы можем собрать всю необходимую информацию в один файл и воспроизвести статистику при необходимости. Это позволит вам увидеть количество операций ввода-вывода в секунду за интервал записи, переключение контекста, статистику памяти. Вы можете разбить это на диск или просто взглянуть на систему в целом. Collectl также поддерживает блеск.
Это отличный инструмент для получения обзора общей производительности системы. Удачи, судя по наблюдениям, диски SATA обычно достигают максимума между 200-300 IOPS при произвольном доступе.
Итак, это похоже на проблему мониторинга и отчетности о мощности. Если вы собираетесь начать измерять статистику трендов, я бы пошел по всем направлениям, чтобы вы могли сравнивать, соотносить и т. Д.
Что касается инструментов, у вас есть ganglia, zenoss, nagios и т. Д. В мире с открытым исходным кодом, а также множество других продуктов поставщиков.
Вы можете настроить их для отслеживания, измерения и хранения интересующих вас KPI, а затем периодически сообщать о них.
Учитывая ваши запросы об использовании ОЗУ, было бы целесообразно включить статистику памяти, использование свопа и ЦП, чтобы вы могли сравнить их по всем направлениям за один и тот же период времени и увидеть, какие из них ограничиваются и т. Д.
После сбора данных вы можете сохранить все это в хорошей большой базе данных для отчетности, возможно, для уточнения исторических данных, например. хранить каждые 5 секунд метрики в течение 6 месяцев, затем поминутно, затем 5, затем по часам, когда вы вернетесь назад. Подобные вещи могут быть написаны и запущены через cron, autosys и т. Д.
Эти отчеты дадут вам то, что нужно руководству, т.е. что-то с красивыми графиками.
А для повседневного управления вы можете просматривать информацию в реальном времени на диаграмме / цифрах через консоль, чтобы увидеть, как вы работаете в любой момент.
В зависимости от вашего внутреннего хранилища (IBM SVC / DS8000) вы можете напрямую получать статистику, относящуюся к случайным IOPS.
Для получения статистики с сервера вы можете использовать nmon. Это бесплатно (как в пиве). Первоначально разработанный IBM для AIX, также работает в Linux.
Если люди используют SAR, я, по крайней мере, надеюсь, что вы собираете данные каждые несколько секунд. Когда я использую collectl, я пробую один раз в секунду. Что касается измерения того, насколько хорошо вы выполняете случайный ввод / вывод, используйте такой инструмент, как dt Робина Миллера (его можно погуглить), и вы можете легко сгенерировать МНОГО случайных вводов / выводов, а затем просто измерить с помощью collectl, чтобы увидеть, сколько вы можно делать в секунду. Типичный диск обычно выполняет максимум 200-300 операций ввода-вывода в секунду, что в значительной степени зависит от задержки вращения. Размер блока имел минимальное влияние, поскольку ожидание 1/2 оборота, чтобы диск оказался в нужном месте, подавлял все остальное.
кстати - iowait - одно из самых неправильно понимаемых измерений. Это НИЧЕГО не имеет отношения к загрузке процессора, это просто означает, что процессор больше ничего не делал, пока выполнялся ввод-вывод. Фактически, если вы на 100% iowait, это означает, что вы примерно на 100% простаиваете!
-отметка