Изменить: действительно ценю помощь в поиске ошибки - но поскольку это может оказаться трудно найти/воспроизвести, любая общая помощь отладки будет также очень признательна! Помогите мне помочь себе! =)
Изменить 2: сузить его, комментируя код.
Изменить 3: Кажется, что lxml не может быть виновником, спасибо! Полный script здесь. Мне нужно пойти по ней, ища ссылки. Как они выглядят?
Изменить 4: На самом деле, скрипты останавливаются (идут на 100%) в этой части parse_og. Поэтому edit 3 является ложным - он должен быть lxml каким-то образом.
Изменить 5 ОСНОВНАЯ РЕДАКТИРОВКА: Как было предложено Дэвидом Робинсоном и TankorSmash ниже, я нашел тип data контента, который отправит lxml.etree.HTML( data ) в цикле. (Я беззаботно проигнорировал его, но нашел, что мои грехи искуплены, поскольку я заплатил цену за дополнительные два дня отладки!;) Рабочий сбой script здесь. (Также был открыт новый вопрос.)
Редактировать 6: Оказывается, это ошибка с lxml версии 2.7.8 и ниже (at наименее). Обновлен до lxml 2.9.0, и ошибка исчезла. Спасибо также прекрасным людям в этом последующем вопросе.
Я не знаю, как отлаживать эту странную проблему, с которой я сталкиваюсь. Следующий код работает нормально около пяти минут, когда ОЗУ внезапно полностью заполняется (от 200 МБ до 1700 МБ в течение 100% -ного периода - тогда, когда память заполнена, он переходит в состояние синего ожидания).
Это из-за кода ниже, в частности, первых двух строк. Это точно. Но что происходит? Что может объяснить это поведение?
def parse_og(self, data):
""" lxml parsing to the bone! """
try:
tree = etree.HTML( data ) # << break occurs on this line >>
m = tree.xpath("//meta[@property]")
#for i in m:
# y = i.attrib['property']
# x = i.attrib['content']
# # self.rj[y] = x # commented out in this example because code fails anyway
tree = ''
m = ''
x = ''
y = ''
i = ''
del tree
del m
del x
del y
del i
except Exception:
print 'lxml error: ', sys.exc_info()[1:3]
print len(data)
pass
Вы можете попробовать низкоуровневую отладку Python с помощью GDB. Вероятно, есть ошибка в интерпретаторе Python или в библиотеке lxml, и ее трудно найти без дополнительных инструментов.
Вы можете прервать работу script под управлением gdb, когда использование ЦП переходит на 100%, и посмотрите на трассировку стека. Вероятно, это поможет понять, что происходит внутри script.
это должно быть связано с некоторыми ссылками, которые поддерживают документы. всегда нужно быть осторожным с строковыми результатами оценки xpath. Я вижу, что вы назначили None на tree и m, но не на y, x и i.
Можете ли вы также назначить None на y, x и i.
Инструменты также полезны при попытке найти проблемы с памятью. Я нашел guppy, чтобы быть очень полезным инструментом для профилирования и разведки памяти Python.
Нелегко начать работу из-за отсутствия хороших учебников/документации, но как только вы справитесь с этим, вы найдете это очень полезным. Особенности, которыми я пользуюсь: