Home/ Questions/Q 3352952
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-18T02:05:33+00:00

Problem statement : How to parallelize inserts in SQL Server (2008) I am performing

  • 0

Problem statement : How to parallelize inserts in SQL Server (2008)

I am performing massive numeric computation for scientific research in C# multithreaded workers that basically do one thing : Test thousands of possible configurations (matrix combinations) through a time period (in days) and store the results into an SQL Server Database.

If i store the results one by one into DB (~300.000 lines per computing session * 100’s of sessions), one after the other, I end up waiting for hours for the storing process to end.

The database design is very simple :

  • Combination Sets

    CS_ID1, Value A1, Value B1, Value C1

    CS_ID2, Value A2, Value B2, Value C2
    ………

  • Results per Day

    CS_ID1, Day1,Result 1

    CS_ID1, Day2,Result 2

    CS_ID1, Day3,Result 3
    ………

    ………

    CS_ID2, Day1, Result N

    CS_ID2, Day2, Result N+1

    CS_ID2, Day3, Result N+2

Each “Combination Set” is tested against sample days and its per-day results are processed in a single C# thread, where a LINQ/SQL query is generated and sent to DB just before the end of the thread. Except combination set IDs sequences, there is NO logical relation between Results. This is very important : This is why I thought of parallelizing the insert stuff as it basically amounts to a bulk dump of result blocks

Another detail that could be important is that it is possible to determine beforehand how much rows will be inserted into the Database (per block and in total). This probably could help organize table spaces, split them through pages, pre-fix id ranges in order to store blocks simultaneously, or something like that (No, i’m not “high” or something 🙂 )

I welcome any kind of suggestions in order to make this insert time as short as possible.

Please take into account that I am a C# developer, with very basic SQL Server knowledge and not very familiar with deep technical DBA concepts (I saw that Locking tweaks are VERY numerous, that there are multithreaded and asynchronous capabilities, too, but I have to admit I am lost alone in the forest 🙂 )

I Have 12 CPU Cores available, and 24Go RAM

EDIT:
Tiebreaker
I welcome any clever suggestion on monitoring time for the whole process : From C# threads inception/end to detailed SQl server insert reports (What happens when, how, and where).
I tried logging whith NLog but it drastically biases the processing time so I am looking for some smart workarounds that are pretty seamless with minimum impact. Same for the SQL server part : I know there are a couple of Logs and monitoring SP’s available. I did not figure out yet which ones suit my situation.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    If you are using a separate transaction for each insert, that would definitely affect performance, as the DB server would have to atomically perform each insert. I have never used SQL server, but most SQL variants have a way to bunch more than one inserts in a single transaction, usually with something like

    BEGIN TRANSACTION;

...<various SQL statements>...

COMMIT TRANSACTION;

    For the SQL server syntax see:

    http://msdn.microsoft.com/en-us/library/ms188929.aspx

    http://msdn.microsoft.com/en-us/library/ms190295.aspx

    In my experience bundling inserts like this definitely helps with server performance and, to some extent, resource and network usage.

    EDIT:

    Most (all?) decent DB servers use some sort of per-row locking, rather than per-table locks. You should be able to have multiple concurrent transactions, each with multiple inserts, with no problem – that’s what DB servers are designed for. You could certainly have each worker thread perform its own transactions, thus parallelizing the inserts from different threads.

    Since you are apparently using a single computer for the computations and the DB, extensively parallelizing DB transactions would not affect performace too much and it might even make it worse, since you don’t really have any network latencies to reduce the impact of. As long as all CPU cores are busy, which would probably imply a number of workers >= 12, you should be looking at other optimisations.

    If your threads generate their output in one go after processing (e.g. if you compute a large matrix and then dump in to the database) I doubt you would gain anything by storing the result into a file and then having the DB read it back into a table.

    If, on the other hand, your threads do their output piece-by-piece you might benefit by storing parts of their output in memory, then inserting those parts in the DB, performing more than one transactions per round. Raising the number of worker threads in that case might allow you to have better CPU utilisation while the DB is storing the data, if the CPU is underutilised.

    Storing the worker output in a file should IMHO be avoided since it effectively triples the load on the disk subsystem. The only reason you might want to do that is if you really don’t have the memory for intermediate storing of the results.

    • 0