Каков рекомендуемый размер партии для SqlBulkCopy?

Question

Какой рекомендуемый размер партии для SqlBulkCopy? Я ищу общую формулу, которую могу использовать в качестве отправной точки для настройки производительности.

Answer 1

У меня есть утилита импорта, расположенная на том же физическом сервере, что и мой экземпляр SQL Server. Используя пользовательский IDataReader, он анализирует плоские файлы и вставляет их в базу данных, используя SQLBulkCopy. Типичный файл содержит около 6 миллионов строк, в среднем 5 столбцов десятичного и короткого текста, около 30 байтов на строку.

Учитывая этот сценарий, я считаю, что размер пакета в 5000 является лучшим компромиссом по скорости и потреблению памяти. Я начал с 500 и экспериментировал с большим. Я обнаружил, что 5000 в 2,5 раза быстрее, в среднем, чем 500. Вставка 6 миллионов строк занимает около 30 секунд при размере пакета 5000 и около 80 секунд при размере пакета 500.

10000 не было заметно быстрее. Переход на 50000 увеличил скорость на несколько процентных пунктов, но не стоит увеличивать нагрузку на сервер. Выше 50000 не показали улучшения в скорости.

Это не формула, а еще одна точка данных, которую вы можете использовать.

Answer 2

Это проблема, которую я тоже потратил некоторое время на изучение. Я стремлюсь оптимизировать импорт больших файлов CSV (16+ ГБ, более 65 миллионов записей и больше) в базу данных SQL Server 2005 с помощью консольного приложения C # (.Net 2.0). * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * вы должны выполнить некоторые тонкие настройки для ваших конкретных обстоятельств, но я бы порекомендовал, чтобы у вас был начальный размер пакета 500, и тестовые значения оба выше и ниже этого.

Я получил рекомендацию проверить значения между 100 и 1000 для размера пакета из этого сообщения на форуме MSDN , и был настроен скептически. Но когда я проверил размер партии от 100 до 10000, я обнаружил, что 500 было оптимальным значением для моего приложения. Значение 500 для SqlBulkCopy.BatchSize также рекомендуется здесь .

Чтобы дополнительно оптимизировать работу SqlBulkCopy, ознакомьтесь с этим MSDN advice ; Я считаю, что использование SqlBulkCopyOptions.TableLock помогает сократить время загрузки.

Answer 3

Как уже говорили другие, это зависит от вашей среды, в частности от объема строки и задержки в сети.

Лично я бы начал с установки свойства BatchSize на 1000 строк и посмотрел, как это работает. Если это работает, то я продолжаю удваивать количество строк (например, до 2000, 4000 и т. Д.), Пока не получу тайм-аут.

В противном случае, если время ожидания составляет 1000, я уменьшу количество строк наполовину (например, 500), пока оно не заработает.

В каждом случае я продолжаю удваивать (в случае успеха) или делить пополам (если не удается) разницу между каждым из двух последних предпринятых размеров партии до тех пор, пока не найду подходящее место.

Другой фактор, который необходимо учитывать, - это сколько времени занимает копирование одной серии строк. Тайм-ауты произойдут, если копируемый пакет строк превышает свойство BulkCopyTimeout, которое по умолчанию составляет 30 секунд. Вы можете попробовать удвоить свойство BulkCopyTimeout до 60 секунд. Это позволяет более длительный период времени копировать больший набор строк пакета. Например, партия из 50000 строк может занять около 40 секунд, что просто превышает 30-секундный лимит времени, поэтому увеличение его до 60 секунд может повысить производительность.

Answer 4

Все зависит от вашей реализации.

Какую скорость вы можете ожидать в своей сети? Вы используете это в формах или ASP.Net? Вам нужно предупредить пользователя о прогрессе? Каков размер общей работы?

По моему опыту, запуск массового копирования без указания размера пакета вызовет проблемы с тайм-аутом. Мне нравится начинать с чего-то вроде 1000 записей и делать оттуда некоторые корректировки.