Also check the default ANSI settings between your local SSMS and the remote SSMS. Differences there can result in different execution plans.
How big are these queries. 30 seconds for a query is slow to begin with for most of the systems I've dealt with (except large data warehouses).
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
Thank you all for responding. Below are the details all of you asked for:
1. Dataset returned is 1.75 million rows. The query is a simple SELECT query, but aggregating (SUM) on a large number of rows. So i guess 30 secs is acceptable for now.
2. Number of tables joined in the query are two. The join is a simple INNER JOIN. First table has around 5 million rows and second table has 30,000 rows. you might have already guessed, aggregation is happening on first table.
3. Same user for all connections.
4. Windows login used for connecting to remote server from my local SSMS client.
5. Windows login used when connecting to the box through RDP session and through SSMS client on the box.
6. I checked ANSI settings and both SSMS clients have similar settings. No difference.
I tried executing the query from other machines using other user logins and got same result. Query executes much faster when connecting through remote SSMS client and same executes much slower when connecting through SSMS client on server box. For the life of me, i am not able to figure this out. Any help is highly appreciated.
Thanks,
Vasu
Hello,
This is happening with all queries. Same user windows login used to connect to server.
Thanks,
Vasu
So you're going to an underpowered machine (8gb is half the memory my laptop has) and you're running a very large aggregation query and returning 1.7 million rows. The machine is expected to both process the query and then process and display the result set, but you're unsure why that's causing the system to slow down? I'm pretty sure I can tell you why. Think about it, the result set isn't just stored once. It's being processed by the server instance and then it's being processed by the client, both on the same machine. Plus, I'll be you don't have max memory set inside of SQL Server. So the server instance is chewing up as much of the memory resources as it possibly can to answer your query. Then, the OS has to try to either reclaim a bunch of that memory form SQL Server in order to store it within the client application of SSMS (which isn't using the same memory space as your SQL Server instance, they are two completely separate executables) or, it's swapping out to disk like mad in order to consume all that data.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
Grant Fritchey (7/8/2014)
So you're going to an underpowered machine (8gb is half the memory my laptop has) and you're running a very large aggregation query and returning 1.7 million rows. The machine is expected to both process the query and then process and display the result set, but you're unsure why that's causing the system to slow down? I'm pretty sure I can tell you why. Think about it, the result set isn't just stored once. It's being processed by the server instance and then it's being processed by the client, both on the same machine. Plus, I'll be you don't have max memory set inside of SQL Server. So the server instance is chewing up as much of the memory resources as it possibly can to answer your query. Then, the OS has to try to either reclaim a bunch of that memory form SQL Server in order to store it within the client application of SSMS (which isn't using the same memory space as your SQL Server instance, they are two completely separate executables) or, it's swapping out to disk like mad in order to consume all that data.
The server spec isn't bad and according to this the max_mem is set to 200Gb:
Thank you for the response. I am sorry for not giving out the SQL box specifications. It has 256 GB RAM, of which 200 GB is dedicated to SQL Server instance. Hard drives are 1 TB each with a total of 5 drives. Data files, log files and tempDB have dedicated drives(D, E and F). Hope this information helps.
I agree with Grant here, the overhead of spawning a desktop session and everything that comes with it is most likely the main cause, although this are respectable specs for a server. The desktop session is just putting pressure in the wrong place if you like. My suggestion is to try both remote SSMS and local (RDP) SSMS with the settings of discarding the result set (query options->Results->Discard Results after execution. If there is less of a difference between the two, this is definitely the culprit.
Where the heck did I see it was 8gb? Maybe time to up my coffee intake. Sorry for the misunderstanding there.
The rest of the processing bit is still correct. You're expecting two separate executables on a single machine to process as much information as quickly as it would on two machines.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
Viewing 11 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply