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