PHP PDO SQLSRVR high cpu usage on Database - php

Question

I'm facing a strange problem after reinstall Ubuntu Server 18.04.
My "Server 1" had these packages and drivers to connect PHP-FPM + Apache with a remote Sql Server Database 2016, the connections are using IPv4.
$ odbcinst --version
unixODBC 2.3.7
$ apt list msodbcsql17
msodbcsql17/bionic,now 17.7.2.1-1 amd64 [installed]
$ php --re pdo_sqlsrv | head -1
Extension [ <persistent> extension #33 pdo_sqlsrv version 5.9.0 ]
$ php --re sqlsrv | head -1
Extension [ <persistent> extension #41 sqlsrv version 5.9.0 ]
Below are my /etc/odbcinst.ini content:
$ cat /etc/odbcinst.ini
[ODBC Driver 17 for SQL Server]
Description=Microsoft ODBC Driver 17 for SQL Server
Driver=/opt/microsoft/msodbcsql17/lib64/libmsodbcsql-17.7.so.2.1
UsageCount=1
$ openssl version
OpenSSL 1.1.1 11 Sep 2018
My two servers are Ubuntu 18.04, all packages are upgraded.
To clarify, we are no issues on Ubuntu side, the issues are on SQL Server.
Using my "Server 1", Linux and SQL Server are ok and fast.
But using my "Server 2", with a new Ubuntu 18.04 install, my SQL Server use more than 90% CPU, and Linux still fast.
These two Linux uses the same packages and drivers listed above, with exactly same versions.
The PHP code executed are exactly same on two servers.
I forget to look another package or config on my "Server 2"?
I don't know if have relation, but on my SQL Server, the ODBC Driver version is 13. Maybe not, because the "Server 1" does not cause issues.
Thanks!

Answer 1

Finally, I found the problem!
Fast answer
Reading trace log on SQL Server, on "Application Name" field, we can observe that some origins calls DataBase (Apache, PHP-FPM and PHP Freetds)
The issue occurs using PHP SQLSRV (pdo), with only with FreeTDS (php ext DBLIB) does not have problem.
Then is a good idea use only PHP DBLIB with FreeTDS on unix systems.
Complete answer
TL;DR;
Of course, the problem is not with only with PHP SQLSRV extension. On our investigation, we look at diver version, and client Linux uses newest version of driver MSODBCSQL17.
But on our server, running SQL SERVER 2016, the driver version is 13.
But the Microsoft have a upgrade to version 17 (same used on Linux client)
Reading the change log, an issue about high cpu usage is fixed.
"Can you prove?"
Yes!
We didi a simple test, on our linux "server 1", we remove support from freetds (disable DBLIB), and immediately we can observe a decrease performance on our dashboard, and after some minutes, when freetds is enabled again (DBLIB) the performance returns to normal, see above.
Our new linux does not have freetds installed, we only taken drivers from Microsoft to PHP 7+ and PECL extension.
The problem is because our SQL SERVER uses ODBC Driver 13 and our cliente have ODBC Driver 17.
We can not upgrade the driver on SQL SERVER, because we need this version, and ODBC 17 is supported only on SQL SERVER 2019.
Then, for now our solution is to use freetds and not PHP SQLSRV extension.
Another point to observe is, all query from PHP SQLSRV is parametrized like this:
Declare #Out int;
EXEC sp_prepexec #Out output,
N'#P1 nvarchar(128), #P2 nvarchar(100)',
N'SELECT database_id, name
FROM sys.databases
WHERE name=#P1 AND state_desc = #P2',
#P1 = 'tempdb', #P2 = 'ONLINE';
EXEC sp_unprepare #Out;
The same query with freetds appears on tracer log like this:
SELECT database_id, name
FROM sys.databases
WHERE name='tempdb' AND state_desc='ONLINE';
I think that this difference makes SQL SERVER force use more CPU than FreeTDS with more simple query.
But you have installed both, how to decide wich to use?
Yes, on my "server 1" we have both drivers and extensions installed, but my application decide to use first DBLIB is is available, we use Laravel, and this code is inside connector:
/**
* Create a DSN string from a configuration.
*
* #param array $config
* #return string
*/
protected function getDsn(array $config)
{
// First we will create the basic DSN setup as well as the port if it is in
// in the configuration options. This will give us the basic DSN we will
// need to establish the PDO connections and return them back for use.
if (in_array('dblib', $this->getAvailableDrivers())) {
return $this->getDblibDsn($config);
} elseif ($this->prefersOdbc($config)) {
return $this->getOdbcDsn($config);
} else {
return $this->getSqlSrvDsn($config);
}
}
Conclusion
I didn't knows that my applications still using FreeDTS after install PHP SQLSRV, this problem did not appears before, cause laravel have a preference to dblib.
This problem is too hard to find, and I hope that all analysis helps you, who is reading until this line.
Thx!
;)