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


13

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

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

Ось кілька додаткових статистичних даних

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

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

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


Я розгорнув всю програму в хмарній службі Azure (2 невеликі екземпляри), пов’язаній із БД SQL Azure. Хоча при тестуванні продуктивність була розумною (майже нульове навантаження), я втратив сміливість використовувати у виробництві через непередбачуваність, про яку я так багато читав. Це може працювати краще за допомогою масштабного підходу, але, маючи лише 10 Гб бази даних, я, ймовірно, можу втекти з масштабуванням прямо зараз і заощадити гроші.

Спочатку я не помічав витрат на ліцензування і не розумів, що ліцензування SQL Server 2012 базується на кількості ядер. У мене є підписка на BizSpark MSDN з ліцензією SQL Server 2012 Standard, тому мені потрібно прочитати, скільки ядер буде використано поза коробкою.


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

2
Як правило, мої рекомендації полягають у наданні переваги ОЗУ над IO, а потім процесором. Писати інтенсивні навантаження вимагають хорошого IO, але найважливішим фактором для вашого бюджету є те, що процесори вимагають додаткових витрат на ліцензування. Ви розглядали цей аспект?
Ремус Русану

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 буде ще кращим. Якщо ви подумаєте над цим, все це може бути зменшено до (теоретичної) пропускної здатності. Ваша комбінація [(швидкість оперативної пам’яті + розмір оперативної пам’яті + контролер пам’яті пам’яті) до CPU] має обмеження пропускної здатності, яке було б найважливішим фактором операцій зчитування, коли ваші дані повинні завжди кешуватися, ваш конкретний (RAID) сховище має обмеження пропускної здатності ( впливає на зчитування, коли кеш пропущено, і записування під час промивання або коли багато клієнтів записують багато даних разом).

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

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

Файл журналу також використовується деякими серверами реплікації бази даних, але більшість реплікацій не відбувається моментально, але часто, тому вплив на продуктивність читання тут мінімальний. Принаймні я так думаю. Я зробив мінімальний бенчмаркінг, роблячи це оновлення ще раз, рекомендую кожному спочатку орієнтирам їх різних конфігурацій і спочатку оновити сховище, потім оперативну пам’ять та мережеве посилання, перш ніж замислюватися над оновленням своїх процесорів.

Після більш широких оновлень більш ніж на 5 серверах я повернувся, щоб поділитися своїм досвідом. Я, безумовно, все ще виступаю за те, щоб спочатку оновити накопичувач, потім оперативну пам’ять, а потім процесор. Причина - це невідповідність пропускної здатності в системі між накопичувачем, оперативною пам’яттю та процесором у порядку від найнижчого до найвищого. Тому я оновив купу серверів з RAID10 та подвійних RAID1 на SSD.

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

Тому я в основному спостерігав у 10-15 разів швидший час відповідей на деякі найдовші запити. SSD чудово підходить для швидкого зчитування даних в оперативній пам’яті, оскільки SQL Server не вносить дані в оперативну пам’ять, доки не вимагається, і, звичайно, дані спочатку потрібно завантажувати в оперативну пам’ять, щоб обробити процесор (пізніше, в кеш-пам'ять L1, L2, L3) , тож SSD допомагають скоротити цей початковий час очікування величезним фактором. А також жорсткі диски також допомагають скоротити час заміни ... очищення оперативної пам’яті та завантаження нових даних, особливо якщо ваша база даних більша, ніж може вміститися в оперативній пам’яті.

Загалом, ми дуже задоволені і працювали так на протязі декількох місяців у вигляді повільного процесу міграції, щоб сервери могли працювати, щоб я міг збирати інформацію про рівень зносу, перш ніж переключити всі мої сервери на цю конфігурацію. І це просто SQL Server Express! : D - Просто переконайтеся, що ваші SSD можуть надавати постійні IOPS, тому що це ще одна річ, яка робить величезну різницю (просто google це). Ось чому я вибрав SSD серії Intel DC (DataCenter).


0

Дещо не відповідь, яку ви, мабуть, шукаєте в першій частині, але: чи ви думали про те, щоб натиснути на хмару? AWS може дозволити вам забезпечити більшість потреб вище та розширити купівельну спроможність, не маючи при цьому справу з обладнанням.

Друга частина - апаратне забезпечення дійсно залежить від завдань. Я схильний схилятися до більшої кількості процесорів, коли мені вдається виконати індивідуальну інтеграцію CLR, оскільки тоді я можу оптимізувати справді паралельні рішення проблем. Більшу частину часу, хоча якщо краще встановити рішення, я вважаю, що оперативна пам’ять і швидкість жорсткого диска є найбільшим вузьким місцем, а другий, здається, є вашим випадком. (Де ідея SSD була б корисною)

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


1
Людина, ти коли-небудь дивився на ВАРТІСТЬ цього? Погодинна ставка на приховання є страховою, коли ви працюєте 24/7. Пропускна здатність для збільшення великих даних та завантажень є божевільною. Витрати на 1 Гбіт - навіть не говорячи про 10 Гбіт - Інтернет, щоб мати порівнянне посилання, коли потрібно переміщувати 50 Гб даних у базу даних та виходити з неї, божевільні. Хмара - це все приємно і весело, якщо ви (а) не використовуєте базу даних з локальних - тобто вона залишається в хмарі або (б) є маленькою.
TomTom

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