Obviously, there could be many reasons for this. It should be remembered that all the CPU showing in Task Manager for esoobserver includes the CPU used by the Driver Manager and the ODBC driver you are using. If the Easysoft ODBC-ODBC Bridge Server is running threaded (the default) then CPU usage SEEN in Task Manager will be greater than if the ODBC-ODBC Bridge Server is running MultiProcess. This is because when in MultiProcess mode, a new process is created to handle each incoming connection. When that connection is closed, the ODBC-ODBC Bridge Server process handling it will die, and you cannot see the CPU usage for a dead process.
The most common scenario where the ODBC-ODBC Bridge Server appears to be using a lot of CPU is: when handling a connection to Microsoft SQL Server, a result set has been generated but not consumed/closed and an attempt to create a new result set is then made. In this case, the Microsoft SQL Server ODBC driver appears to spin-wait, consuming a lot of CPU. We have seen this ourselves on our web site and a few customers have hit the same problem — it is always down to not closing the result set. The example below is a real example that occurred in a PHP script, it is provided in the hope it will help others avoid this problem.
The table in the Microsoft SQL Server database contained a column defined as TEXT. One row in the table contained one of these text columns with over 7K in it, but PHP's odbc.defaultlrl (default long read length) was set to the default of 4K. A query was issued that retrieved all of the columns from this table. PHP bound most of the columns in the table, but used SQLGetData to retrieve the TEXT column, as it was defined as a SQL_LONGVARCHAR. The problem arises because when PHP's odbc_result() was called to retrieve the result set data, PHP passed a 4K buffer, which was insufficient. Microsoft SQL Server returned 4K and SQL_SUCCESS_WITH_INFO and hence the result set was not consumed. (ODBC says you can call SQLGetData multiple times on the same column to retrieve the data in chunks.) The PHP script then goes on to issue another query, which hangs. At this stage, the ODBC-ODBC Bridge Server on the NT machine showed a lot of CPU usage, which was tracked down to spin-waiting in the ODBC driver. This problem can be avoided very simply by closing any result set that you generate. In PHP , that means calling odbc_free_result(), which, in ODBC terms, is a call to SQLFreeStmt(SQL_CLOSE).
In every case, high CPU usage in the ODBC-ODBC Bridge Server has been reported to us, the connection was always to Microsoft SQL Server and always resulted from the result set not being closed.
© 1993 - 2024 Easysoft Limited. All rights reserved. Oracle® is a registered trademark of Oracle® Corporation and/or its affiliates. Other trademarks and registered trademarks appearing on easysoft.com are the property of their respective owners.
