Больше процессорных ядер против более быстрых дисков

Я, как обычно, являюсь частью небольшой компании, выполняющей ряд различных ролей. Последний из них - это приобретение выделенного блока SQL Server для нашего веб-приложения .NET. Мы были процитированы на двухъядерной конфигурации процессора Xeon E5-2620 (шесть ядер) 2,00 ГГц (всего 12 ядер) с 32 ГБ оперативной памяти. В результате у нас был ограниченный бюджет для дискового массива, который в основном состоял бы из двух 2,5-дюймовых дисков SAS 300 ГБ (15 тыс. Об / мин) в конфигурации RAID 1.

Я знаю, что настройка диска является неоптимальной для SQL Server, и я бы очень хотел использовать RAID 10, чтобы мы могли разместить базу данных, файлы журналов и базу данных tempdb на своих собственных дисках. Чтобы сделать это совместимым с нашим бюджетом, я должен рассмотреть сокращение количества процессорных ядер? или я получу лучший банк для хранения ядра и использования меньшего количества дисков, возможно, 4 в двойной конфигурации RAID 1?

Вот некоторые дополнительные характеристики

• База данных SQL Server наклонена к большому количеству операций чтения-записи, вероятно, 80% против 20% соответственно. В настоящее время размер БД составляет около 10 ГБ, в настоящее время он составляет 26 ГБ, увеличиваясь со скоростью 250 МБ в месяц.

• В настоящее время работает на SQL Server 2008 R2 Standard на одном четырехъядерном компьютере Xeon, совместно используемом с веб-сервером (12 ГБ оперативной памяти, 2 диска SAS по 10 ГБ 300 ГБ в RAID 1), и планирует перейти на SQL Server 2012 Standard.

• База данных обслуживает около 100-150 одновременно работающих пользователей с некоторыми заданиями фонового планирования. Читая это, я думаю, что 12 ядер - это серьезное излишнее!

Я развернул все приложение в облачной службе Azure (2 небольших экземпляра), связанной с БД SQL Azure. Хотя при тестировании производительность была приемлемой (почти нулевая нагрузка), я потерял смелость использовать в производстве из-за непредсказуемости, о которой я так много читал. Это может лучше работать при масштабном подходе, но с базой данных всего 10 ГБ я, вероятно, смогу уйти с масштабированием прямо сейчас и сэкономить немного денег.

Сначала я не обращал внимания на затраты на лицензирование и не осознавал, что лицензирование SQL Server 2012 основано на количестве ядер. У меня есть подписка BizSpark MSDN со стандартной лицензией SQL Server 2012, поэтому мне нужно узнать, сколько ядер будет использоваться из коробки.

Судя по опыту, который скромен, но я думаю, что стоит поделиться, главное узкое место в базах данных SQL (Sybase и SQL-сервер здесь) - это хранилище.

Но я думаю, что будет справедливо, что кто-то сначала оценивает их настройку, прежде чем делать какие-либо неправильные предположения. В моем случае загрузка ЦП никогда не была достаточно высокой, чтобы оправдать обновление ЦП в ближайшее время. Вместо этого я обновил с одного диска до RAID 1, а затем до RAID 10 + увеличение с 8 ГБ до 16 ГБ оперативной памяти.

Все эти обновления RAID помогли сократить предыдущее время ожидания в 2-6 раза. Я подозреваю, что обновление до SSD будет еще лучше. Если вы думаете об этом, все это может быть уменьшено до (теоретической) пропускной способности. Ваша комбинация [(RAM Speed ​​+ RAM Size + Memory controller) ссылка на CPU] имеет ограничение пропускной способности, которое будет самым важным фактором в операциях чтения, когда ваши данные всегда должны кэшироваться, а в вашем конкретном (RAID) хранилище есть ограничение пропускной способности ( влияет на чтение, когда кэш пропущен, и запись при сбросе или когда многие клиенты пишут много данных вместе).

