-
Notifications
You must be signed in to change notification settings - Fork 297
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Possible bug: SqlDataReader.ReadAsync hangs and produces high garbage collection. #439
Comments
System.Data.SqlClient in this repository has been deprecated in favour of Microsoft.Data.SqlClient. I've contributed a number of performance improvements to that version of the library and if you can produce a simple test case against then 2.0.0preview that replicates your problem I can look into it to see what's going on. |
@Wraith2 Same issue persists with Microsoft.Data.SqlClient versions "1.1.1" and "2.0.0-preview1.20021.1".
Console: |
@cheenamalhotra this might be worth moving |
Thanks for the repro @aliveli186 . The new home for SqlClient driver issues is "dotnet/sqlclient" repository, we will investigate and get back to you! |
@aliveli186 we'll need the sproc and any other database definitions it depends on. |
@Wraith2 The table it selects is a View which depends on few other tables, few joins. Can't provide the db schema now. It's not a query problem because SQL Management Studio is working fine when executed with the same parameters.
|
@cheenamalhotra does the investigation clarified the issue? I am having same, |
Investigation stalled because there isn't a complete repo, see "Can't provide the db schema now." above. If you have a self contained repo we can run then it can continue. Looking back at the report though It smells like long async strings to me and the answer is to not do that, fetch the string sync or use a textreader stream. |
@Wraith2 yep, fetching sync solves the issue. And the string was indeed huge, about 260 Mb. |
That's huge. Unless you actually need that as a string I strongly suggest using the GetTextReader overload in sequential mode, it'll save you a lot of GC work. |
Another variant of #593, possibly a dup? |
Yup |
@cheenamalhotra consider closing as a dup of #593 |
I do sort of have a plan on how to deal with the long strings but it requires a lot of changes throughout the library. The main problem is that each received packet starts the parse process again which we could avoid if we knew that we could just pick up from the end of the last packet's parse stall, but we can't do that because we can't tell a stall from a failure because all the TryRead* functions return Boolean where true is succeeded and failure could mean error or stall. If we replace those bools with OperationResult and flow that all the way through we could snapshot on stall and then resume from that snapshot at the next packet receipt. |
Tested on: System.Data.SqlClient versions "4.4.0", "4.8.0" and "4.8.1"
I'm trying to read from a table which has 8 records.
In ReadAsync it fetches the first 6 records quickly and hangs around 45 seconds to fetch the rest 2.
During that 45 seconds time produces very high garbage collection.
The synchronous version on the other hand fetches the records immediately and there is no visible garbage collection.
vs.
The text was updated successfully, but these errors were encountered: