SMO, SSMS lambat untuk pengelolaan SQL Server di Docker saat tersambung ke localhost

TL; DR: Saat menghubungkan ke wadah SQL Server Docker saya melalui nama yang memutuskan untuk loopback IPv6 ( ::1), panggilan SMO sangat lambat. Saat digunakan 127.0.0.1, mereka cepat.

Saya mencoba mempelajari cara menggunakan image Docker microsoft / mssql-server-windows-developer . Per dokumentasi Microsoft, wadah ini hanya memperlihatkan port 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

Saya menjalankan wadah pada Windows 10, dan telah berhasil memulainya, mengautentikasi dengan otentikasi SQL Server, dan menjalankan kueri terhadap contoh menggunakan sqlcmd dan SSMS 17.4 pada host windows (menghubungkan ke localhost atau "."), Dan Operasi SQL Studio di mac di sebelah yang terhubung dengan IP. Saya tidak melihat masalah kinerja yang nyata saat menjalankan kueri dengan cara ini.

Dalam SSMS, saya juga dapat menelusuri objek explorer, tetapi jika saya mencoba melakukan sesuatu dari menu klik kanan pada objek di objek explorer, seperti membuka jendela parameter contoh atau melampirkan database, SSMS tidak menunjukkan respons sekitar 5 -10 menit, pada saat itu ia menampilkan jendela yang saya minta, atau menampilkan pesan kesalahan ini:

Saya juga mencoba melakukan beberapa skrip PowerShell terhadap instance ini menggunakan objek SMO Scripter , dan melihat perilaku yang sama. Script PS loop melalui objek dalam database dan skrip mereka untuk file, dan sementara ia bekerja untuk mengumpulkan daftar objek relatif cepat, masing-masing objek individu membutuhkan 5-10 menit untuk script - terlalu lambat untuk dapat digunakan.

Saya punya firasat bahwa port terbuka tunggal tidak cukup dan bahwa SMO dan SSMS mencoba untuk terhubung dengan cara yang sama yang memperlambat mereka. Mungkinkah juga saat terhubung ke localhost, alat-alat ini mengasumsikan ada saluran komunikasi lain yang biasanya tidak firewall? Apakah ada parameter koneksi tambahan yang bisa saya gunakan? Adakah yang bisa memvalidasi asumsi saya bahwa SSMS menggunakan SMO atau sesuatu yang lain untuk berbicara dengan SQL Server?

UPDATE: Saya masih menyelidiki, tetapi masuk akal bahwa ini adalah masalah Docker seputar kendala sumber daya. Ini membingungkan karena sebagian besar dokumentasi tampaknya menunjukkan bahwa Wadah Windows tidak memiliki kendala sumber daya default (dan ini tidak dapat diatur di Docker untuk Windows GUI - hanya untuk wadah Linux ), tetapi tampaknya pada kenyataannya, Windows kontainer yang berjalan pada Windows 10 mendapatkan alokasi RAM default 1GB. Saya masih mencoba mencari cara untuk memeriksa wadah yang sedang berjalan untuk melihat alokasi RAM dan CPU-nya, tetapi selanjutnya saya harus mencoba meningkatkannya dari apa pun defaultnya, menggunakan docker runparameter.

PEMBARUAN LEBIH LANJUT: Saya telah gagal mendapatkan segala jenis metrik yang dapat diandalkan dari buruh pelabuhan yang memberi tahu saya apa batas CPU dan memori yang ada untuk wadah. Memvariasikan penelitian menunjukkan bahwa kedua wadah buruh pelabuhan tidak memiliki batas memori secara default, atau yang mereka lakukan dan itu 1GB, tetapi semua saya dapat memverifikasi saat ini adalah bahwa docker statsmengatakan wadah SQL hanya menggunakan antara 750 dan 850 mcg, dan ketika Saya mencoba menambahkan run parameter untuk mengatur memori yang tersedia menjadi 4 gb, itu keluar kesalahan. Jadi saya berhenti mengikuti utas pertanyaan itu dan pergi untuk pemeriksaan usus yang berbeda: memasuki sesi powerhell interaktif pada wadah berjalan dan kemudian memanggil skrip powershell saya yang terhubung di atas dari dalam wadah.

Berlari ke dalam wadah tidak ada masalah. Itu berkobar melalui 2.780 objek hanya dalam beberapa menit. Saya pikir ini menegaskan bahwa masalahnya adalah dengan batas kontainer / host, jadi saya akan melihat apakah saya dapat membuka port UDP itu. PEMBARUAN: Membuka port 1434 UDP tidak membantu.