Нормализуйте все эти ограничения в максимально возможной степени (приблизьте их так, чтобы у вас не было потраченных впустую ресурсов) и увеличьте их как можно больше (обновляйте там, где это необходимо и только при необходимости, не позволяйте ресурсам расходоваться впустую, если система выиграла ' я не смогу их использовать, потому что мешает другое узкое место). В конце концов, ваше худшее узкое место будет наименее эффективной (с наименьшей пропускной способностью) серверной подсистемой в вашей конкретной конфигурации.

Могу также добавить, что в процессе обновления я создал отдельные конфигурации RAID для файлов базы данных и файлов журнала базы данных. Причина заключалась в том, что файлы журнала базы данных обычно интенсивно записывают. Файл журнала используется для восстановления базы данных после сбоя, и он всегда записывается немедленно, поскольку транзакция фиксируется до того, как какие-либо данные будут записаны в файл базы данных.

Файл журнала также используется некоторыми серверами репликации базы данных, но большая часть репликации выполняется не сразу, а часто, поэтому здесь влияние на производительность чтения минимально. По крайней мере, я так думаю. Я сделал минимальный сравнительный тест при повторном выполнении этого обновления, поэтому я рекомендую всем сначала сравнить их различные конфигурации и сначала обновить их хранилище, а затем ОЗУ и сетевое соединение, прежде чем думать об обновлении своих ЦП.

После более обширных обновлений на более чем 5 серверах я вернулся, чтобы поделиться своим опытом. Я определенно все еще рекомендую сначала обновить хранилище, затем ОЗУ, а затем ЦП. Причина - несоответствие пропускной способности в системе между хранилищем, ОЗУ и ЦП в порядке убывания. Поэтому я обновил группу серверов с RAID10 и двух RAID1 до SSD.

Я сделал это из-за проблем с ценами (у меня есть еще 20 серверов для обновления), чтобы переместить данные и файлы объектов базы данных на SSD (да, только один SSD в RAID0) и переместить журнал транзакций плюс базу данных tempdb на RAID-массив 4xHDD10 конфигурации. Я также тестировал с tempdb на SSD с отличными результатами (на самом деле очень хорошие результаты с более чем в 15 раз более быстрыми запросами, иногда некоторые отчеты занимали секунды, а не минуты в прошлом), но позже я переместил tempdb на диск RAID10, потому что интенсивной записи износа SSD.

Так что теперь в основном я наблюдал в 10-15 раз более быстрое время отклика на некоторые самые длинные запросы. Твердотельный накопитель отлично подходит для быстрого считывания данных в ОЗУ, поскольку SQL Server не переносит данные в ОЗУ до тех пор, пока их не запросят, и, конечно, данные сначала должны быть загружены в ОЗУ для обработки ЦП (позже, в кэш-памяти L1, L2, L3) Таким образом, твердотельные накопители помогают значительно сократить начальное время ожидания. Кроме того, твердотельные накопители также помогают сократить время подкачки ... очистка ОЗУ и загрузка новых данных, особенно если ваша база данных больше, чем может поместиться в ОЗУ.

В целом, мы очень довольны и уже несколько месяцев работаем в таком медленном процессе миграции, чтобы позволить серверам работать, чтобы я мог собирать информацию об уровне износа, прежде чем переключить все свои серверы на эту конфигурацию. И это только SQL Server Express! : D - Просто убедитесь, что ваши SSD могут обеспечивать постоянный IOPS, потому что это еще одна вещь, которая имеет огромное значение (просто Google). Вот почему я выбрал твердотельные накопители серии Intel DC (DataCenter).

Почему-то не тот ответ, который вы, вероятно, ищете в первой части, но: вы рассматривали вопрос о том, чтобы отправить его в облако? AWS может позволить вам удовлетворить большинство вышеперечисленных потребностей и расширить покупательскую способность, не прибегая к аппаратному обеспечению.

Вторая часть - аппаратное обеспечение действительно зависит от задач. Я склонен склоняться к большему количеству процессоров, когда я могу выполнить пользовательскую интеграцию CLR, потому что тогда я могу оптимизировать для действительно параллельных решений проблем. Однако в большинстве случаев, если лучше использовать основанные на них решения, я считаю, что ОЗУ и скорость жесткого диска являются самым большим узким местом, и вторым, похоже, является ваш случай. (Где идея SSD выше была бы полезна)

Без какой-либо реальной статистики с вашего сервера я бы посоветовал вам взглянуть на некоторые решения для кэширования, чтобы уменьшить количество записей (если вы не ведете какую-либо запись с записями или вещами, для которых нужна история) и вкладываете много денег в жесткие диски. чем процессоры. SQL-сервер довольно хорош в параллельном выполнении запросов (если они написаны для него), но если вы много пишете, то ваш жесткий диск является настоящим узким местом.