Кто-нибудь здесь использует SQL Server на твердотельных накопителях? Вы нашли какие-нибудь конкретные советы по оптимизации? Меня особенно интересуют способы уменьшить частоту, с которой SQL Server выполняет небольшие операции произвольной записи, поскольку они являются заклятым врагом производительности SSD, особенно MLC SSD.
Конечно, есть несколько очевидных оптимизаций: данные с большим объемом чтения должны обслуживаться с SSD, а данные с большим объемом записи следует оставить традиционным вращающимся дискам. Это, естественно, включает журналы транзакций!
При наличии достаточного бюджета, конечно, можно было бы использовать SSD-диски SLC, такие как серия X25-E или Vertex Ex, или различные предложения корпоративного уровня. Но меня также интересуют советы, которые могут помочь при настройке MLC SSD. Я думаю, что это интересная область. У одного из клиентов моих клиентов небольшой бюджет и набор данных, который значительно вырос, и им приходится полностью переписывать около сотни запросов, чтобы поддерживать достойный уровень производительности. Однако у меня есть скрытое подозрение, что менее 500 долларов на RAM и SSD-диск могут принести им больший прирост производительности, чем тысячи (возможно, десятки тысяч) долларов, затраченные на время разработчика.
Не уверен, что вы имеете в виду, говоря об уменьшении количества небольших случайных записей, которые выполняет SQL Server. SQL Server записывает страницы данных только во время контрольных точек, поэтому единственный способ ограничить количество операций записи - это изменить интервал контрольной точки или уменьшить количество операций ВМС. Вы что-то еще имели в виду?
Во всех реализациях твердотельных накопителей, которые я видел (несколько), это как бы противоположно тому, что вы предлагаете - лучше всего использовать твердотельные накопители, по-видимому, для журналов транзакций с большим объемом записи и tempdb - в основном, где самый большой я Узкое место подсистемы / O и вставьте туда твердотельные накопители - так как время поиска и задержка уменьшаются до низкой постоянной.
Ознакомьтесь с этим исследовательским документом, подготовленным MS (к сожалению, не очень подробно описывающим особенности SQL Server): Миграция серверного хранилища на твердотельные накопители: анализ компромиссов.
Надеюсь это поможет!
Вы не можете изменять характеристики ввода-вывода SQL Server. Его основная единица доступа к диску для файлов данных - это страница размером 8 КБ. Он будет писать их в основном во время контрольной точки, но также будет лениво писать их, когда может.
SQL не дожидается завершения записи на диск данных перед возвратом, должна быть завершена только запись журнала. Если вы можете хранить только один журнал базы данных на диске, тогда это будет последовательная запись, и это будет нормально на обычных быстрых жестких дисках.
Падение производительности с точки зрения SQL происходит тогда, когда ему приходится читать диски. Если вы можете предоставить ему больше памяти, тогда SQL будет хранить больше страниц данных в памяти, что быстрее, чем любой диск, SSD или другой. Очевидно, вы также можете уменьшить количество операций чтения с диска, создав соответствующие индексы. Я ожидаю, что SSD также поможет с этими чтениями, потому что они, вероятно, будут случайными и задерживаться в ожидании движения головок дисков.
Я не знаю, о каком размере базы данных мы здесь говорим, но, возможно, вы захотите взглянуть на HyperOS. Они делают sata-диски, которые на самом деле представляют собой всего лишь загрузку модулей памяти DDR2 с SSD или 2,5-дюймовым диском в качестве резервной копии. Тогда схема доступа к серверу не будет иметь никакого значения. Хотя я бы не стал ставить журналы ни на что подобное. Журналы - это то, что поддерживает согласованность ваших данных, они должны находиться на надежном носителе, и, несмотря на резервный SSD и аккумулятор, а также на сервере, вероятно, есть ИБП и т. Д., Мне все равно будет нелегко из-за отсутствия моих журналов на реальном жестком диске в каком-то отказоустойчивом RAID-массиве.
Небольшие случайные операции - это заклятый враг традиционных дисков из-за задержки поиска головки ... SSD отлично справляются именно с этой задачей.
При длительных последовательных операциях стандартные диски работают достаточно хорошо, поэтому нет смысла использовать SSD (конечно, с точки зрения производительности).
Здесь еще не достаточно места, чтобы добавить в поток комментариев, но если вы установите размер страницы БД / счетчик нескольких чтений для чего-либо на SSD в несколько раз больше размера страницы SSD, это не должно быть проблемой.
Я давно не работал с SQL Server, поэтому не уверен, доступны ли там эти параметры. Последние несколько лет я занимаюсь Oracle и DB2, и это решит ваши проблемы, так как БД будет правильно настроена на характеристики диска.
Я бы порекомендовал выровнять раздел, на котором хранятся файлы базы данных.
Я также рекомендовал бы решить, что происходит в RAID 0 для perf (ldf и TempDB), и разместить важные данные на RAID 1 (mdf).
В-третьих, вам действительно стоит обновить прошивку накопителя, а также прошивку / драйверы контроллера SATA. Таким образом, вы даете производителям оборудования и их разработчикам возможность оптимизировать производительность для вас.