TL; DR: SQL Server Docker kapsayıcısına IPv6 geri döngüsüne ( ::1) çözümlenen bir adla bağlanırken SMO çağrıları gerçekten yavaş. Kullanırken 127.0.0.1, hızlılar.
Docker görüntüsü microsoft / mssql-server-windows-developer nasıl kullanılacağını öğrenmeye çalışıyorum . Microsoft'un belgelerine göre, bu kapsayıcı yalnızca 1433 numaralı TCP bağlantı noktasını açığa çıkarır.
docker run -d -p 1433:1433 -e sa_password=Passw0rd! -e ACCEPT_EULA=Y -v C:\dockerdb:C:\dockerdb microsoft/mssql-server-windows-developerKapsayıcıyı Windows 10'da çalıştırıyorum ve SQL Server kimlik doğrulamasıyla kimlik doğrulaması yapmayı ve Windows ana bilgisayarında sqlcmd ve SSMS 17.4 kullanarak yerel sunucuya (localhost veya “.” Bağlanıyor) sorguları çalıştırmayı ve SQL İşlemlerini başarıyla gerçekleştirdim. IP ile bağlanan bir mac yandaki Studio. Sorguları bu şekilde çalıştırırken belirgin bir performans sorunu görmüyorum.
SSMS'de, nesne gezgine de göz atabilirim, ancak örnek gezgini penceresini açmak veya bir veritabanı eklemek gibi, nesne gezginde bir nesne üzerinde sağ tıklama menüsünden bir şey yapmaya çalışırsam, SSMS yaklaşık 5 için bir yanıt göstermez -10 dakika, bu noktada istediğim pencereyi veya şu hata iletisini görüntüler:
Ayrıca SMO Scripter nesnesini kullanarak bu örneğe karşı bazı PowerShell komut dosyaları yapmaya çalışıyorum ve aynı tür davranış görmek. PS betiği, veritabanındaki nesneler arasında dolaşır ve bunları dosyaya yazar ve nesnelerin listesini nispeten hızlı bir şekilde toplamak için çalışırken, her bir nesnenin betiği 5-10 dakika sürer - kullanılamayacak kadar yavaştır.
Açıkta kalan tek portun yeterli olmadığı ve SMO ve SSMS'nin onları yavaşlatan benzer bir şekilde bağlanmaya çalıştıklarına dair bir önsezim var. Ayrıca, localhost'a bağlanırken, bu araçların genellikle güvenlik duvarı olmayacak başka iletişim kanalları olduğu varsayılabilir mi? Kullanabileceğim başka bağlantı parametreleri var mı? Herkes SSMS'nin SQL Server ile konuşmak için SMO veya başka bir şey kullandığını varsayımımı doğrulayabilir mi?
GÜNCELLEME: Hala araştırıyorum, ancak bunun kaynak kısıtlamaları ile ilgili bir Docker sorunu olması makul. Bu belgelerin çoğu Windows Konteynerleri herhangi bir varsayılan kaynak sınırlamaları yoktur belirtmek görünüyor çünkü kafa karıştırıcı (ve bunlar olabilir değil Windows GUI Docker ayarlanabilir - sadece Linux konteynerler için ), ancak gerçekte, Windows gibi görünüyor Windows 10 üzerinde çalışan kapsayıcılar varsayılan 1GB RAM ayırma alır. Hala çalışan bir kapsayıcıyı RAM ve CPU tahsisini görmek için nasıl inceleyeceğimizi anlamaya çalışıyorum, ama sonra sadece docker runparametreleri kullanarak, varsayılanları ne olursa olsun artırmayı denemeliyim .
DAHA FAZLA GÜNCELLEME: Docker'dan, kapsayıcı için hangi CPU ve bellek sınırlarının mevcut olduğunu söyleyen her türlü güvenilir metriği elde edemiyorum. Araştırma Değişen ya liman işçisi kapları, varsayılan olarak bir bellek sınırı olmadığını belirtir veya yaptıklarını ve 1GB, ama şu anda doğrulayabilir tüm yani docker statsSQL konteyner yalnızca diyor kullanılarak 750 ila 850 Meg ve ne zaman Kullanılabilir belleği 4 gb'ye ayarlamak için bir çalışma parametresi eklemeye çalışıyorum, hata veriyor. Ben soruşturma o iplik aşağıdaki durdu ve farklı bir bağırsak kontrolü için gitti Yani: çalışan kabın üzerine interaktif bir powershell oturumu giren ve sonra benim powershell komut yukarıda bağlantılı çağırarak iç kap.
Konteynerin içinde koşarken hiçbir sorun yoktu. Sadece birkaç dakika içinde 2780 nesneler arasında parladı. Sanırım bu sorunun kapsayıcı / ana bilgisayar sınırında olduğunu doğruladı, bu yüzden o UDP bağlantı noktasını açıp açamayacağımı göreceğim. GÜNCELLEME: 1434 UDP bağlantı noktasını açmak işe yaramadı.
DAHA FAZLA GÜNCELLEME — Geçici Çözüm Elde Edildi, Kaynak kısıtlaması sorunu değil: Windows kapsayıcıları için büyük bellek ayırmalarını ayarlama ile ilgili sorunlar var gibi görünüyor - 3g ve 2g için benzer hatalar alıyordum, ancak sonunda kapsayıcıyı 1.5g ile başlatabiliyordum ve docker stats(Sanırım) 1GB varsayılan ayırma ile çalıştığını doğruladı konteyner için bir fark gördüm. Varsayılan ayarlarda, PRIV WORKING SET stat (herhangi bir belge bulamıyorum, ama en iyi tahminim RAM) 700MiB ile 850MiB arasında. İledocker run —memory="1.5g"Set, 1.0GiB civarında. Bu yüzden genişledi, ancak tahsisin daha önce olduğundan daha fazla serbest bırakıldığı görülüyor. Bu (belki de yanlış) (kesinlikle NO yük çalıştıran ve NO kullanıcı veritabanları olan) bu sunucunun bellek baskısı altında olmadığı anlamına gelir. Maksimum sunucu belleği ayarını varsayılan maksimum 2PiB olarak ayarlandığını doğrulamak için kontrol ettim.
Sonra işler tuhaflaştı. Hala çeşitli konumlardan powershell betiğimi çalıştırarak işleri test ediyorum. Konteynerin içinde hızlı, ana bilgisayarda yavaş. Sonra ağdaki başka bir windows makinesine RDP'ledim ve komut dosyasını THAT makinesinden çalıştırdım, Windows 10 ana bilgisayarıma IP ile bağlandım. Ve HIZLI oldu! Bu, yerel ana bilgisayar olması gereken bir şeye bağlanırken, SMO'nun TCP bağlantısına geri dönmeden önce çok uzun bir zaman aşımı bekleyen 1433 TCP bağlantı noktası dışında bir şey kullanarak SQL Server'a bağlanmaya çalıştığı teorisini destekliyor gibi görünüyor.
Localhost dışında bir ad ile localhost başvurmak için bir hosts dosya girişi girerek bu teori doğrulamaya karar verdim:
127.0.0.1 dockersucksSSMS'de localhost veya "." Yerine dockersucks'a bağlandım ve hemen işler daha hızlıydı. Nesne gezgininde gezinmek her zamanki gibi oldu ve veritabanı ekle veya sunucu özellikleri gibi açılış panelleri normalde olduğu kadar hızlı oldu. Ve, bu takma adı sunucu adı olarak kullanarak windows 10 ana bilgisayardan powershell betiğimi çalıştırdığımda da hızlıydı.
Bu güncellemeyi bir cevap yerine soruya ekledim, çünkü hala bunun neden oluştuğuna dair bir açıklama arıyorum ve bu adla "localhost" bağlantısı için düzeltmenin bir yolu varsa.