У меня возникают проблемы с доступом к диску в веб-приложении.
Основная нагрузка - это множество одновременных вставок / обновлений / выборок в больших таблицах.
В настоящее время это одна стойка 2RU, на которой работают SQL Server 2000 и IIS, работает raid5 с SAS 4x15k для БД; и 6 ГБ оперативной памяти / 8 физических ядер. Использование процессора и памяти кажется нормальным.
Вещи, которые я рассматриваю ....
На что я должен смотреть / обдумывать?
Спасибо Крис
Переместите свои данные и журналы в FusionIO диск, очень-очень дорогой, но, насколько мне известно, вы не можете получить более быстрое постоянное хранилище прямо сейчас.
Да, и вам, конечно же, следует перейти на 64-разрядную версию 2008R2, плюс загрузите память.
Сразу приходит в голову мысль о преобразовании этого RAID5 в RAID10 или пару RAID1.
Это обширная тема, но я мог бы предложить несколько советов, которые помогут вам начать работу. В общем, я думаю, что можно с уверенностью сказать, что вам нужно будет собрать более точную информацию, прежде чем вы сможете решить, как лучше всего решить вашу проблему. В конце концов, это, вероятно, сведется к проблеме с памятью или диском.
(Я проигнорирую возможность просмотра запросов, которые выполняются медленно, и попытки выяснить, есть ли способы их улучшить. Это огромная тема, но использование анализатора запросов может помочь вам определить, отсутствует ли у вас индекс или запрос должен быть полностью переписан.)
Я бы начал с использования инструмента администрирования производительности, чтобы посмотреть на несколько ключевых показателей. Счетчики производительности SQL Server - хорошее место для поиска. Дисковая очередь статистика также может быть очень показательной. Ожидают ли приложения (например, SQL Server) дискового ввода-вывода для выполнения операций? Если да, то вы знаете, что вам нужно будет обновить диски (или, возможно, исправить запросы). @Hutch прав в том, что RAID 10 будет предлагать лучшую производительность, чем RAID 5 для сервера базы данных, но на самом деле это вступит в игру, только если вы ждете записи. 4 диска 15k RPM в RAID 5 должны быть в состоянии справиться с вполне разумной нагрузкой с приличной картой RAID (конечно, то, что разумно и / или прилично, относительно).
Я бы также проверьте память. На сервере работает SQL Server 2000, поэтому я предполагаю, что это 32-разрядная серверная ОС. Действительно ли SQL-сервер может использовать всю эту память? В 32-битной системе вам нужно использовать PAE использовать все 6 ГБ, и даже тогда я считаю, что сам процесс SQL-сервера сможет вырасти только до 4 ГБ. Вы можете использовать такую программу, как проводник процессов sysinternals, чтобы посмотреть, сколько памяти фактически используется. Вы даже можете посмотреть, сколько памяти «хочет» SQL Server - посмотрите счетчики SQL Server: Memory Manager (если они доступны на 2000, не могу припомнить).
Вы также упоминаете, что на сервере работает IIS. Если вы используете MS SQL Server на сервере, на котором также работают другие сильно загруженные службы, вы можете захотеть вручную настроить объем памяти, который следует использовать. По умолчанию SQL Server предполагает, что он находится на выделенном сервере, и пытается динамически выделить как можно больше памяти; в зависимости от потребностей ваших процессов IIS это может быть не очень хорошо. На серверах, на которых запущено несколько приложений, мне обычно нравится настраивать SQL Server на использование точно определенного количества ОЗУ, задав для минимума и максимума одно и то же значение (например, 4 ГБ, 10 ГБ и т. Д.).
Наконец, вы можете подумать об обновлении SQL Server. SQL Server 2005 представил несколько значительных улучшений скорости в определенных областях, которые могут принести вам пользу в зависимости от вашей настройки. Не говоря уже о том, что вы можете получить 64-битную версию SQL Server 2005/2008 и запустить ее в 64-битной ОС, чтобы получить еще больше памяти, а память на сегодняшний день является одной из самых важных вещей для SQL. сервер.
Пара вещей. Во-первых, кластеризация сервера не даст вам никакого выигрыша в производительности, а только повысит доступность.
Вероятно, самое простое, что вы можете сделать для уменьшения дискового ввода-вывода, - это увеличить объем памяти на вашем сервере. Чем больше страниц данных хранится в ОЗУ, тем меньше физических операций ввода-вывода требуется для выполнения запросов.
В зависимости от вашей рабочей нагрузки, если вы можете позволить себе перейти на SAN, тогда вам, вероятно, захочется разделить вашу TempDB, журналы и файлы данных на отдельные физические диски (вы можете посмотреть эту статью MS о хранилище 10 лучших практик для SQL Server: http://technet.microsoft.com/en-us/library/cc966534.aspx). Как заявил Хатч, при переходе с RAID 5, особенно для журналов и TempDB, они имеют большое количество операций записи (RAID 5 имеет штраф записи для четности).
Как говорит Chopper3, диски FusionIO - одни из самых быстрых в настоящее время. Если у вас есть на них бюджет, это определенно одна из областей для изучения (особенно для ваших TempDB).
HTH, Дэн
В этой теме для ответа нужен огромный «Это зависит от обстоятельств». Хотя опубликованные до сих пор ответы хороши и верны для данных условий, есть гораздо больше.
Да, переход с RAID-5 на RAID-10 - огромная галочка в столбце «Сделать это сейчас», но что насчет частей, которые нам не сказали?
Подумав об этом, я придумываю следующие элементы: Схема диска:
Какие файлы на каких дисках? Где находится TempDb и сколько файлов связано с TempDb. Находятся ли БД и T-журналы на разных дисках?
Управление запросами и оптимизация:
Были ли определены и оптимизированы самые тяжелые запросы? Как? Вызывают ли обновления перемещение строк или они могут «обновляться на месте»? Перемещение строк во время обновления вызывает всевозможные проблемы с производительностью. Управление индексами: существуют ли необходимые индексы и правильно ли они определены, чтобы их можно было использовать в запросах, которые в них нуждаются? Восстановление индексов: индексы со временем становятся фрагментированными, и их необходимо реорганизовать или перестроить. Если этого не сделать, это повлияет на производительность.
Среда: фрагментация диска может привести к фрагментации файлов. Даже когда диск содержится в чистоте, большое количество экстентов для любого файла DB или T-Log имеет негативный эффект. Обновление с SQL 2000 до SQL 2005 или (еще лучше) 2008 или 2008 R2 - отличное предложение. Запуск на Windows Server 2008 x64 или Windows Server 2008 R2 x64 дополняет 6 ГБ памяти изначально. SQL Server 2008 и 2008 R2 имеют встроенные инструменты, помогающие выявлять проблемные запросы. В напряженной среде с напряженным администратором баз данных это стоит обновления. Кэш-память контроллера накопителя: достаточно ли этого? Совместно ли кеш-память между несколькими логическими дисками?
Ресурсная конкуренция (давление):
Помимо IIS, какие еще процессы в системе SQL Server конкурируют за ресурсы системы?
Добавление SAN - неплохая идея, но вам нужно разбираться в среде. Очень важно знать, является ли причина скачков производительности из-за сканирования таблиц, неправильного управления внешними ключами, перемещения строк во время обновления, какой-либо другой проблемы или «всего вышеперечисленного». Незнание первопричины (причин) означает, что добавление SAN будет лишь временным благом. Кроме того, знание вашей среды является обязательным для правильного определения размера SAN - речь идет не только о свободном пространстве.
Я не знаю вашего окружения и не могу дать разумного ответа, что вы должен делать; Кроме того, мой список, приведенный выше, действительно является вершиной темы, которой было посвящено много продуманных книг.