Updated Summary to reflect this appears to be related to using an ssh tunnel - see most recent comments
-------------------------------------
I have a frequent need to run so slow queries against our Aurora MySQL databases. Once a query gets to approximately the 4m runtime, ADS becomes unresponsive until the results are returned. Can't do anything within the UI at that point and other tabs aren't accessible. It doesn't seem to be dependent on the amount of data returned either. The results might have 0 rows or 10000. This means I can't use ADS exclusively for my querying even though I prefer it, and can't really recommend it to colleagues because of this hassle. So I use ADS *and* MySqlWorkbench.
Attached is an example showing how the query and UI hung at the 4 min mark, and then results which in this case was 0 rows after 10 minutes.
I hope you can help. Let me know if there's other information you need.
Tim
Product: Aqua Data Studio
![]() |
183 KB
![]() |
73 KB
![]() |
243 KB
![]() |
23 KB
Hi Tim,
The QA window should work independently of the other parts of ADS. However, I have found on rare occasion that if the connection has a problem is can cause ADS to temporarily hang. Can you open the SQL.Log and View.log windows before you run the long query? This way you can monitor the background queries and errors. The logs can be opened using the Help tab at the top. So Help->SQL.Log and Help->View.Log. The logs will tell you the time each query is taking and if there are errors happening that are not visible in the QA window. Please attach a screen shot of those logs after you have run the query.
Thanks,
Tom
Hi Tom,
Thanks for the quick reply. I'm afraid the logs don't really show anything. See the attached.
Tim
Hi Tom,
Thanks for the quick reply. I'm afraid the logs don't really show anything. See the attached.
Tim
Hmm... A couple of other thoughts...
Could the connection be timing out? Since the query is taking about 8 minutes, maybe the server connection is timing out. Have you tried enableQueryTimeouts=false in the server properties? Or do you have any of the timeouts set in the sever properties like connectTimeout or socketTimeout? These are usually set to 0. Lastly, if you have admin, you can use DBA Tools->Instance Manager to see what the server timeouts are...
Another couple thoughts...
Give those a try and let me know what you find. Would you please attach the datastudio and startup logs located in USER_HOME\.datastudio\logs. Sometimes they will contain some good information.
Thanks,
Tom
Hmm... A couple of other thoughts...
Could the connection be timing out? Since the query is taking about 8 minutes, maybe the server connection is timing out. Have you tried enableQueryTimeouts=false in the server properties? Or do you have any of the timeouts set in the sever properties like connectTimeout or socketTimeout? These are usually set to 0. Lastly, if you have admin, you can use DBA Tools->Instance Manager to see what the server timeouts are...
Another couple thoughts...
Give those a try and let me know what you find. Would you please attach the datastudio and startup logs located in USER_HOME\.datastudio\logs. Sometimes they will contain some good information.
Thanks,
Tom
No, the connection is not timing out. We have our timeout set at something like 2 hours and when that occurs ADS reports the error correctly and it kills my ssh session through which the ADS connects to my server.
I just set enableQueryTimeouts=false, reconnected and reran the same query... no difference. Hung at 4m 1s and then got the results in 7m 44s. Also not running out of memory either. I'm seen that happen before with huge result sets but that's not happening here. As I mentioned the same thing happens when there are no results at all. After this particular query finished with 2740 rows the memory on status bar shows 202 : 264 : 3,641 MB.
Show Text is turned off... I use Show Grid exclusively. I'll attach the requested logs.
No, the connection is not timing out. We have our timeout set at something like 2 hours and when that occurs ADS reports the error correctly and it kills my ssh session through which the ADS connects to my server.
I just set enableQueryTimeouts=false, reconnected and reran the same query... no difference. Hung at 4m 1s and then got the results in 7m 44s. Also not running out of memory either. I'm seen that happen before with huge result sets but that's not happening here. As I mentioned the same thing happens when there are no results at all. After this particular query finished with 2740 rows the memory on status bar shows 202 : 264 : 3,641 MB.
Show Text is turned off... I use Show Grid exclusively. I'll attach the requested logs.
I have more information about this issue and hoping you can help.
This issue only occurs with the connections I use that require a ssh tunnel... regular connections have no issue. Unfortunately I have a few environments that I am required to use a ssh tunnel for and it's those that hang at the 4 minute mark. MySQLWorkbench doesn't have this issue nor do I have issues when I query from the command line using mysql or with other scripting tools. It's only with ADS.
I'm on a Mac and use the following command to create my tunnel from the terminal:
ssh -N -o "ControlPersist=yes" -o "ServerAliveInterval=15" -L 3310:my_db_uri:3306 greentim@jump_server
Then in ADS I setup the connection with Host: localhost and Port: 3310. While I originally reported the problem with ADS 22.1, it happens with the current 22.2.1 as well.
I really hope you can provide some assistance here, if only to find the source of the issue and get it on your backlog to correct. I'm sure I can't be the only one to use a ssh tunnel for DB work and the whole app just locking up for the entire duration of these long running queries is incredibly frustrating.
Thanks,
Tim
PS. By the way I cannot use ADS' built in ssh support to create a tunnel as described here because it doesn't support the -N option - ADS' ssh client requires shell access on the jump server, something our accounts don't have. We can only create tunnels on the jump server.
Also I really wish ADS supported setting up the tunnel within ADS' server properties, something that MySQLWorkbench supports and does well. Whether I configure MySQLWorkbench to create the tunnel itself or have it connect to the one I've created from the command line, I have no trouble with it locking up. It's just ADS.
I have more information about this issue and hoping you can help.
This issue only occurs with the connections I use that require a ssh tunnel... regular connections have no issue. Unfortunately I have a few environments that I am required to use a ssh tunnel for and it's those that hang at the 4 minute mark. MySQLWorkbench doesn't have this issue nor do I have issues when I query from the command line using mysql or with other scripting tools. It's only with ADS.
I'm on a Mac and use the following command to create my tunnel from the terminal:
ssh -N -o "ControlPersist=yes" -o "ServerAliveInterval=15" -L 3310:my_db_uri:3306 greentim@jump_server
Then in ADS I setup the connection with Host: localhost and Port: 3310. While I originally reported the problem with ADS 22.1, it happens with the current 22.2.1 as well.
I really hope you can provide some assistance here, if only to find the source of the issue and get it on your backlog to correct. I'm sure I can't be the only one to use a ssh tunnel for DB work and the whole app just locking up for the entire duration of these long running queries is incredibly frustrating.
Thanks,
Tim
PS. By the way I cannot use ADS' built in ssh support to create a tunnel as described here because it doesn't support the -N option - ADS' ssh client requires shell access on the jump server, something our accounts don't have. We can only create tunnels on the jump server.
Also I really wish ADS supported setting up the tunnel within ADS' server properties, something that MySQLWorkbench supports and does well. Whether I configure MySQLWorkbench to create the tunnel itself or have it connect to the one I've created from the command line, I have no trouble with it locking up. It's just ADS.
Hi Tim,
Which MacOS version are you using? Also, do you have Execution Monitor or Connection Monitor turned on in ADS?
Thanks,
Tom
Hi Tim,
Which MacOS version are you using? Also, do you have Execution Monitor or Connection Monitor turned on in ADS?
Thanks,
Tom
It's happened with multiple versions. I don't recall what version of Big Sur I was using originally, but for the last 9 months or more I've been using Monterey, currently 12.6. Now, on a new M1 Pro as of last week, I'm using Ventura 13.1 which I was disappointed to learn is not supported.
Anyway I have not used with the connection monitor or execution monitor before. Just tried them out. Not sure what should have happened but they hang just like the other windows in ADS, and didn't show anything interesting after the query finished.
It's happened with multiple versions. I don't recall what version of Big Sur I was using originally, but for the last 9 months or more I've been using Monterey, currently 12.6. Now, on a new M1 Pro as of last week, I'm using Ventura 13.1 which I was disappointed to learn is not supported.
Anyway I have not used with the connection monitor or execution monitor before. Just tried them out. Not sure what should have happened but they hang just like the other windows in ADS, and didn't show anything interesting after the query finished.
Actually I see now the lockup seems to correlate to the connection ping time, which the connection monitor conveniently displays. The Idle Connection Threshold is set to 240 seconds - I believe the default - and that's no coincidence apparently. I bumped it up to 2400 for a test and sure enough the UI did not lock up at the 4 minute mark and the query keeps running.
I'm not exactly sure what the consequences of bumping up the ping time will be and if there's some limit that will cause some other problem, but not having the UI lockup and be useless is progress.
Actually I see now the lockup seems to correlate to the connection ping time, which the connection monitor conveniently displays. The Idle Connection Threshold is set to 240 seconds - I believe the default - and that's no coincidence apparently. I bumped it up to 2400 for a test and sure enough the UI did not lock up at the 4 minute mark and the query keeps running.
I'm not exactly sure what the consequences of bumping up the ping time will be and if there's some limit that will cause some other problem, but not having the UI lockup and be useless is progress.
Hi Tim,
If you uncheck the Ping Idle Connections, it should shut the connection monitor off. There should not be any problems with bumping the ping time up if you want to leave it turned on
Tom
Hi Tim,
If you uncheck the Ping Idle Connections, it should shut the connection monitor off. There should not be any problems with bumping the ping time up if you want to leave it turned on
Tom
Yeah, I've disabled it. Is the bug here that an executing query isn't an "idle connection" and shouldn't be pinged, but it's doing it when it's executing over an ssh tunnel? Just curious.
Also, any timeline on when Ventura will be supported, or perhaps suggestions that make it not as broken? I think I'm going to need to simply run ADS on a windows VM now as the UI quickly becomes non-functional on my Mac as I have to exit and restart constantly, and saving query results and some other functions are impossible.
Yeah, I've disabled it. Is the bug here that an executing query isn't an "idle connection" and shouldn't be pinged, but it's doing it when it's executing over an ssh tunnel? Just curious.
Also, any timeline on when Ventura will be supported, or perhaps suggestions that make it not as broken? I think I'm going to need to simply run ADS on a windows VM now as the UI quickly becomes non-functional on my Mac as I have to exit and restart constantly, and saving query results and some other functions are impossible.
Hi Tim,
It might get confused because it is going through SSH. I will have to look into that. As for Ventura, ADS 23.0 should be updated to handle the new OS. Release will be out by the summer.
Thanks,
Tom
Hi Tim,
It might get confused because it is going through SSH. I will have to look into that. As for Ventura, ADS 23.0 should be updated to handle the new OS. Release will be out by the summer.
Thanks,
Tom
Hi Tim,
As a temporary workaround, I understand that ADS 22.1.3 works with Ventura 13.2. Have you tried that? You have to shutoff charts by unchecking File->Options->General->Chart->Support Charts. This, of course, will shut off the charting capability in VA but will let the rest of ADS function.
Thanks,
Tom
Hi Tim,
As a temporary workaround, I understand that ADS 22.1.3 works with Ventura 13.2. Have you tried that? You have to shutoff charts by unchecking File->Options->General->Chart->Support Charts. This, of course, will shut off the charting capability in VA but will let the rest of ADS function.
Thanks,
Tom
Any known work-arounds for Ventura to be at least more functional? It's shocking how badly it behaves, with right-click menus, menu bars and dialogs all completely disappearing and being unusable after a variety of actions, one of which is running any query with grid results.
At the moment it appears the only solution for me will be running ADS via a Windows VM but that has other downsides. While I know Ventura isn't officially supported, if you have any tips you can share that would make it more tolerable it would be nice if you could share them. I'm trying avoid having to deactivate my license and then re-activate on a VM
Any known work-arounds for Ventura to be at least more functional? It's shocking how badly it behaves, with right-click menus, menu bars and dialogs all completely disappearing and being unusable after a variety of actions, one of which is running any query with grid results.
At the moment it appears the only solution for me will be running ADS via a Windows VM but that has other downsides. While I know Ventura isn't officially supported, if you have any tips you can share that would make it more tolerable it would be nice if you could share them. I'm trying avoid having to deactivate my license and then re-activate on a VM
Thank you for that tip! Disabling charting is livable for me. I'm finally able to run a query, save it and save the grid results. At least the app seems usable now and I don't have to switch to using a VM.
I know you guys have a statement on your site saying Ventura isn't supported, but adding this tip would likely help others that upgrade without realizing the impact on ADS. "Unsupported" also doesn't sound nearly as alarming as it should in this instance. Without this tidbit you shared the app is basically unusable.
Thanks again!
Thank you for that tip! Disabling charting is livable for me. I'm finally able to run a query, save it and save the grid results. At least the app seems usable now and I don't have to switch to using a VM.
I know you guys have a statement on your site saying Ventura isn't supported, but adding this tip would likely help others that upgrade without realizing the impact on ADS. "Unsupported" also doesn't sound nearly as alarming as it should in this instance. Without this tidbit you shared the app is basically unusable.
Thanks again!
Issue #15902 |
New |
Completion |
No due date |
No fixed build |
No time estimate |
Hi Tim,
The QA window should work independently of the other parts of ADS. However, I have found on rare occasion that if the connection has a problem is can cause ADS to temporarily hang. Can you open the SQL.Log and View.log windows before you run the long query? This way you can monitor the background queries and errors. The logs can be opened using the Help tab at the top. So Help->SQL.Log and Help->View.Log. The logs will tell you the time each query is taking and if there are errors happening that are not visible in the QA window. Please attach a screen shot of those logs after you have run the query.
Thanks,
Tom