Существует ли причина, почему SSIS значительно замедляется после нескольких минут?
Я выполняю довольно существенный пакет SSIS против SQL 2008 - и я получаю те же результаты оба в моей dev среде (Win7-x64 + SQL-x64-Developer) и продуктивная среда (Сервер 2 008 x64 + Станд. SQL x64).
Признак - то, что исходные данные, загружающие крики в между 50K - 500K записи в секунду, но после нескольких минут скорость понижается существенно и в конечном счете проверяет смущающе медленно. База данных находится в Простой модели восстановления, целевые таблицы пусты, и все предпосылки для минимально зарегистрированного объема вставляют, встречаются. Поток данных является простой загрузкой от НЕОБРАБОТАННОГО входного файла до подобранной схеме таблицы (т.е. никакой комплекс не преобразовывает данных, никакой сортировки, никаких поисков, никакого SCDs, и т.д.),
Проблема имеет следующие качества и устойчивость:
- Проблема сохраняет, какова целевая таблица.
- Использование оперативной памяти является lowish (45%) - существует много запасной RAM, доступной для буферов SSIS или SQL Server для использования.
- Выставочные буферы Perfmon не буферизуют, дисковое время отклика нормально, доступность дисков высока.
- Использование ЦП является низким (парения приблизительно 25%, совместно использованных sqlserver.exe и DtsDebugHost.exe)
- Активность диска, прежде всего, на TempDB.mdf, но вводе-выводе является очень низкой (<600 Кбит/с)
- Место назначения OLE DB и Место назначения SQL Server обе выставки эта проблема.
Для подведения его я ожидаю, что или диск, ЦП или RAM будут исчерпаны, прежде чем пакет замедлится, но вместо этого, как будто пакет SSIS берет послеобеденный сон. SQL-сервер остается быстро реагирующим к другим запросам, и я не могу найти счетчики производительности или зарегистрированные события, которые предают причину проблемы.
Я с благодарностью буду вознаграждать любые разумные ответы / предложения.
3 ответа
Первые мысли:
- Растут ли файлы базы данных (без мгновенной инициализации файлов для MDF)?
- Является ли загрузка пакетной / транзакционной? AKA, это одна большая транзакция?)
Выполняете ли вы ОБЯЗАТЕЛЬСТВА? Я видел, как такие вещи замедляются, когда рабочий набор становится слишком большим (конечно, относительная мера). Периодический COMMIT должен предотвратить это.
Лучший способ диагностировать проблемы производительности с потоками данных SSIS - это декомпозиция.
Шаг 1 - измерьте текущую производительность вашего пакета. Вам нужен базовый план. Шаг 2. Сделайте резервную копию вашего пакета, а затем отредактируйте его. Удалите назначение и замените его числом строк (или другим преобразованием, ориентированным на конец потока). Снова запустите пакет, чтобы измерить производительность. Теперь вы знаете, что ваше место назначения снижает производительность. Шаг 3. Отредактируйте пакет еще раз, удалив следующее преобразование «вверх» снизу в потоке данных. Беги и измеряй. Теперь вы знаете, как это преобразование снижает производительность. Шаг 4 ... n - Промойте и повторите.
Вам, вероятно, не придется карабкаться вверх по потоку, чтобы понять, каков ваш ограничивающий фактор. Когда вы его найдете, вы можете задать более конкретный вопрос о производительности, например: «X-преобразование / назначение в моем потоке данных медленное, вот как он настроен, это мой объем данных и оборудование, какие у меня варианты?» По крайней мере, вы точно будете знать, в чем заключается ваша проблема, что останавливает множество диких гусиных погонь.