Мы использовали SQL Server Express - различные версии без проблем. Однако у нас есть установка на машину VMware, и есть серьезные проблемы с производительностью. Я связался с VMware и Microsoft - Microsoft явно не поддерживает Express как бесплатную версию. Проблема в том, что по мере увеличения базы данных разрыв в производительности между физической машиной и VMware становится намного больше. В настоящее время виртуальная машина примерно в 5 раз медленнее, чем физическая машина аналогичной спецификации с установкой SQL Server 2008 R2 Express 4 ГБ (ограничение 10 ГБ). Существует огромная служба VMware, занимающая более 1 ГБ из 3,5 ГБ памяти, доступной на виртуальной машине. Я ищу ресурсы, чтобы попытаться найти, можно ли улучшить производительность. Ссылки, комментарии очень ценятся.
Уровень гипервизора для доступа к диску не вызовет такой большой проблемы. Что делает виртуальная машина на сервере? Похоже, что это, вероятно, раздувает память и борется за RAM или CPU с другими ресурсами на вашем сервере VMware. Какую версию VMware вы используете? Насколько чрезмерно загружены ваша память и ресурсы процессора? У меня около 400 виртуальных машин с SQL-серверами, и они не испытывают проблем. Но я не слишком привязан к оперативной памяти.
В этом нет ничего удивительного. По многим традиционным меркам операционная система базы данных в этом случае является гостевой операционной системой, работающей поверх Windows. Когда он запускается, он немедленно захватывает кусок ОЗУ и кусок диска, которым SQL-сервер хочет управлять самостоятельно из соображений производительности. Как только вы попросите хост стать гостем в VMWARE, вы вводите еще один уровень арбитража в доступе к диску и памяти, связанный с производительностью SQL Server. Еще одна особенность гостевых операционных систем заключается в том, что они, как правило, имеют собственный естественный уровень консолидации для поддержания производительности. В случае с SQL Server, хотя и не обязательно с SQL Express, вы можете объединить несколько экземпляров базы данных на одном аппаратном обеспечении, тем самым поддерживая производительность и доступ к ресурсам для механизма базы данных и в то же время сокращая многие элементы затрат, которые являются движущей силой. виртуализация от высшего руководства.
Обратите внимание на то, что производительность ухудшается по мере добавления все большего количества данных, это означает, что у вас будет все больше доступа к диску для извлечения информации. Каждый из этих запросов должен быть обработан гипервизором до того, как он фактически попадет на диск, и чем больше доступ к диску, тем больше совокупный ущерб от всех этих микросекунд на задержку арбитража. Лучшее, что вы можете сделать в этом случае, - это изучить свои запросы. Убедитесь, что они гиперэффективны в производстве, что они используют индексы, когда и где это возможно, чтобы минимизировать активность сканирования таблиц (что обычно имеет место, когда время ответа напрямую связано с размером таблицы данных). Чем меньше запросов вы должны сделать к дисковой подсистеме, тем меньше возможностей будет у гипервизора для арбитража запросов и тем быстрее станет ваша система.
Если ваши данные растут довольно быстрыми темпами, вы захотите рассмотреть другие варианты в будущем, поскольку у вас, вероятно, закончится бензин из-за способности SQL Express обрабатывать все большие и большие наборы данных раньше, чем позже ... и обычно это происходит в неудобное время, когда вам нужно вынести вещи за дверь. Я думаю, что ограничение на SQL Express 2088 R2 составляет 10 ГБ. Не несущественный объем данных, но тот, который, кажется, легко превзойти в наши дни.
Вполне возможно, что наблюдаемая вами «огромная служба VMware» связана с раздутие памяти что может произойти в случае нехватки физической памяти на вашем хосте ESX. Наблюдаемые периоды полной загрузки системы, в то время как она ничего не делает, в свою очередь, вероятно, представляют собой время ожидания ввода-вывода подкачки на стороне хоста ESX. Пока ESX меняет местами страницы или выгружает их (опять же, из-за нехватки памяти), он останавливает гостя, оставляя только несколько циклов для фактической обработки.
Хорошо, поэтому vmWare не должно было использовать 1G3 - существует документированная утечка памяти из-за какого-то реентерабельного IP. Перезагрузка машины (в случае сомнений выключите ее и снова включите) устранила это. С другой стороны, SQL Express не должен занимать 3 ГБ. Согласно MS, это должен быть предел в 1 ГБ. Память SQL Express была (вручную) привязана к 786 МБ - мало? увеличение или уменьшение 256M казалось хуже, но изменения не были кардинальными, поэтому мы выбрали медианное значение. vmWare медленно увеличивается - до 89 МБ - началось с 10 МБ. Обратите внимание, что с SQL 2008 вы можете изменить объем памяти без перезапуска службы (SQL).