Вопросы Теги

Диагностирование Производительности Пропускной способности средств ввода-вывода в SQL Где угодно

Необходимо задать себе эти вопросы, когда Вы думаете об аутсорсинге приложений:

  • Мой штат испытывает недостаток в каких-либо из правильных навыков или необходимой глубины?
  • Разве я не уверен, что могу восстановиться с отключений электричества достаточно быстро?
  • У меня есть проблемы при хождении в ногу с технологическим циклом 18 - 36 месяцев?
  • Ежедневные операции и поддерживание в рабочем состоянии систем мешают мне фокусироваться на новых стратегических проектах?

Я предполагаю, ответили ли Вы на два или больше из этих вопросов с "да", необходимо рассмотреть аутсорсинг приложения или сервиса. Это не означает нахождение поставщика которому будут нужны требования. Это в большой степени зависит, какое приложение Вы хотите произвести на стороне.

Я предполагаю, что существуют некоторые стандартные приложения как электронная почта, сотрудничество и т.д. с большим количеством хороших стандартных опций аутсорсинга. Если Ваше приложение является более специализированным, я думаю, что оно зависит от того, как программное обеспечение реализовано (клиент/сервер, сеть...) и каковы технические ограничения.

Конечно, необходимо задать себе подобные вопросы о своем производящем на стороне поставщике услуг для вычисления всех рисков, которые Вы берете при вводе отношений с внешней компанией.

Вот некоторые вопросы оценить потенциальных поставщиков:

  • У поставщика есть послужной список сервисного обязательства?
  • Кто существующие клиенты поставщика, и насколько удовлетворенный они?
  • Как Вашей учетной записью будут управлять? Как быстро можно ожидать принимать телефонный вызов возврата из менеджера учетных записей?
  • Насколько гибкий поставщик в реализации Ваших определенных потребностей?
  • Каково качество инфраструктуры поставщика и инфраструктуры безопасности?
  • Поставщик предлагает план миграции?
  • Насколько сильный финансовое здоровье поставщика? Это слишком часто пропускается, но особенно запуститесь, компании имеют определенный риск того, чтобы обанкротиться.
  • Как оценка их сервисов?
4
задан 18 June 2009 в 19:37
3 ответа

При контакте с НАБЕГАМИ традиционные Дисковые счетчики в perfmon могут отдать вводящие в заблуждение результаты. Они покажут кэшу ввод-вывод, а не диск ввод-вывод. Поэтому удостоверьтесь, что Вы также смотрите на % Idle Time счетчик. Это будет, вероятно, самый точный результат, но он будет инвертирован (более низкий процент равняется более занятым дискам),

2
ответ дан 3 December 2019 в 03:38
  • 1
    Спасибо, это похоже на него средние числа приблизительно 20%, поэтому возможно, диск, ввод-вывод не является проблемой. –  Ralph Wissing 18 June 2009 в 23:52
  • 2
    Если значение, которое Вы читаете, составляет 20%, который означает it' s только бездействуют 20% времени. Значение 80% времени it' s запись. Вы добираетесь очень близко к наличию проблем ввода-вывода. –  Joseph Kern 22 June 2009 в 18:59
  • 3
    Моя ошибка - я на самом деле сделал " conversion" когда я отправил. График считал неактивных приблизительно 80%, таким образом, загрузка ввода-вывода составляла приблизительно 20%. Однако я думаю, что единственный способ быть уверенным состоял бы в том, чтобы получить информацию от самого RAID-контроллера. –  Ralph Wissing 24 June 2009 в 16:45

Статистической величиной CurrIO не является SMP, безопасный в SA. Вы были бы лучше для рассмотрения счетчиков "PhysicalDisk", предоставленных Windows perfmon. В особенности: "Текущая Дисковая Длина очереди", "В среднем. Дисковая Длина очереди", "В среднем Длина очереди Записи на диск" и "В среднем. Длина очереди Чтения с диска".

Я не уверен, куда "3 +#disks" значение прибыли из. Если Вы ожидаете, что много IO будет сделано на диске, очень разумно иметь несколько iOS, выдающихся на том диске.

1
ответ дан 3 December 2019 в 03:38
  • 1
    Я также думал " 3 + # disks" было немного странным - Perfmon doesn' t показывают что-либо возмутительное, таким образом, проблемы производительности не могут произойти из-за диска ввод-вывод. Если " CurrRead" и " CurrWrite" действительно ли SMP быть безопасным? Надеется быть приблизительно 100/с средними числами, со скачками чуть более чем 1,000/с. –  Ralph Wissing 19 June 2009 в 00:02

Другой способ видеть, насколько ввод-вывод выполняется базой данных, путем рассмотрения статистики кэша. Если база данных читает из кэша, она не делает такого же количества диска ввод-вывод. Свойства на два дб, которые могут быть просмотрены, являются "CacheRead" и "CacheHits", как так:

SELECT db_property ( 'CacheRead' ), db_property ( 'CacheHits' )

SQL Где угодно 10.0.0 руководства рекомендует, по крайней мере, 70%-й процент удачного обращения в кэш. Если это, ниже которого, Вы, возможно, должны выделить больше кэша серверу. Можно получить процент непосредственно как это:

SELECT STRING(((db_property ( 'CacheHits' ) / db_property ( 'CacheRead' )) * 100), '%')

В моем особом случае, когда база данных имела кэш на 22 ГБ, процент хита составлял приблизительно 58%. После установки кэша к 55 ГБ процент хита подошел к 97%. Хотя свойство "CurrIO" и "MaxIO", точные числа могут быть неправильными, относительное отбрасывание, было решительным после этого изменения также.

1
ответ дан 3 December 2019 в 03:38

Теги

Похожие вопросы