... надеялся, что смогу получить ... грубую приблизительную оценку того, что мы должны бежать.
Без дополнительной информации о ваших запросах и размерах данных очень сложно дать какую-либо оценку, не говоря уже о точной оценке.
База данных: SQL Server 2008 R2 база данных предприятия
Windows: Windows 2008 r2 Enterprise 64-битная, почти наверняка работает на VMware.
Процессор: Intel (R) Xeon (R) CPU E7-4860 @ 2,27 ГГц, 2,26 ГГц (2 процессора)
Установленная память: 4 ГБ
Два процессора (я предполагаю, что в ВМ они выставлены как 2 ядра) могут быть или не быть недостаточно обеспечены. Ядра, назначенные виртуальной машине, не обязательно отображаются непосредственно на физические ядра (или даже разрешено использовать 100% одного ядра, когда это необходимо!), Поэтому вы можете обнаружить, что это более гибкий ресурс, чем память. Без дополнительной информации о вашей рабочей нагрузке или конфигурации оборудования / виртуализации, я бы сказал, что было бы неплохо увеличить ее до 4.
Выделение памяти. О, парень. Это крайне недостаточно для рабочей нагрузки. Сама Windows требует минимум 2-3 ГБ, чтобы оставаться довольным, и каждому из 2 пользователей, использующих BIDS на коробке, потребуется по крайней мере 500 МБ каждый. И с этим коробка уже исчерпана, и я даже не начал выяснять, сколько понадобится базе данных .
Большинство пользователей взаимодействуют с базой данных через веб-сайт asp.net и веб-сайт сервера отчетов.
Вы не сказали, но если они работают на одном и том же устройстве, необходимо учитывать требования к памяти для них.
Наконец, у нас довольно сложная операция хранилища данных, которая, вероятно, приносит 3 миллиона записей в день с помощью пакетов служб SSIS, которые также запускаются на сервере.
Предполагая, что это происходит ночью, когда в системе нет активных пользователей, я не вижу в этом проблемы, если для запуска не требуется слишком много времени. Эта часть вещей меньше всего беспокоит вас; живые пользователи важнее.
Наши предыдущие запросы на дополнительную память были отклонены с общим ответом, что нам нужно выполнить больше оптимизаций запросов.
Как я продемонстрировал выше, текущий объем выделенной памяти совершенно неадекватен. В то же время, однако, на другом конце спектра крайне маловероятно, что вы сможете получить достаточно памяти, чтобы иметь возможность хранить всю базу данных в памяти сразу.
Даже несмотря на то, что вы получили общий ответ, подобный этому (который, кстати, скорее всего, был связан с тем, насколько убедительным было ваше обоснование дополнительных ресурсов, а не фактическое использование самих ресурсов), весьма вероятно, что эффективность базы данных может быть улучшенный. Тем не менее, нет одной лишь настройки, которая может решить проблемы, которые вы испытываете сейчас; предложение о том, что для меня это совсем не начало.
Я бы использовал общий подход, согласно которому объем выделяемой памяти ниже требуемого минимума (который должен быть скорректирован как можно скорее), и могут потребоваться дополнительные ресурсы, чтобы повысить удобство использования до приемлемого уровня, в то время как сделаны улучшения для повышения эффективности системы.
Вот несколько мыслей (в порядке атаки):
Вы выиграете, если сможете доказать, насколько улучшается производительность каждый раз, когда вы получаете больше ресурсов. Отслеживайте показатели производительности с помощью ведения журнала Performance Monitor (примечание: часть ведения журнала очень важна), включая время отклика веб-сайта, если это возможно. Начните делать это сейчас , прежде чем делать что-либо еще. Когда вы, наконец, доберетесь до минимального объема памяти (вы не собираетесь сразу получить 32 ГБ), вдруг у вас появятся доказательства того, что добавленная память улучшила вещи ... что означает, что добавление еще большего объема памяти, вероятно, тоже поможет! Если вы не соберете базовый уровень в текущей конфигурации, вы пропустите лодку, когда все поднимется до минимального рекомендуемого уровня.
Проанализируйте статистику ожидания вашего сервера . Это скажет вам, какое самое большое узкое место в системе. Вероятно, у вас будет PAGEIOLATCH_XXсамое распространенное / максимальное время ожидания, которое указывает на то, что слишком много операций ввода-вывода выполняется для извлечения страниц с диска. Это можно облегчить, добавив память, поэтому физические операции ввода-вывода становятся менее частыми, поскольку необходимые данные уже находятся в памяти. Хотя этот анализ в значительной степени предрешен, тот факт, что вы собрали эти статистические данные, дает больше боеприпасов при обосновании необходимости в ресурсах.
Как я уже упоминал выше, минимальное требование к памяти не выполняется. Соберите набор рекомендуемых аппаратных требований для всего программного обеспечения, которое вы используете, и, возможно, также сделайте скриншоты диспетчера задач. Одного этого должно быть достаточно, чтобы оправдать как минимум еще 4-8 ГБ на месте. Если они по-прежнему отказываются, попробуйте убедить их позволить вам опробовать его в течение недели, а затем верните его (вы собираете статистику производительности, поэтому вам не нужно будет возвращать ее, потому что в середине недели вы '' смогу доказать насколько это улучшило ситуацию). Если они все еще отказываются, вы настроены потерпеть неудачу; URLT .
Если вы можете разгрузить часть рабочей нагрузки (в частности, избегать удаленного взаимодействия, если это вообще возможно), это увеличит объем памяти, доступный для базы данных, что является более критичным.
Вы не сможете разместить всю базу данных в памяти сразу, а это значит, что вам нужно очень осторожно установить максимальный объем памяти в SQL Server, чтобы предотвратить перерасход памяти , который, как ничто другое , снижает производительность . Чрезмерная фиксация на самом деле даже хуже, чем просто невозможность разместить все данные в памяти. Весьма вероятно, что вы находитесь в этом сценарии прямо сейчас, просто потому, что памяти вообще нет, и вполне вероятно, что для параметра max memory установлено значение по умолчанию (неограниченное).
Поскольку вы работаете с SQL Server Enterprise Edition, а объем памяти ограничен, я настоятельно рекомендую реализовать сжатие данных . Это компенсирует увеличение использования ЦП для экономии места в памяти (и, следовательно, уменьшает доступ к диску, который сравнительно очень медленный).
Настройте базу данных. Вероятно, структуры и запросы могут использовать улучшения в том, что касается индексации и шаблонов доступа. Кроме того, если много данных часто сканируется и агрегируется, создание индексированных представлений, сводных таблиц или предварительно вычисленных отчетов может быть очень полезным.
Это может быть длинным, потому что это, вероятно, означает больше аппаратного обеспечения, но реализовать решение для кэширования. Самый быстрый запрос - тот, который вы никогда не делаете .
Это всего лишь несколько идей. Суть в том, что настройка сама по себе не решит проблемы, как и аппаратное обеспечение, хотя последнее, вероятно, облегчит большинство неотложных проблем. Вот как это происходит: бросьте аппаратное обеспечение на проблему в краткосрочной перспективе, чтобы потушить пожар, и бросьте настройку на проблему в долгосрочной перспективе, чтобы как можно лучше устранить первопричину.