TL; DR: Khi kết nối với bộ chứa Docker SQL Server của tôi thông qua một tên phân giải thành vòng lặp IPv6 ( ::1), các cuộc gọi SMO rất chậm. Khi sử dụng 127.0.0.1, chúng rất nhanh.
Tôi đang cố gắng học cách sử dụng hình ảnh Docker microsoft / mssql-server-windows-developer . Theo tài liệu của Microsoft, container này chỉ hiển thị cổng 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-developerTôi đang chạy container trên Windows 10 và đã khởi động thành công, xác thực bằng xác thực SQL Server và chạy các truy vấn đối với trường hợp sử dụng sqlcmd và SSMS 17.4 trên máy chủ windows (kết nối với localhost hoặc mật. Studio trên máy mac bên cạnh kết nối bằng IP. Tôi thấy không có vấn đề hiệu suất đáng chú ý khi chạy truy vấn theo cách này.
Trong SSMS, tôi cũng có thể duyệt trình thám hiểm đối tượng, nhưng nếu tôi cố gắng làm gì đó từ menu chuột phải trên một đối tượng trong trình thám hiểm đối tượng, như mở cửa sổ tham số phiên bản hoặc đính kèm cơ sở dữ liệu, SSMS không hiển thị phản hồi trong khoảng 5 -10 phút, tại thời điểm đó, nó sẽ hiển thị cửa sổ tôi yêu cầu hoặc hiển thị thông báo lỗi này:
Tôi cũng đang cố gắng thực hiện một số kịch bản PowerShell chống lại trường hợp này bằng cách sử dụng đối tượng Scripter SMO và xem loại hành vi tương tự. Tập lệnh PS lặp qua các đối tượng trong cơ sở dữ liệu và tập lệnh chúng để tập tin, và trong khi nó hoạt động để thu thập danh sách các đối tượng tương đối nhanh chóng, mỗi đối tượng riêng lẻ mất 5-10 phút để tập lệnh quá chậm để có thể sử dụng.
Tôi có linh cảm rằng cổng tiếp xúc duy nhất là không đủ và SMO và SSMS đang cố gắng kết nối theo cách tương tự đang làm chậm chúng. Cũng có thể là khi kết nối với localhost, các công cụ này cho rằng có các kênh liên lạc khác hiện tại thường không được tường lửa? Có bất kỳ tham số kết nối bổ sung nào tôi có thể sử dụng không? Bất cứ ai cũng có thể xác nhận giả định của tôi rằng SSMS đang sử dụng SMO hoặc một cái gì đó khác để nói chuyện với SQL Server?
CẬP NHẬT: Tôi vẫn đang điều tra, nhưng có thể đây là vấn đề Docker xung quanh các hạn chế tài nguyên. Điều này gây nhầm lẫn bởi vì hầu hết các tài liệu dường như chỉ ra rằng Windows Container không có bất kỳ ràng buộc tài nguyên mặc định nào (và chúng không thể được đặt trong Docker cho Windows GUI - chỉ dành cho các container Linux ), nhưng có vẻ như trong thực tế, Windows các container chạy trên Windows 10 có phân bổ RAM mặc định là 1GB. Tôi vẫn đang cố gắng tìm ra cách kiểm tra một container đang chạy để xem phân bổ RAM và CPU của nó, nhưng tiếp theo tôi phải thử tăng chúng từ bất kỳ giá trị mặc định nào, sử dụng docker runtham số.
CẬP NHẬT THÊM: Tôi đã không nhận được bất kỳ loại số liệu đáng tin cậy nào ra khỏi docker cho tôi biết CPU và bộ nhớ giới hạn nào có trong bộ chứa. Nghiên cứu khác nhau chỉ ra rằng các bộ chứa docker không có giới hạn bộ nhớ theo mặc định, hoặc chúng có và 1GB, nhưng tất cả những gì tôi có thể xác minh tại thời điểm đó là docker statsbộ chứa SQL chỉ sử dụng từ 750 đến 850 meg và khi nào Tôi cố gắng thêm một tham số chạy để đặt bộ nhớ khả dụng lên 4 gb, nó bị lỗi. Vì vậy, tôi đã dừng theo dõi chuỗi điều tra đó và đi kiểm tra ruột khác: nhập một phiên quyền hạn tương tác trên container đang chạy và sau đó gọi tập lệnh powershell của tôi được liên kết ở trên từ bên trong container.
Chạy bên trong container không có vấn đề gì. Nó thổi qua 2780 vật thể chỉ trong vài phút. Tôi nghĩ điều này xác nhận rằng vấn đề nằm ở ranh giới vùng chứa / máy chủ, vì vậy tôi sẽ xem liệu tôi có thể mở cổng UDP đó không. CẬP NHẬT: Mở cổng 1434 UDP không giúp được.
CẬP NHẬT THÊM CÂU HỎI THƯỜNG GẶP Đã đạt được, Không phải là vấn đề hạn chế tài nguyên: Dường như có vấn đề liên quan đến việc đặt phân bổ bộ nhớ lớn cho các bộ chứa windows - Tôi đã nhận được các lỗi tương tự trong 3g và 2g, nhưng cuối cùng đã có thể khởi động bộ chứa với 1,5g và Tôi DID thấy một sự khác biệt trong docker statscontainer cho (tôi nghĩ) xác nhận rằng nó đang chạy với phân bổ mặc định là 1GB. Trên cài đặt mặc định, chỉ số PRIV WORKING SET (mà tôi không thể tìm thấy bất kỳ tài liệu nào, nhưng tôi đoán tốt nhất là RAM) nằm trong khoảng từ 700MiB đến 850MiB. Vớidocker run —memory="1.5g"thiết lập, khoảng 1.0GiB. Vì vậy, nó đã mở rộng, nhưng dường như để lại nhiều phân bổ miễn phí hơn trước đây. Tôi giải thích điều này (có lẽ không chính xác) có nghĩa là máy chủ này (đang chạy hoàn toàn KHÔNG tải và KHÔNG có cơ sở dữ liệu người dùng) không chịu áp lực bộ nhớ. Tôi đã kiểm tra cài đặt bộ nhớ máy chủ tối đa để xác nhận rằng nó được đặt ở mức tối đa mặc định là 2PiB.
Sau đó, mọi thứ trở nên kỳ lạ. Tôi vẫn đang thử nghiệm mọi thứ bằng cách chạy tập lệnh powershell của mình từ nhiều địa điểm khác nhau. Nhanh chóng bên trong container, chậm trên máy chủ. Sau đó, tôi RDP'd đến một máy tính windows khác trên mạng và chạy tập lệnh từ máy THAT, kết nối với máy chủ Windows 10 của tôi bằng IP. Và nó đã NHANH CHÓNG! Điều này dường như ủng hộ lý thuyết rằng khi kết nối với thứ gì đó được coi là localhost, SMO đang cố gắng kết nối với SQL Server bằng cách sử dụng một cái gì đó ngoài cổng 1433 TCP, chờ một thời gian rất lâu trước khi quay lại kết nối TCP.
Tôi quyết định thử xác nhận lý thuyết này bằng cách nhập một mục nhập tệp máy chủ để tham chiếu localhost bằng một tên khác ngoài localhost:
127.0.0.1 dockersucksTôi đã kết nối trong SSMS với dockersucks thay vì localhost hoặc ".", Và ngay lập tức mọi thứ nhanh hơn. Điều hướng trình thám hiểm đối tượng giống như bình thường và việc mở các bảng như đính kèm cơ sở dữ liệu hoặc máy chủ xảy ra nhanh như bình thường. Và, khi tôi chạy tập lệnh powershell của mình từ máy chủ windows 10 sử dụng bí danh này làm tên máy chủ, nó cũng rất nhanh.
Tôi đã thêm bản cập nhật này vào câu hỏi thay vì câu trả lời vì tôi vẫn đang tìm lời giải thích tại sao điều này xảy ra và nếu có cách khắc phục nó cho các kết nối với "localhost" bằng tên đó.