SQL HW к соотношению производительности - PullRequest
1 голос
/ 18 ноября 2010

Я ищу способ найти узкие места в SQL-сервере, и кажется, что более 32 ГБ ОЗУ и более 32 спинделов на 8 ядер недостаточно Существуют ли какие-либо метрики, лучшие практики или сравнения HW (то есть транзакций в секунду)? Наше ежедневное закрытие занимает часы, и я хочу, чтобы это было в минутах или в реальном времени, если это возможно. Мне не удалось объединить более 12 тысяч строк в секунду. На данный момент мне пришлось разделить трафик более чем на один сервер, но является ли это правильным решением для ~ 50 ГБ базы данных? Слияние заключено в SP и поддерживается настолько простым, насколько это возможно - дедупликация ввода, вставка новых строк, обновление существующих строк. Я обнаружил, что чем больше строк мы объединяем, тем больше строк в секунду мы получаем. Сервер приложений работает в большем количестве потоков и использует всю память и процессор на своем выделенном сервере.

Ответы [ 2 ]

3 голосов
/ 18 ноября 2010

Следуйте методологии, подобной Ожидания и очереди , чтобы выявить узкие места.Это точно , для чего предназначен.После того, как вы определили узкое место, вы также можете судить, является ли проблема предоставления оборудования и калибровки (и если да, то , какое оборудование является узким местом), или если что-то еще.

0 голосов
/ 19 декабря 2010

Основная идея - избежать произвольного доступа к диску, как для чтения, так и для записи.Без какого-либо анализа для базы данных объемом 50 ГБ требуется как минимум 50 ГБ оперативной памяти.Затем вы должны убедиться, что индексы находятся на отдельном шпинделе от данных и журналов транзакций, вы пишете как можно позже, а критические таблицы разбиваются на несколько шпинделей.Ты все это делаешь?

...