у нас есть база данных SQL среднего размера около 40 ГБ, и мы собираемся переместить ее в новую коробку с сервером 2008 r2 x64
дорогой подрядчик только что пришел и сказал, что нам нужно 72 ГБ оперативной памяти, чтобы вся БД могла жить в ОЗУ, я думаю ... Я нахожу это нелепым, но, возможно, я что-то упускаю.
Мне было интересно, есть ли «эмпирическое вычисление», которое намекает на достаточное количество оперативной памяти для использования в экземпляре SQL ..
РЕДАКТИРОВАТЬ: В DB одновременно работают до 150 человек, которые используются для запуска системы бронирования. очень неприятная старая схема БД, ужасное количество столбцов во многих таблицах, огромные массивы полубессмысленных индексов. Доступен .net, ударяя по некоторым sprocs, но также запрашивая необработанный sql и все, что использует VisualDataFlex.
Спасибо
нац
Нет хорошего практического правила.
Полезность дополнительной оперативной памяти во многом зависит от того, как спроектирована ваша база данных, а также от шаблонов запросов или ваших пользователей. В качестве крайнего примера, если у вас всего 1 ТБ данных, хорошая индексация и 1000 одновременных пользователей, которые когда-либо переходят только после одной конкретной строки (выберите * из dbo.BigTable, где pkey_id = 42), вы можете обойтись очень небольшим объемом оперативной памяти . Влияние увеличения объема оперативной памяти также может зависеть от скорости вашей дисковой подсистемы хранения. Если у вас сверхбыстрое хранилище ( хорошо SAN, хорошо DASD или SSD) вы можете не заметить отставание, когда серверу необходимо прочитать данные.
В идеале вам нужны все данные, которые хранятся в базе данных. вероятно понадобится в течение дня кешируется в ОЗУ. Иногда это называют «горячими данными» или «горячими страницами» (в SQL Server данные организованы в блоки, называемые «страницами»). Примером горячих данных могут быть заказы, принятые сегодня или вчера, которые потребуются работникам, отправляющим эти заказы. Примером холодных данных могут быть заказы, полученные два года назад, но они все еще существуют в системе, так что CSR могут искать старые заказы.
Благодаря хорошо спроектированной системе OLTP с общим объемом данных 40 ГБ (в отличие от файлов данных, которые в сумме составляют до 40 ГБ), возможно, что горячие данные будут достигать только 10 ГБ, 5 ГБ, 1 ГБ или даже меньше. . Раньше разница между покупкой только 64 ГБ ОЗУ и 8 ГБ (или даже меньше) была астрономической, и на получение нужного количества ОЗУ стоило потратить много времени.
Вы всегда хотите немного дополнительной оперативной памяти для «накладных расходов», таких как ОС, антивирусные сканеры, сеансы RDP. Вы также хотите принять во внимание рост базы данных.
Еще нужно иметь в виду, что оперативная память бывает «кусками». Вы не можете выбрать между 48 ГБ и 49 ГБ, вам нужно увеличить, вероятно, с 48 до 64 ГБ. Размер блока зависит от технологий оперативной памяти, продаваемых в настоящее время, и от количества каналов вашей памяти. У старых серверов было одно изменение памяти, затем на серверах было два, а теперь у большинства мощных серверов есть три канала памяти. Итак, вы не можете просто добавить одну палку, вам нужно добавлять две по три за раз.
Если у вас плохо спроектированная и плохо проиндексированная база данных, как вы говорите, SQL закончит чтение большого количества данных, которых он не должен был бы делать с более продуманной базой данных. Наличие всех этих данных в ОЗУ не означает, что он не считывает их все. Это просто означает, что он считывает все данные в ОЗУ быстрее, чем если бы данные находились на диске. Это не обязательно решит все ваши проблемы; чтение данных из ОЗУ происходит быстро, но все же занимает ограниченное время, и вы все равно можете столкнуться с проблемами блокировки и взаимоблокировки, которые могут вызвать проблемы с производительностью.
Другое дело, что больше оперативной памяти помогает, когда люди запускают в системе большие отчеты, в которых используются данные за прошлый год. Люди все время относятся к OLTP-системам как к системам отчетности. Это может быть не редкостью, особенно с случайными SQL-запросами.
Вы можете потратить время (и деньги) на разработчиков и тестировщиков, чтобы улучшить дизайн базы данных и внести любые изменения во внешний интерфейс, которые для этого потребуются.
Очень быстрое посещение hp.com показывает, что я могу получить (очень) урезанный сервер с 96 ГБ ОЗУ примерно за 9000 долларов США.
(Это менее 100 долларов США за ГБ без учета каких-либо других компонентов сервера. Такие компоненты, как блок питания или процессор. Старые люди, такие как я, помнят, когда объем оперативной памяти составлял 5000 долларов США за мегабайт. С M.)
Как быстро вы сможете потратить 9000 долларов США на разработку и тестирование? (По корпоративным тарифам в моем районе это вряд ли позволит вам получить одного человека за целый месяц.) Будет ли этого времени достаточно, чтобы исправить все в базе данных? Что если ошибка в измененном коде проскользнет?
Отключение сервера для добавления оперативной памяти может занять час, и почти каждый может выполнить эту работу. Миграция на совершенно новый сервер может занять пару дней подготовительной работы и час простоя, и вам понадобится кто-то с опытом (вероятно, администратор баз данных).
Добавление ОЗУ вряд ли вызовет какие-либо ошибки. Переход на новый сервер вряд ли вызовет какие-либо трудные для поиска проблемы. (Как правило, все работает или явно не работает. Обычно это «упс, неверный пароль» или «упс, забыл скопировать связанный сервер», но никогда «эй, этот расчет внезапно не работает правильно».)
Итак, предполагая, что мы собираемся хранить все в ОЗУ и у нас есть база данных на 40 ГБ, нам нужно немного места для накладных расходов. Я бы подумал о сервере с 48 ГБ или около того. Кроме того, нам нужно пространство для роста. Скажем так, рост на 25% отсюда, что составляет 12 ГБ, а у нас получается 60 ГБ. Следующий уровень (который я действительно могу купить) - 64 ГБ. Если ваш консультант рекомендует трехканальный сервер, следующий уровень может быть 72 ГБ. Так что его предложение не обязательно диковинное. Возможно, вам не нужно столько ядер / сокетов, и это может вернуть вас к двухканальному серверу (который в любом случае будет дешевле), и вы сможете купить немного меньше оперативной памяти.
TL; DR:
Короче говоря, что бывает редко, оперативная память стоит дешево, а время дорого. Если у вас нет денег, времени или желания исправить базу данных, или вы не хотите рисковать добавлением ошибок в свое приложение, то использование оперативной памяти для решения проблемы вызывает сомнения. Еще один хороший шаг - улучшить скорость отклика дисковой системы хранения (IOW, добавить больше шпинделей, больше оборотов в минуту или перейти на SSD).
Я бы спросил, почему консультант не хотел, чтобы вы потратили год и 100 000 долларов США, чтобы он переписал систему.