Ускорение обработки таблицы временного файла SQL Server с Псевдодиском
В основном Вы NAT и portforward дважды. Однажды на router2, чтобы заставить IP/порт в router1 сети и с другой стороны в router1 добираться на Интернет. Затем Вы соединяетесь с IP, который выставляется Интернету, и он автоматически переводится, и порт передается внутреннему IP. Никакая потребность в любых специальных маршрутах, когда это - единственный ПК как это.
Дело не только в скорости, а в ожидании. Тестируйте правильно. Проверьте количество операций ввода-вывода в секунду и длину дисковой очереди. Используйте Perfmon и профилирование SQL. Продолжайте - я подожду.
Вы уже знаете, что ОС должна быть на одном наборе шпинделей, MDF - на другом, LDF - на другом, а файлы tempdb - на третьем, если у вас действительно есть проблемы с производительностью. Если вы не можете взять на себя обязательство сделать это, сравните это и определите свои приоритеты. Кроме того, разные шаблоны чтения и записи могут диктовать разные уровни RAID для каждого из них.
Вы можете обнаружить, что стандартные диски с правильными конфигурациями RAID могут доставить вас туда, где вам нужно, а не перегружать корпоративные SSD. Хотя, если база данных tempdb становится достаточно загруженной, для нее может подойти один SSD. Вероятно, нет необходимости в RAID для производительности, хотя для избыточности это может быть хорошей идеей. Конечно, это зависит от вашего бюджета и от того, как долго вы можете не работать.
Вы также знаете, что сервер SQL должен быть отделен от веб-сервера, верно? Если производительность вызывает беспокойство? Даже если сейчас у вас нет проблемы, но если вы вырастете, вам будет сложно определить, что из-за того, что испытывают тяжелее, и какое решение лучше всего исправить.
RAID предназначен для избыточности , производительность зашкаливает. Например, для RAID 5 для чтения фрагмента данных все диски компонентов должны быть прочитаны, и должна быть проверена четность (что медленнее, чем чтение с одного диска, движения головки выиграли » t обязательно должны быть синхронизированы, поэтому вы ждете самого длинного набора, а не только среднего), запись означает чтение всего, вычисление четности и запись новых данных и четности, что явно медленнее, чем просто запись.
Да, хорошая реализация RAID и умная операционная система могут значительно смягчить это (необходимо, ведь даже отдельные диски ужасно медленны в отношении ОЗУ, поэтому любая стоящая операционная система выполняет обширное кэширование независимо от дисков).
Да, интеллектуальная СУБД также будет кэшировать данные в ОЗУ в максимально возможной степени (соблюдая обещания, данные в отношении согласованности данных, устойчивости к сбоям и т. д.; при необходимости, она будет явно ждать, пока данные будут безопасно на диске, прежде чем продолжить).
Для любой БД RAMdisk является чистым ядом («данные, явно записанные на диск, поэтому безопасные» не являются).
так что скорость ввода-вывода tempdb высокая при записи и чтении
Слишком мало ОЗУ. tempdb - только операции ввода-вывода при переполнении - в противном случае SQL Server не выгружает страницы tempdb на диск.
Таким образом, RAM-диск не поможет - вместо этого добавьте больше памяти.
Спасибо за все ответы. Они мне очень помогли. После некоторых последующих исследований я обнаружил, что скорость ввода-вывода не была основным узким местом в данном конкретном случае, хотя в целом она важна. Передовой опыт управления базой данных tempdb предполагает наличие как минимум 4 файлов данных. Microsoft также рекомендует 1 файл данных для каждого ядра процессора. Наличие большего количества файлов помогает уменьшить некоторые разновидности конфликтных проблем.
Некоторые ссылки об этом: