2010-11-03 4 views
3

Я пытаюсь заполнить базу данных MS SQL 2005 с помощью python на окнах. Я вставляю миллионы строк, и на 7 миллионов я использую почти гигабайт памяти. Тест ниже съедает 4 мегабайт оперативной памяти для каждого 100k строк, вставленных:Python в Windows: большое количество вставок с использованием pyobbc вызывает утечку памяти

import pyodbc 
connection=pyodbc.connect('DRIVER={SQL Server};SERVER=x;DATABASE=x;UID=x;PWD=x') 
cursor=connection.cursor() 
connection.autocommit=True 
while 1: 
    cursor.execute("insert into x (a,b,c,d, e,f) VALUES (?,?,?,?,?,?)",1,2,3,4,5,6) 
mdbconn.close() 

решение Hack: Я в конечном итоге нерест новый процесс с использованием модуля многопроцессорной вернуть память. Все еще запутано, почему вставка строк таким образом потребляет столько памяти. Есть идеи?

+0

Вы пытались вручную совершать транзакции? Это немного похоже на то, что ничто из этого не связано с db. – katrielalex

+0

Спасибо.Установка connection.autocommit = False и выполнение ручной фиксации с connection.commit() не влияет на использование памяти. –

ответ

0

Возможно, закрыть & повторно открыть соединение каждые миллион строк или около того?

Уверен, что это ничего не решает, но если вам нужно сделать это только после того, как сможете продолжить жизнь!

+0

Спасибо. Я пробовал connection.close() и connection = pyodbc.connect() каждые 10 000 вставок. Похоже, что использование памяти растет. –

0

Попробуйте создать отдельный курсор для каждой вставки. Повторно используйте переменную курсора каждый раз через цикл, чтобы неявно разыменовать предыдущий курсор. Добавьте connection.commit после каждой вставки.

Вам может понадобиться только что-то простое, как time.sleep (0) в нижней части каждого цикла, чтобы разрешить запуск сборщика мусора.

+0

Спасибо, freegnu. Создание отдельного курсора не имеет никакого эффекта. Я пробовал time.sleep (1) после каждых 1000 вставок, и это не имело никакого эффекта - одинаково для time.sleep (0) после каждого. –

+0

Я использую pymssql для разработки и не вижу половины проблем и ограничений, которые я вижу при использовании mx.odbc.windows в процессе производства. Я предполагаю, что pyobbc также проблематичен. Вы можете попробовать попробовать pymssql. – freegnu

0

Вы также можете попробовать заставить мусорную коллекцию время от времени с помощью gc.collect() после импорта модуля gc.

Другим вариантом может быть использование cursor.executemany() и посмотреть, устраняет ли это проблему. Однако неприятная вещь о executemany() заключается в том, что она принимает последовательность, а не итератор (поэтому вы не можете передать ему генератор). Сначала я попробую сборщик мусора.

EDIT: Я только что проверил код, который вы опубликовали, и я не вижу той же проблемы. Вы используете старую версию pyobbc?

1

Даже я столкнулся с той же проблемой.

я должен был прочитать более 50 XML файлов каждый около 300 Мб и загрузить их в SQL Server 2005.

Я попытался следующие:

Используя тот же курсор разыменовывая.

закрытия/открытия соединения

Установка подключения к None.

Наконец-то завершилась загрузка каждой загрузки файла XML с помощью модуля Process.

Теперь я заменил процесс, используя IronPython - System.Data.SqlClient.

Это дает лучшую производительность, а также лучший интерфейс.

8

Я была такая же проблема, и она выглядит как pyodbc вопрос с параметризованными вставками: http://code.google.com/p/pyodbc/issues/detail?id=145

Временного переключения на статические вставки с пунктом ЦЕННОСТЕЙ заселенным исключает утечку, пока я не попытаться построить от источника тока ,

+0

Это решило это. Жаль, что у меня было 15 очков, поэтому я мог проголосовать за это. Большое спасибо! –

+1

Как представляется, последний код разрешает проблему без обходного пути. – MattK

Смежные вопросы