Система, которую мы разрабатываем, состоит из внешнего интерфейса веб-приложения и внутреннего интерфейса, который выполняет большую часть обработки данных с использованием хранимых процедур в SQL Server 2008 R2 (пожалуйста, не спрашивайте, почему ...). Эти хранимые процедуры интенсивно используют временные таблицы (создание, вставки, объединения), так что tempdb Скорость ввода-вывода высокая при записи и чтении. Нашим клиентам нужна скорость, поэтому мы можем порекомендовать следующее:
Некоторые контекстные данные:
Мы протестировали подход ramdisk на ноутбуке с большим количеством оперативной памяти. По крайней мере, ускорение заметно (время выполнения хранимых процедур сокращено до 1/3).
Мне нужна помощь, чтобы определить, хорошее это решение или нет, и выявить какие-либо недостатки (очевидные или менее очевидные), которые я мог упустить.
РЕДАКТИРОВАТЬ: Спасибо за ответы! Я забыл прямо упомянуть, что приложение будет одновременно использовать несколько пользователей, поэтому будет выполняться несколько операций с временными таблицами. Кроме того, смешивание веб-сервера и сервера БД - не наш выбор, мы уже знаем, что это не оптимально;)
Дело не только в скорости, а в ожидании. Тестируйте правильно. Проверьте количество операций ввода-вывода в секунду и длину дисковой очереди. Используйте Perfmon и профилирование SQL. Давай, я подожду.
Вы уже знаете, что ОС должна быть на одном наборе шпинделей, MDF - на другом, LDF - на другом, а файлы tempdb - на третьем, если у вас действительно есть проблемы с производительностью. Если вы не можете взять на себя обязательство сделать это, сравните это и определите свои приоритеты. Кроме того, разные шаблоны чтения и записи могут диктовать разные уровни RAID для каждого из них.
Вы можете обнаружить, что стандартные диски с правильными конфигурациями RAID могут доставить вас туда, куда вам нужно, а не на корпоративных SSD. Хотя, если база данных tempdb становится достаточно загруженной, для нее может подойти один SSD. Вероятно, нет необходимости в RAID для повышения производительности, хотя для резервирования это может быть хорошей идеей. Конечно, это зависит от вашего бюджета и от того, как долго вы можете не работать.
Вы также знаете, что SQL-сервер должен быть отделен от веб-сервера, верно? Если производительность вызывает беспокойство? Даже если сейчас у вас нет проблем, но если вы вырастете, вам будет сложно определить, что из-за того, что забивают сильнее, и какое решение лучше всего исправить.
Спасибо за ответы на все вопросы. Они мне очень помогли. После некоторых последующих исследований я обнаружил, что скорость ввода-вывода не была основным узким местом в данном конкретном случае, хотя в целом она важна. Передовой опыт управления базой данных tempdb предполагает наличие как минимум 4 файлов данных. Microsoft также рекомендует по одному файлу данных для каждого ядра процессора. Наличие большего количества файлов помогает уменьшить некоторые виды конфликтов.
Некоторые ссылки об этом:
RAID предназначен для избыточность, производительность уходит в окно. Например, RAID 5 для чтения фрагмента данных все должны быть прочитаны компоненты дисков и проверена четность (что является медленнее, чем чтение с одного диска, движения головы не обязательно будут синхронизироваться, поэтому вы ждете самый длинный набора, а не только среднего), запись означает чтение всего, вычисление четности и запись новых данных и четности, что явно медленнее, чем просто запись.
Да, хорошая реализация RAID и умная операционная система могут значительно смягчить это (необходимо, даже отдельные диски ужасно медленны в отношении ОЗУ, поэтому любая операционная система, достойная ее соли, выполняет обширное кэширование независимо от дисков).
Да, интеллектуальная СУБД также будет кэшировать данные в ОЗУ в максимально возможной степени (соблюдая обещания, данные в отношении согласованности данных, устойчивости к сбоям и т. Д.; При необходимости, она будет явно ждать, пока данные будут безопасно на диске, прежде чем продолжить).
Для любой БД RAMdisk - это чистый яд («данные, явно записанные на диск, а значит безопасные», не являются).
так что скорость ввода-вывода tempdb высока при записи и чтении
Слишком мало оперативной памяти. tempdb - только операции ввода-вывода при переполнении - иначе SQL Server не выгружает страницы tempdb на диск.
Таким образом, RAM-диск не поможет - лучше вставьте больше памяти.