Это стандартная история, идет борьба между разработчиками и администраторами. Одно обвинение в том, что дизайн базы данных и запросы плохи, в то время как другие говорят, что это нехватка оборудования и количества данных.
Итак, я прошу вас - это мой IBM x3400 с 2 ксенонами 2 ГГц и SCSI raid 5 и 4 ГБ ОЗУ, адекватно сформированным для базы данных MSSQL размером 53 ГБ с таблицами.Основные детали - около 6,5 миллионов записей в деталях и 2 миллиона в заголовках документов. в то время как другие составляют около 100К (например, предметы).
Мы постоянно страдаем от недостаточной производительности при получении данных из SQL, этот сервер предназначен только для того, чтобы быть только сервером SQL и действовать как подписчик реплицированных данных с другого сервера SQL.
Другой вопрос: как администраторы баз данных планируют размер оборудования для серверов баз данных? Есть какой-то стандартный подход или это просто опыт и смысл?
Есть какой-то стандартный подход или это просто опыт и смысл?
Опыт и смысл. Вы также думаете наперед и проверяете, что имеет смысл через пару лет. Например, у SuperMicro есть серверы NICE с местом для 24-72 дисков в конфигурации SAS. Таким образом, у вас есть возможность избежать использования SAN (более дорогой) и заполнять диски по мере необходимости. Другие получают небольшой сервер, и у них заканчиваются возможности. Вы также можете почерпнуть некоторые идеи из тестирования на обычной рабочей станции.
Это стандартная история, идет борьба разработчиков и администраторов.
Нет это не так.
Одно обвинение в том, что дизайн базы данных и запросы плохи, в то время как другие говорят, что это недостаток оборудования и количества данных.
Снова нет. Дизайн БД можно измерить довольно объективно. Например: есть определенные задокументированные и известные подходы (о которых МНОГО разработчиков в основном не знают). Вы когда-нибудь слышали о 5-й нормальной форме?
То же и с запросами. Я действительно могу ВИДЕТЬ, эффективно ли выполняется запрос. Здесь нет настоящей серой зоны. Тем не менее, возможны компромиссы, но если дело дойдет до обвинения, я могу быть уверен, что что-то не так.
Довольно часто разработчики не знают ничего, кроме «это простой выбор», и понятия не имеют, как работать с базой данных, а затем пытаются решить проблему с помощью оборудования. Был там, видел это. Не всегда, но это вероятная догадка.
Я мог бы предположить, что и оборудование, и код в какой-то степени виноваты.
Во-первых, вы можете использовать SQL Profiler и динамические управленческие представления, чтобы проверить, какие запросы медленные и почему они медленные. Использовать эти инструменты довольно просто на высоком уровне, вы можете легко увидеть, привязаны ли вы к процессору, к диску, к памяти и т. Д. Но понимание сложных планов запросов и оптимизации - это не то, чему вы собираетесь научиться. не тратя время. Отличный отсутствующий индекс и отчет о медленных запросах в Панель мониторинга производительности SQL Это поможет вам найти низко висящие фрукты.
С другой стороны, это серверное оборудование явно слабовато по современным стандартам. Моя персональная рабочая станция в офисе мощнее во всех отношениях (включая SSD вместо механических дисков). Мы развертывали 64-битные серверы баз данных с> 16 ГБ ОЗУ. пять лет назад. Аппаратное обеспечение - это самая дешевая часть любой ИТ-операции, которая, безусловно, дешевле, чем десятки или сотни человеко-часов, которые вы тратите на решение этой проблемы.
Предложения:
При определении размера ОЗУ важно знать, каков ваш вероятный «рабочий набор», и убедиться, что у вас достаточно ОЗУ для этого, умноженное как минимум в пару раз. Ваш нормальный рабочий набор - это все страницы индекса и данных, которые обычно используются, и возможность хранить все это в ОЗУ с достаточным пространством для резервирования «более исключительных, но все же не редких» запросов значительно сократит дисковый ввод-вывод, необходимый для операций чтения. .
Например, база данных размером 10 ГБ (на значительную величину меньше вашей, но в теории существует любой размер ваших данных) для одного из наших клиентских приложений содержит около 1 ГБ активных страниц данных: индексы и строки таблиц, к которым, вероятно, будет регулярно осуществляться доступ. поскольку пользователи занимаются своими обычными делами. Еще ~ 4 Гбайт - это более старые данные, которые не читаются в большинстве обычных сеансов (поскольку большинство представлений по умолчанию отображают не более месяца или трех данных, а данные, индексы и запросы достаточно хорошо спланированы, чтобы старые страницы данных не будут прочитаны, если пользователь не попросит увидеть что-то более далекое во времени (что относительно редко при повседневном использовании). Последние ~ 5 ГБ - это капли - документы, которые пользователи прикрепили к записям и к которым редко обращаются больше чем через некоторое время после добавления, кроме как во время аудита. Даже с таким размером данных, я сомневаюсь, что 2 ГБ ОЗУ будет достаточно для поддержания быстрого доступа (БД, о которой я говорю, живет на сервере 4 ГБ, предназначенном для запуска MSSQL, другой машины действует как веб-сервер и другие службы, связанные с приложением), поэтому вам может потребоваться переосмыслить размер ОЗУ для размера ваших данных - ОЗУ в наши дни относительно дешево, поэтому, если ваш сервер может справиться с дополнительным увеличением его до 8, 12 или даже 16 ГБ может дать вам хорошую отдачу от инвестиций.
Когда нельзя избежать дискового ввода-вывода, я бы отказался от RAID5 и RAID6, если ваши данные видят большую активность записи. Стандартный RAID10 (или немного менее стандартные конфигурации RAID10, подобные тем, которые предлагаются драйвером Linux RAID10 и некоторыми аппаратными решениями) будет работать также для большинства нагрузок чтения, заметно лучше для большинства нагрузок записи и предлагает аналогичную избыточность (любой диск может выйти из строя). Если вы не хотите переходить на четыре диска, вы можете попробовать трехдисковый RAID10 (называемый RAID1E большинством контроллеров IBM), если он поддерживается вашей средой. Также очень стоит подумать о разделении вашего массива на два, как предлагает TomTom. Для операций записи вы, вероятно, обнаружите, что наличие журнала транзакций на массиве RAID1 из двух дисков и файлов данных на другом будет работать значительно лучше, чем при использовании RAID10 - производительность RAID10 при массовом чтении, близкая к RAID0, может быть быстро снижена из-за характер произвольного доступа для записи в базу данных (обновление страниц данных и индекса, которые могут быть распределены по файловому пространству, обновление журнала транзакций перед фиксацией данных в файлах данных и отметка их как зафиксированных в журнале по завершении и т. д.). Разделение операций журнала и файлов данных по разным шпинделям может значительно во многих случаях повысить производительность базы данных. Если у вас достаточно места для требуемых дисков, сохранение tempdb (или любой другой СУБД, эквивалентной tempdb MS) и тому подобное в третьем массиве также может иметь существенное значение, если ваши запросы и хранимые процедуры интенсивно используют временные таблицы (это Иногда может быть удивительно, сколько обстоятельств планировщик запросов рассмотрит возможность использования tempdb за вашей спиной!). Конечно, использование твердотельных накопителей также может быть ответом на производительность произвольного доступа - хотите ли вы получить лучшее соотношение цена / производительность с теми или иными схемами массивов (или и другие схемы массивов) существенно зависит от вашей базы данных (ей) и типичных шаблонов доступа.
Еще одна вещь: прежде чем тратить время + усилия + деньги на перестройку подсистемы ввода-вывода, убедитесь, что вы запускаете некоторые показатели производительности в часы пик, чтобы убедиться, что у вас нет плохих процедур, сильно ограничивающих ЦП. Иногда сложные процедуры (особенно те, которые используют курсоры не совсем оптимальным образом) могут привязать подсистему ЦП + память на длительное время (добавление большего объема ОЗУ и улучшенные возможности ввода-вывода здесь не имеют большого значения) и часто могут быть значительно оптимизированы путем переосмысления курсоры / циклы или возможность их полностью удалить. Сочетание настраиваемого ведения журнала трассировки SQL и ведения журнала Windows Performance Monitor (или эквивалентных инструментов мониторинга для людей, использующих другую комбинацию ОС + БД) может оказаться большим подспорьем в поиске ваших ключевых узких мест (нехватка памяти, производительность ввода-вывода, меньше чем оптимальный код, ...), и вы должны пытаться исправить проблему, пока не будете относительно уверены, что исправляете правильную проблему.