0

Using docker compose (and ACI integration), I start services to be run in Azure Container Instances. One of the service is SQL Server 2019 docker container. It takes a moment to get the containers up and running. However, even if the SQL Server container is then in running state and the log shows it has successfully started, it takes quite long (a few minutes) for the SQL Server to be able to accept connections.

Does somebody know why it takes that long?

So when trying to connect to the server using sqlcmd, I keep getting the following response for a few minutes later right after the server has started:

Sqlcmd: Error: Microsoft ODBC Driver 17 for SQL Server : Login timeout expired.
Sqlcmd: Error: Microsoft ODBC Driver 17 for SQL Server : TCP Provider: Error code 0x102.
Sqlcmd: Error: Microsoft ODBC Driver 17 for SQL Server : A network-related or instance-specific error has occurred while establishing a connection to SQL Server. Server is not found or not accessible. Check if instance name is correct and if SQL Server is configured to allow remote connections. For more information see SQL Server Books Online..

UPDATE [2021/12/22]:

I wonder also why the "top" command executed from within the DB container shows the following. The mssql process uses almost 100% CPU. However, the overall status of the CPU (please see the row "%Cpu(s):") shows the CPU is 66% idle. Does somebody know why?

enter image description here

Jakub Janiš
  • 131
  • 1
  • 2
  • 8
  • Have you tried researching this yourself? What have you tried what helped/did not help? One of the first google results: https://github.com/microsoft/mssql-docker/issues/644 – Alex Dec 16 '21 at 07:03
  • Have you run `docker logs | less` yet? You might observe that SQL Server takes some time to load each of the system and user databases which includes rolling back incomplete transactions, validating the pages and upgrading files to the latest file format version. Only after that will it open a server socket to accept client connections. One would posit that your Docker/k8s health check should be testing that the mssql process is accepting connections, not just that the process itself is running. – AlwaysLearning Dec 16 '21 at 11:12
  • @Alex Yes, I've done some research already but haven't found an answer for this yet. Thank you for pointing me to that issue on github. – Jakub Janiš Dec 16 '21 at 13:47
  • @AlwaysLearning Yes, I always checked the container logs first. From the log, it appears the server is ready. There is no user database, it's just an empty server (with master database etc.). The log says "Server is listening on any address.." and it also contains the following message in the end which usually indicates (as I know it from running ‍♀️ it locally) that the DB has started. `Recovery is complete. This is an informational message only. No user action is required.` However, the server usually does not accept any remote connections for a few minutes after. – Jakub Janiš Dec 16 '21 at 13:52
  • May be, the public DNS address is not setup and the MSSQL service is yet to start and bind with the container to be connected at first attempt. – Kartik Bhiwapurkar Dec 16 '21 at 18:20

1 Answers1

1

• I tried to reproduce your scenario in my environment by deploying a mssql/server:2019-CU12-ubuntu-20.04 image in a container group instance. I was able to connect to the container instance almost instantly as soon as it was started. Also, I connected to the SQL database service through sqlcmd utility almost instantly after starting the container group instance. Here are the screenshots for your reference: -

SQL Container Container properties Container overview SQLCMD connection

I would suggest you to please reconfigure the vCPU and memory allotted to your ACI group running SQL image once again and restart the ACI group one more time and then retry to connect to the SQL instance in it once again. It should connect almost instantly after starting the ACI.

Also, due to the inadequate resources available, the SQL service might take a bit longer to startup and get discoverable through the DNS.

Update for the question : - the ACI CPU Usage metrics seems to be in millicores, not in %. So, when you are seeing above mssql process using 99.7% of CPU, it means 99.7 millicores of a CPU are utilized which accounts for almost 10% of a single vCPU core.

Please refer this documentation link for more details regarding the CPU usage calculation: -

https://learn.microsoft.com/en-us/azure/container-instances/container-instances-monitor#available-metrics

Kartik Bhiwapurkar
  • 4,550
  • 2
  • 4
  • 9
  • Hello, thank you for trying this out. I tried again today. For the 1st and 2nd time I re-started the container, the DB was accessible instantly from a remote machine. However, at the 3rd attempt, the DB was not accessible even 7 minutes later (even though the DB log says it's started). The DB container has reserved 2 vCPU and 4 GB memory. I wonder if this still could have something to do with a lack of resources available or the network stuff taking time to get configured. – Jakub Janiš Dec 22 '21 at 09:15
  • Added update to the question above. – Jakub Janiš Dec 22 '21 at 09:35
  • Please check the answer above, I have edited it to include the answer of your edited question also to best possible level of my understanding. – Kartik Bhiwapurkar Dec 23 '21 at 07:09