Hello everyone,
I have decided to use the SQL Profiler today, and my goal was to identify requests that take longer than 1 sec, for the execution or the blocking. This is the conditions that I have set up for the SA Profiler:
![Profiling Options]()
The profiler has recorded a multiple similar statements with the following properties:
![Connection Properties]()
What worries me is the high "Idle" value, plus these requests are called from the multiple connections that are still (I think) alive:
![Connections]()
I have found the old thread that says that the idle connections consume memory, and a little CPU when they send "ping" packets: http://sqlanywhere-forum.sap.com/questions/6524/whats-the-performance-downside-to-having-a-lot-of-idle-connections
But I think that this is bad, because it looks like the statement wasn't finished yet (you see, the execution time was still "Unknown") and/or the connection was not returned to the server's connection pool.
A short update. The profiler has also shown me the following warning:
![Non-default options]()
Can you please confirm that I am right in my assumption? Because it is only you who can stop me from the creation of the support ticket to people, who developed the server :)
p.s. I am using SA 17.0.4.2053 (Windows 2012R2 Build 9600, 4 cores).
Just in case:
Auto multiprogramming level - 1
Current multiprogramming level - 20
Min multiprogramming level - 4
Max multiprogramming level - 80
update #2:
I have decided to start demo.db and check it with the SQL Profiler (Profiling options: comprehensive). It showed me that dbisql.exe (I use 64-bit version), gets the number of locks, but probably doesn't close the connection:
![dbisql.exe requests]()
Here you see my simple select:
SELECT @@version;
And then immediately you see the "idle" connection. The source code of com.sybase.saisqlplugin.SAISQLPlugin.getLockedTableCount (I apologize for doing this, but I wanted to know how the "universe" works!) creates the SQL statement object, and then closes it later, but ResultSet is not closed. Am I correct that this is the way where we have the "connection leak" or whatever?
Can someone take a look at my observation, are either the profiler, or dbisql, or me wrong?
To reproduce the issue, you should simply start the profiler (comprehensive mode), dbisql and execute any SELECT.
Thank you in advance,
Vlad