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


13

Я, как обычно, являюсь частью небольшой компании, выполняющей ряд различных ролей. Последний из них - это приобретение выделенного блока 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, поэтому мне нужно узнать, сколько ядер будет использоваться из коробки.


7
10GB? Более быстрые диски не очень вам помогут. Все ваши данные почти всегда должны быть в памяти ... и сколько еще будет стоить RAID 10? А какая версия / редакция SQL Server? Я подозреваю, что лицензирование программного обеспечения легко будет в 10-20 раз дороже оборудования.
Аарон Бертран

2
В целом, я рекомендую отдавать предпочтение оперативной памяти, а не ЦПУ, а затем ЦП. Интенсивные рабочие нагрузки при записи требуют хорошего ввода-вывода, но наиболее важным фактором для вашего бюджета является то, что процессорам требуются дополнительные затраты на лицензирование. Вы рассматривали этот аспект?
Ремус Русану

4
Подумайте о покупке SSD. Извините, но цена 15k SAS делает SSD лучшим предложением. Фактически, я сейчас нахожусь в аналогичном месте, и я заменяю 300G 10k Velciraptors на 450G 10k SAS накопителей и 500G SSD (зеркальный). Цена / выгода 15k дисков SAS заставляет меня съеживаться.
TomTom

4
@TomTom согласился. 15K SAS - это как присадка к топливу для Datsun 1972 года - да, это будет немного лучше, но разница незначительна, и дополнительные затраты на SSD будут более чем оправданы.
Аарон Бертран

Ответы:


10

Судя по опыту, который скромен, но я думаю, что стоит поделиться, главное узкое место в базах данных 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).


0

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

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

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


1
Человек, ты когда-нибудь смотрел на СТОИМОСТЬ этого? Почасовая ставка за влияние является страховой, когда вы работаете 24/7. Пропускная способность для создания больших данных и загрузки безумна. Расходы на 1 Гбит - даже не говоря уже на 10 Гбит - Интернет, чтобы иметь сопоставимую ссылку, когда вам нужно переместить 50 ГБ данных в базу данных и из нее, безумны. Облако - это все хорошо и здорово, если вы (а) не используете базу данных из локальной системы, т. Е. Она остается в облаке или (б) небольшая.
TomTom

Да, я был на общественном облачном маршруте, я на самом деле далеко вниз! Производительность была посредственной, как и следовало ожидать ... но по цене она мне не помешала. Я все за разработку шаблонов горизонтального масштабирования, но Colo дешев, и вам придется потратить кучу денег, чтобы приблизиться к этому с любым из популярных поставщиков облачных решений. Конечно, это отвлекает инфраструктуру, но даже если вы добавите затраты на обслуживание оборудования, это будет трудно продать.
QFDev
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.