Obviously, there could be many reasons for this. Remember that 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 shown in Task Manager will be greater than if the ODBC-ODBC Bridge server is running multi-process. This is because when in MultiProcess mode, a new process is created to handle each incoming connection. When that connection closes, the ODBC-ODBC Bridge server process handling it dies, and CPU usage is not shown 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 and 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 reproduced this on our web site and a few customers have had the same problem — it's always down to not closing the result set. An example that demonstrates this issue follows:
A SQL Server table contains a TEXT column. One row contains a TEXT column with over 7 KB of data in it, but PHP's odbc.defaultlrl (default long read length) is set to the default of 4 KB. A query fetches all columns from this table. PHP binds most of the columns in the table, but uses SQLGetData to retrieve the TEXT column, as it's defined as a SQL_LONGVARCHAR. The problem arises because when PHP's odbc_result() retrieves the result set data, PHP passes a 4 KB buffer, which is insufficient. SQL Server returns 4 KB and SQL_SUCCESS_WITH_INFO and hence the result set isn't 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 run another query, which hangs. At this stage, the ODBC-ODBC Bridge server shows a lot of CPU usage, the underlying reason for which was spin-waiting in the ODBC driver. To avoid this problem, close 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 where 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.
