У меня нет опыта работы с DBA, но я пытаюсь найти причину для запроса дополнительных ресурсов для нашего сервера sql и надеялся, что мне удастся заставить некоторых умных людей дать приблизительную приблизительную оценку того, что мы должны работать. Я подозреваю, что распределение ресурсов, выделенных ИТ на наш производственный сервер sql, невелико.
Аппаратное обеспечение:
База данных: SQL Server 2008 R2 база данных предприятия
Windows: Windows 2008 r2 Enterprise 64-битная, почти наверняка работает на VMware.
Процессор: Intel (R) Xeon (R) CPU E7-4860 @ 2,27 ГГц, 2,26 ГГц (2 процессора)
Установленная память: 4 ГБ
Жесткий диск для файлов базы данных: 300 ГБ
Жесткий диск для резервных копий: 150 ГБ
Жесткий диск для журналов: 100 ГБ
Заявка:
У нас есть 3 основные базы данных, которые составляют до 170 ГБ данных, база данных служб Reporting Services (SSRS) на том же сервере, на которой размещено, возможно, 10 различных отчетов (в среднем по 700 тыс. Записей каждая), которые генерируются ежедневно. Наша база пользователей насчитывает около 20 одновременных пользователей, может быть, 5 из них можно считать «ресурсоемкими» с созданием больших отчетов с перегрузкой данных. Большинство пользователей взаимодействуют с базой данных через веб-сайт asp.net и веб-сайт сервера отчетов. Кроме того, наши разработчики широко используют SSIS в BIDS, напрямую подключаясь к серверу (максимум 2 удаленных подключения). Наконец, у нас довольно сложная операция хранилища данных, которая, вероятно, приносит 3 миллиона записей в день с помощью пакетов служб SSIS, которые также запускаются на сервере.
Текущие проблемы:
У нас хронические тайм-ауты серверов, и время отклика на веб-сайт довольно плохое. Я подозреваю, что объем памяти (4 ГБ), вероятно, является узким местом. Наши предыдущие запросы на дополнительную память были отклонены с общим ответом, что нам нужно выполнить больше оптимизаций запросов. Хотя мы не являемся профессионалами в области SQL или (как я уверен, вы можете сказать по нашей настройке) профессионалами в области администрирования db, я хочу убедиться, что я не трачу все свое время, пытаясь выжать небольшую потенциальную производительность, если аппаратное обеспечение является узкое место.
Спасибо всем за избегание!
Ответы:
Без дополнительной информации о ваших запросах и размерах данных очень сложно дать какую-либо оценку, не говоря уже о точной оценке.
Два процессора (я предполагаю, что в ВМ они выставлены как 2 ядра) могут быть или не быть недостаточно обеспечены. Ядра, назначенные виртуальной машине, не обязательно отображаются непосредственно на физические ядра (или даже разрешено использовать 100% одного ядра, когда это необходимо!), Поэтому вы можете обнаружить, что это более гибкий ресурс, чем память. Без дополнительной информации о вашей рабочей нагрузке или конфигурации оборудования / виртуализации, я бы сказал, что было бы неплохо увеличить ее до 4.
Выделение памяти. О, парень. Это крайне недостаточно для рабочей нагрузки. Сама Windows требует минимум 2-3 ГБ, чтобы оставаться довольным, и каждому из 2 пользователей, использующих BIDS на коробке, потребуется по крайней мере 500 МБ каждый. И с этим коробка уже исчерпана, и я даже не начал выяснять, сколько понадобится базе данных .
Вы не сказали, но если они работают на одном и том же устройстве, необходимо учитывать требования к памяти для них.
Предполагая, что это происходит ночью, когда в системе нет активных пользователей, я не вижу в этом проблемы, если для запуска не требуется слишком много времени. Эта часть вещей меньше всего беспокоит вас; живые пользователи важнее.
Как я продемонстрировал выше, текущий объем выделенной памяти совершенно неадекватен. В то же время, однако, на другом конце спектра крайне маловероятно, что вы сможете получить достаточно памяти, чтобы иметь возможность хранить всю базу данных в памяти сразу.
Даже несмотря на то, что вы получили общий ответ, подобный этому (который, кстати, скорее всего, был связан с тем, насколько убедительным было ваше обоснование дополнительных ресурсов, а не фактическое использование самих ресурсов), весьма вероятно, что эффективность базы данных может быть улучшенный. Тем не менее, нет одной лишь настройки, которая может решить проблемы, которые вы испытываете сейчас; предложение о том, что для меня это совсем не начало.
Я бы использовал общий подход, согласно которому объем выделяемой памяти ниже требуемого минимума (который должен быть скорректирован как можно скорее), и могут потребоваться дополнительные ресурсы, чтобы повысить удобство использования до приемлемого уровня, в то время как сделаны улучшения для повышения эффективности системы.
Вот несколько мыслей (в порядке атаки):
Вы выиграете, если сможете доказать, насколько улучшается производительность каждый раз, когда вы получаете больше ресурсов. Отслеживайте показатели производительности с помощью ведения журнала Performance Monitor (примечание: часть ведения журнала очень важна), включая время отклика веб-сайта, если это возможно. Начните делать это сейчас , прежде чем делать что-либо еще. Когда вы, наконец, доберетесь до минимального объема памяти (вы не собираетесь сразу получить 32 ГБ), вдруг у вас появятся доказательства того, что добавленная память улучшила вещи ... что означает, что добавление еще большего объема памяти, вероятно, тоже поможет! Если вы не соберете базовый уровень в текущей конфигурации, вы пропустите лодку, когда все поднимется до минимального рекомендуемого уровня.
Проанализируйте статистику ожидания вашего сервера . Это скажет вам, какое самое большое узкое место в системе. Вероятно, у вас будет
PAGEIOLATCH_XXсамое распространенное / максимальное время ожидания, которое указывает на то, что слишком много операций ввода-вывода выполняется для извлечения страниц с диска. Это можно облегчить, добавив память, поэтому физические операции ввода-вывода становятся менее частыми, поскольку необходимые данные уже находятся в памяти. Хотя этот анализ в значительной степени предрешен, тот факт, что вы собрали эти статистические данные, дает больше боеприпасов при обосновании необходимости в ресурсах.Как я уже упоминал выше, минимальное требование к памяти не выполняется. Соберите набор рекомендуемых аппаратных требований для всего программного обеспечения, которое вы используете, и, возможно, также сделайте скриншоты диспетчера задач. Одного этого должно быть достаточно, чтобы оправдать как минимум еще 4-8 ГБ на месте. Если они по-прежнему отказываются, попробуйте убедить их позволить вам опробовать его в течение недели, а затем верните его (вы собираете статистику производительности, поэтому вам не нужно будет возвращать ее, потому что в середине недели вы '' смогу доказать насколько это улучшило ситуацию). Если они все еще отказываются, вы настроены потерпеть неудачу; URLT .
Если вы можете разгрузить часть рабочей нагрузки (в частности, избегать удаленного взаимодействия, если это вообще возможно), это увеличит объем памяти, доступный для базы данных, что является более критичным.
Вы не сможете разместить всю базу данных в памяти сразу, а это значит, что вам нужно очень осторожно установить максимальный объем памяти в SQL Server, чтобы предотвратить перерасход памяти , который, как ничто другое , снижает производительность . Чрезмерная фиксация на самом деле даже хуже, чем просто невозможность разместить все данные в памяти. Весьма вероятно, что вы находитесь в этом сценарии прямо сейчас, просто потому, что памяти вообще нет, и вполне вероятно, что для параметра max memory установлено значение по умолчанию (неограниченное).
Поскольку вы работаете с SQL Server Enterprise Edition, а объем памяти ограничен, я настоятельно рекомендую реализовать сжатие данных . Это компенсирует увеличение использования ЦП для экономии места в памяти (и, следовательно, уменьшает доступ к диску, который сравнительно очень медленный).
Настройте базу данных. Вероятно, структуры и запросы могут использовать улучшения в том, что касается индексации и шаблонов доступа. Кроме того, если много данных часто сканируется и агрегируется, создание индексированных представлений, сводных таблиц или предварительно вычисленных отчетов может быть очень полезным.
Это может быть длинным, потому что это, вероятно, означает больше аппаратного обеспечения, но реализовать решение для кэширования. Самый быстрый запрос - тот, который вы никогда не делаете .
Это всего лишь несколько идей. Суть в том, что настройка сама по себе не решит проблемы, как и аппаратное обеспечение, хотя последнее, вероятно, облегчит большинство неотложных проблем. Вот как это происходит: бросьте аппаратное обеспечение на проблему в краткосрочной перспективе, чтобы потушить пожар, и бросьте настройку на проблему в долгосрочной перспективе, чтобы как можно лучше устранить первопричину.
источник
Это безумие "счетчик бобов" аккаунта. 1100-2500 долларов, которые вы потратите на оперативную память, могут окупиться в течение недели !
Они получают тайм-ауты для 20 сотрудников, и 5 из них выполняют «ресурсоемкую» работу. Я полагаю, что их время недешевое, и некоторые из этих отчетов - те, которые любил бы начальник, не подписывающий зарплату. Это тонны потраченных впустую повторных передач и борьбы с разочарованием.
Объясните им, что они, вероятно, ищут 15-20 долларов США за ГБ для оперативной памяти. Объем 128 ГБ ОЗУ сейчас составляет примерно 2200-2500 долларов, а цены на ОЗУ в настоящее время немного выросли. Даже если материнская плата вашего сервера не может ее поддерживать (это было бы странно), тогда 64 ГБ будут стоить от 1100 до 1200 долларов (я только что проверил, и это качество памяти сервера от Dell без скидок). Даже 64 ГБ оперативной памяти могут иметь ОГРОМНОЕ отличие (особенно если мы избегаем сканирования больших таблиц).
Выясните, сколько времени потрачено впустую, и спросите их, стоит ли это 1100-2500 долларов. Если вы тратите всего 1100 долларов и получаете 64 ГБ оперативной памяти, избегайте сканирования таблиц на больших столах. Используйте больше дисков с индексами (если у вас есть задержка для его поддержки), чтобы избежать больших дампов сканирования памяти.
источник
Я бегу 2008 R2 с 46 ГБ ОЗУ. Нет виртуальных машин. SQL Server 2008
Базы данных около 300 ГБ.
Я недавно положил базы данных на твердотельный накопитель и утроил вывод данных.
Сервер в настоящее время использует 45 ГБ оперативной памяти и работает нормально.
Рейды FC Sata и SAS SCSI. Всего 26 логических дисков. 144 прядильные диски.
Вчера я использовал только 24 ГБ оперативной памяти, когда у меня было только 50 ТБ заполненных жестких дисков и для передачи данных. Сегодня у меня 160TB полных жестких дисков, и я использую 45 ГБ оперативной памяти.
Мое приложение не использует более 400 МБ оперативной памяти.
Я подозреваю, что вам нужны базы данных на быстром твердотельном или оперативном диске. В принципе, хотя вам нужно гораздо больше оперативной памяти.
источник