TL; DR: при подключении к контейнеру Docker SQL Server через имя, которое разрешается в loopback IPv6 ( ::1), вызовы SMO выполняются очень медленно. При использовании 127.0.0.1они быстрые.
Я пытаюсь узнать, как использовать образ Docker microsoft / mssql-server-windows-developer . Согласно документации Microsoft, этот контейнер предоставляет только порт 1433 TCP.
docker run -d -p 1433:1433 -e sa_password=Passw0rd! -e ACCEPT_EULA=Y -v C:\dockerdb:C:\dockerdb microsoft/mssql-server-windows-developerЯ запускаю контейнер в Windows 10 и успешно запускаю его, проверяю подлинность с помощью аутентификации SQL Server и выполняю запросы к экземпляру, используя sqlcmd и SSMS 17.4 на хосте Windows (подключение к localhost или «.»), И операции SQL Студия на Mac по соседству подключается по IP. Я не вижу заметных проблем с производительностью при выполнении запросов таким образом.
В SSMS я также могу просматривать обозреватель объектов, но если я пытаюсь что-то сделать из меню правой кнопки мыши на объекте в проводнике объектов, например открыть окно параметров экземпляра или присоединить базу данных, SSMS не показывает ответ около 5 -10 минут, после чего он либо отображает запрошенное мной окно, либо отображает это сообщение об ошибке:
Я также пытаюсь выполнить некоторые сценарии PowerShell для этого экземпляра, используя объект SMO Scripter , и вижу такое же поведение. Сценарий PS просматривает объекты в базе данных и записывает их в файл, и, хотя он работает для сравнительного быстрого сбора списка объектов, для создания сценария каждого отдельного объекта требуется 5-10 минут - слишком медленно, чтобы его можно было использовать.
Я догадываюсь, что одного незащищенного порта недостаточно, и что SMO и SSMS пытаются соединиться аналогичным образом, что замедляет их. Может ли быть так, что при подключении к локальному узлу эти инструменты предполагают наличие других каналов связи, которые, как правило, не защищены брандмауэром? Есть ли дополнительные параметры подключения, которые я мог бы использовать? Может ли кто-нибудь подтвердить мое предположение, что SSMS использует SMO или что-то еще для общения с SQL Server?
ОБНОВЛЕНИЕ: Я все еще исследую, но вполне вероятно, что это проблема Docker, связанная с ограниченностью ресурсов. Это сбивает с толку , потому что большая часть документации , кажется, указывает , что Windows , контейнеры не имеют каких - либо ограничений ресурсов по умолчанию (и они могут не быть установлены в Docker для графического интерфейса пользователя Windows - только для контейнеров Linux ), но мне кажется , что на самом деле, Windows контейнеры, работающие в Windows 10, по умолчанию выделяют 1 ГБ памяти Я все еще пытаюсь выяснить, как проверить работающий контейнер, чтобы увидеть его ОЗУ и распределение ЦП, но затем я должен просто попытаться увеличить их из значений по умолчанию, используя docker runпараметры.
ДОПОЛНИТЕЛЬНОЕ ОБНОВЛЕНИЕ: мне не удалось получить какой-либо надежный показатель из докера, который говорит мне, какие ограничения ЦП и памяти он имеет для контейнера. Варьируя исследование указывает на то, что либо Докер контейнеры не имеют ограничение памяти по умолчанию, или что они делают , и это 1 Гб, но все , что я могу проверить , на данный момент , что docker statsговорит SQL контейнер только с использованием между 750 и 850 мег, а когда Я пытаюсь добавить параметр запуска, чтобы установить доступную память на 4 ГБ, это ошибки. Поэтому я перестал следить за этим потоком запросов и пошел к другой проверке интуиции: входил в интерактивный сеанс powershell в работающем контейнере, а затем вызывал мой скрипт powershell, связанный выше, изнутри контейнера.
Запуск внутри контейнера не было проблемой. Всего за пару минут он пронзил 2780 объектов. Я думаю, это подтверждает, что проблема связана с границей контейнера / хоста, поэтому я собираюсь посмотреть, смогу ли я открыть этот порт UDP. ОБНОВЛЕНИЕ: Открытие порта 1434 UDP не помогло.
БОЛЬШЕ ОБНОВЛЕНИЙ — Обходной путь достигнут, не проблема с ограничением ресурсов: Кажется, есть проблемы, связанные с установкой больших выделений памяти для контейнеров Windows - я получал аналогичные ошибки для 3g и 2g, но в итоге смог запустить контейнер с 1,5g, и Я ДЕЙСТВИТЕЛЬНО видел разницу в docker statsконтейнере, который (я думаю) подтверждает, что он работает с выделением по умолчанию 1 ГБ. При настройках по умолчанию показатель PRIV WORKING SET (для которого я не могу найти никакой документации, но, скорее всего, это ОЗУ), составляет от 700 МБ до 850 МБ. Сdocker run —memory="1.5g"установить, это около 1,0 ГБ. Таким образом, он расширился, но, похоже, оставил больше свободных ресурсов, чем раньше. Я интерпретирую это (возможно, неправильно), чтобы означать, что этот сервер (который работает абсолютно без нагрузки и не имеет пользовательских баз данных) не находится под давлением памяти. Я проверил настройку max server memory, чтобы убедиться, что она установлена по умолчанию на максимум 2PiB.
Тогда все стало странно. Я все еще проверяю вещи, выполняя свой скрипт powershell из разных мест. Быстро внутри контейнера, медленно на хосте. Затем я перешел на другой компьютер с Windows в сети и запустил скрипт с ЭТОГО компьютера, подключившись к моему хосту Windows 10 по IP. И это было БЫСТРО! Похоже, что это подтверждает теорию, что при подключении к чему-то, что должно быть локальным, SMO пытается подключиться к SQL Server, используя что-то отличное от порта 1433 TCP, который ждет очень долгое время ожидания, прежде чем вернуться к TCP-соединению.
Я решил попробовать проверить эту теорию, введя запись в файле hosts для ссылки на localhost по имени, отличному от localhost:
127.0.0.1 dockersucksЯ подключился в SSMS к dockersucks вместо localhost или ".", И сразу все стало быстрее. Навигация по объекту проводника была обычной, и открытие панелей, таких как присоединение базы данных или свойств сервера, происходило так же быстро, как обычно. И когда я запустил свой скрипт powershell с хоста Windows 10, используя этот псевдоним в качестве имени сервера, он также был быстрым.
Я добавил это обновление к вопросу вместо ответа, так как я все еще ищу объяснение, почему это происходит, и есть ли способ исправить это для соединений с "localhost" с таким именем.