LEBIH BANYAK PEMBARUAN — Solusinya Dicapai, Bukan masalah keterbatasan sumber daya: Tampaknya ada masalah yang terkait dengan pengaturan alokasi memori yang besar untuk wadah windows - Saya menerima kesalahan serupa untuk 3g dan 2g, tetapi akhirnya bisa memulai wadah dengan 1.5g, dan Saya tidak melihat perbedaan dalam docker statsuntuk wadah yang (saya pikir) mengkonfirmasi sedang berjalan dengan alokasi default 1GB. Pada pengaturan default, stat PRIV WORKING SET (yang saya tidak dapat menemukan dokumentasi untuk apa, tapi tebakan terbaik saya adalah RAM) adalah antara 700MiB dan 850MiB. Dengandocker run —memory="1.5g"set, sekitar 1.0GiB. Jadi memang memperluas, tetapi tampaknya meninggalkan lebih banyak alokasi gratis daripada sebelumnya. Saya menafsirkan ini (mungkin salah) berarti bahwa server ini (yang berjalan benar-benar tanpa beban dan tidak memiliki database pengguna) tidak berada di bawah tekanan memori. Saya memeriksa pengaturan memori server maks untuk mengonfirmasi bahwa pengaturannya diatur pada maksimum 2PiB.

Kemudian semuanya menjadi aneh. Saya masih menguji berbagai hal dengan menjalankan skrip PowerShell saya dari berbagai lokasi. Cepat di dalam wadah, lambatkan tuan rumah. Kemudian saya RDP ke mesin windows lain di jaringan, dan menjalankan skrip dari mesin ITU, menghubungkan ke host Windows 10 saya dengan IP. Dan itu CEPAT! Ini tampaknya mendukung teori bahwa ketika menghubungkan ke sesuatu yang seharusnya menjadi localhost, SMO sedang mencoba untuk menyambung ke SQL Server menggunakan sesuatu selain port 1433 TCP, yang menunggu waktu yang sangat lama sebelum jatuh kembali ke koneksi TCP.

Saya memutuskan untuk mencoba memvalidasi teori ini dengan memasukkan entri file host untuk merujuk ke localhost dengan nama selain localhost:

        127.0.0.1       dockersucks

Saya terhubung dalam SSMS ke buruh pelabuhan bukannya localhost atau ".", Dan segera segalanya lebih cepat. Menavigasi objek explorer seperti biasa, dan membuka panel seperti melampirkan database atau properti server terjadi secepat biasanya. Dan, ketika saya menjalankan skrip PowerShell saya dari host windows 10 menggunakan alias ini sebagai nama server, itu juga cepat.

Saya menambahkan pembaruan ini ke pertanyaan alih-alih jawaban karena saya masih mencari penjelasan mengapa ini terjadi, dan jika ada cara untuk memperbaikinya untuk koneksi ke "localhost" dengan nama itu.

Ini kemungkinan besar adalah masalah kelaparan RAM.

Hal-hal yang perlu diperiksa:

• Apakah wadah memiliki 4 GB RAM yang ditetapkan untuknya? Periksa jawaban ini .
• Sudahkah Anda mengonfigurasi pengaturan Memori Server Max untuk SQL Server di dalam wadah? Bergantung pada seberapa banyak RAM yang dapat dilihat SQL Server dalam wadah, ini dapat diatur ke apa saja dari 1 GB hingga 3,25 GB.
• Apakah RAM host Anda sudah habis, dan apakah mungkin Docker melakukan paging ke disk? Tutup semua aplikasi luar (browser web adalah konsumen besar RAM). SSMS membutuhkan sekitar 1 GB RAM yang berfungsi agar dapat digunakan.
• Apakah ini lebih cepat setelah reboot?

Jika saya melakukan ini sendiri, saya akan menginstal Edisi Komunitas Docker untuk Windows dari toko Docker , dan kemudian menginstal gambar SQL Server Docker seperti itu.

Jika koneksi internet Anda cukup cepat, Anda dapat menghidupkan dan menjalankannya dalam waktu kurang dari 5 menit, dan dapat mengalokasikan sumber daya dengan cara yang jauh lebih mudah.

EDIT: Ah, jaringan.

Perbedaan utama di sini adalah apakah SSMS / SMO berusaha untuk terhubung dengan IPv4 atau IPv6. Jika Anda melakukan ping localhostdalam prompt perintah, Anda harus melihatnya menyelesaikan ::1, yang setara dengan IPv6 127.0.0.1. Menghubungkan ke .melakukan hal yang sama.

docker runPerintah Anda hanya memperlihatkan port 1433 pada 127.0.0.1. Anda dapat memverifikasi ini dengan menjalankan netstat -auntuk melihat port mana yang tersedia.

File host hosts yang Anda buat langsung diselesaikan 127.0.0.1, tetapi Anda tidak memerlukannya, karena Anda dapat terhubung 127.0.0.1langsung ke SSMS dan menyelesaikan masalah Anda dengan cara itu. Mematikan IPv6 sepenuhnya pada sistem host Anda mungkin juga akan berfungsi, tetapi saya tidak yakin seberapa disarankan ini pada Windows 10.

Saya akan mempertimbangkan jawaban alternatif untuk menerima jika ada yang bisa memberi tahu saya mengapa IPv6 menyebabkan ini rusak.