TL; DR: Під час підключення до мого контейнера Docker SQL Server через ім'я, яке вирішує цикл IPv6 ( ::1), дзвінки SMO дійсно повільні. Під час використання 127.0.0.1вони швидкі.
Я намагаюся навчитися використовувати Docker image 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 Operations Студія на сусідньому комп'ютері, підключений по IP. Я не бачу помітних проблем із ефективністю при виконанні запитів таким чином.
У SSMS я також можу переглядати провідник об’єктів, але якщо я спробую зробити щось із меню правої кнопки миші на об'єкті в Explorer Explorer, наприклад відкрити вікно параметрів екземпляра або долучити базу даних, SSMS не відображає відповіді близько 5 -10 хвилин, після чого він або відображає вікно, про яке я попросив, або відображає це повідомлення про помилку:
Я також намагаюся зробити деякі сценарії PowerShell проти цього примірника, використовуючи об’єкт SMO Scripter , і побачити таку ж поведінку. Сценарій PS перебирає об'єкти в базі даних і скриптує їх до файлу, і, хоча він працює відносно швидко, збирає список об'єктів, кожен окремий об'єкт займає 5-10 хвилин для сценарію - занадто повільний, щоб бути корисним.
У мене є думка, що одного відкритого порту недостатньо, і що SMO та SSMS намагаються підключитися аналогічним чином, який уповільнює їх. Чи може бути так, що під час підключення до localhost ці інструменти припускають, що існують інші канали зв'язку, які, як правило, не підлягають фальшиві? Чи є якісь додаткові параметри з'єднання, які я міг би використовувати? Чи може хтось підтвердити моє припущення, що SSMS використовує SMO або щось інше, щоб поговорити з SQL Server?
ОНОВЛЕННЯ: Я все ще розслідую, але правдоподібно, що це проблема Докера навколо обмеження ресурсів. Це заплутано, оскільки більша частина документації вказує на те, що контейнери Windows не мають обмежень щодо ресурсів за замовчуванням (і їх не можна встановити в графічному інтерфейсі Docker for Windows - лише для контейнерів Linux ), але здається, що насправді Windows контейнери, що працюють на Windows 10, отримують за замовчуванням розподіл оперативної пам’яті 1 Гб. Я все ще намагаюся розібратися, як перевірити запущений контейнер, щоб побачити його оперативну пам’ять та розподілення процесора, але далі я повинен просто спробувати збільшити ті, які є за замовчуванням, використовуючи docker runпараметри.
ДУШЕ ОНОВЛЕННЯ: Мені не вдалося отримати з докера будь-яку надійну метрику, яка повідомляє мені, які обмеження процесора та пам'яті є у контейнера. Різні дослідження показують, що або докер-контейнери не мають обмеження пам’яті за замовчуванням, або що вони роблять, і це 1 Гб, але все, що я можу перевірити на даний момент, - це docker statsте, що кажуть, що контейнер SQL використовує лише від 750 до 850 мег, і коли Я намагаюся додати параметр запуску, щоб встановити доступну пам'ять до 4 ГБ, вона помиляється. Тож я перестав слідкувати за цією темою запиту та пішов на іншу перевірку кишок: ввівши інтерактивний сеанс оболонки повноважень на запущеному контейнері, а потім викликав мій скрипт повноважень, пов'язаний вище зсередини контейнера.
Пробігаючи всередині контейнера, проблем не було. Він промайнув через 2780 об’єктів всього за пару хвилин. Я думаю, це підтверджує, що проблема полягає в межі контейнера / хоста, тому я перегляну, чи зможу я відкрити цей порт UDP. ОНОВЛЕННЯ: Відкриття порту 1434 UDP не допомогло.
БІЛЬШЕ ОНОВЛЕННЯ - Досягнуто вирішення, не проблема з обмеженням ресурсів: Можливо, виникають проблеми, пов’язані із встановленням великих розмірів пам'яті для контейнерів Windows - я отримував подібні помилки для 3g та 2g, але в кінцевому підсумку вдалося запустити контейнер з 1,5g, і Я DID бачив різницю в docker statsконтейнері, що (я думаю) підтверджує, що він працює з виділенням за замовчуванням 1 Гб. У налаштуваннях за замовчуванням статистика PRIV WORKING SET (для якої я не можу знайти жодної документації, але я найкраще здогадуюсь, що це оперативна пам'ять) становить від 700 Мбіт до 850 Мбіт. Зdocker run —memory="1.5g"встановити, це близько 1,0 Гбіт. Таким чином, він розширився, але, здається, залишає більшу частину виділення безкоштовно, ніж раніше. Я трактую це (можливо, неправильно), щоб означати, що цей сервер (який працює абсолютно без навантаження та не має баз даних користувачів) не знаходиться під тиском пам'яті. Я перевірив налаштування максимальної пам'яті сервера, щоб підтвердити, що він встановлений за замовчуванням максимумом 2PiB.
Тоді речі стали дивними. Я все ще тестую речі, запускаючи скрипт повноважень із різних місць. Швидко всередині контейнера, повільно на хості. Потім я RDP'd до іншої машини Windows в мережі, і запустив сценарій з цієї машини, підключившись до мого Windows 10 хостом по IP. І це було ШВИДКО! Це, мабуть, підтримує теорію, що під час підключення до чогось, що повинно бути localhost, SMO намагається підключитися до SQL Server за допомогою чогось іншого, ніж порт 1433 TCP, що чекає дуже тривалий час очікування, перш ніж повернутися до TCP-з'єднання.
Я вирішив спробувати перевірити цю теорію, ввівши запис файлу хостів, щоб посилатися на localhost іменем, відмінним від localhost:
127.0.0.1 dockersucksЯ підключився в SSMS до dockersucks замість localhost або ".", І відразу все пройшло швидше. Навігація за допомогою "Провідника об'єктів" була, як звичайно, і відкриття панелей на зразок прикріплення властивостей баз даних або сервера відбувалося так само швидко, як звичайно. І коли я запустив свій скрипт повноважень з хоста Windows 10, використовуючи цей псевдонім як ім'я сервера, це було також швидко.
Я додав це оновлення до питання замість відповіді, оскільки я все ще шукаю пояснення, чому це відбувається, і якщо є спосіб виправити це для підключення до "localhost" за цим ім'ям.