Python-сообщество

1. программа сканирует папку на наличие файлов.
2. если файл найден, то он читается построчно.
3. строчки преобразуются в соответствии с настройками программы
4. преобразованные строчки складываются в новый файл
5. когда все строчки прочитались и переработались
5.а новый файл закрывается и перекладывается в директорию базы
5.б исходный файл перекладывается из сканируемой папки
6. база всасывает новый файл
есть некоторые другие операции. рассказывать подробнее мне не хочется,.. паранойя опять же.

что делает с файлом БД не расскажу, т.к. это не моя часть, да и не думаю, что это важно, т.к. для прекращения тормозов перезапуск БД не требуется, а требуется перезапуск моей программы.
ещё в моей программе есть второй тред. сегодня добавил в него логирования, чтобы отслеживать замедление и в нём, и логирование, есть ли во втором треде накопление объектов.

axe
сегодня добавил в него логирования, чтобы отслеживать замедление и в нём, и логирование, есть ли во втором треде накопление объектов.

Вот об этом я и хотел спросить.
Логгируйте время выполнения каждого из пуктов.
Чтобы локализовать проблему.

Lexander
Логгируйте время выполнения каждого из пуктов.
Чтобы локализовать проблему.

в лог при чтении/разборе исходного файла пишется:

reading 1.625 secs, parsing 45.537 secs, decode 27.554 secs

reading - это построчное чтение файла и ничего более.
Спустя некоторое время (когда сервер под нагрузкой) reading растёт до 100-200 секунд, но может и до 300-900. Остальные операции (parsing, decode) остаются примерно с таким же временем.

Давайте сначала получим результаты для всех этапов, чтобы можно было делать какое-то выводы.
Было бы неплохо иметь их все в виде линейных графиков в одной системе координат.
И наложить эти данные на используемую память.

axe
Информация из шапки top:

Это в момент тормозов?

Когда вы перезапускаете скрипт, он начинает сначала, или продолжает с где прервался предыдущий?
Если сначала, то возможно файл он будет читать из кеша, из-за этого не будет тормозов.

вообщем вероятнее всего тормоза в диске, я бы попробовал (для теста) обойти диск стороной, сделать ram диск (на сервере 100Г оперативы), либо попробовать подключить сетевой диск 1000Mbit/sec или более.
Кстати это локальный диск? (не сетевой?)

У меня есть другой вариант - пусть ваш скрипт складывает готовый файл в другой каталог, не в “директорию базы”(чтобы обойти пункт 6, вы же можете потом эти файлы подбросить базе руками) и посмотреть наличие тормозов.

PS: Я все таки склонен продолжать полагать, что импорт в базу загружает ввод/вывод, а питоновский скрипт сидит на блокировке при чтении(поэтому и время ядра такое большое). Прошу проверить, тем более это самая простая из предложенных проверок - исключить пункт 5а

Отредактировано PooH (Ноя. 28, 2013 04:04:06)

PooH
Я все таки склонен продолжать полагать, что импорт в базу загружает ввод/вывод

+там ещё помимо этого, кто-то логи пишет на диск.

у меня на боевом сервере не более 100 процессов, тут же более 400, т.е. его наверно юзают в доль и поперек, и самые тормоза по видимому с диском, при этом проц “простаивает”, так что там рам диск так и просится, для увеличения общей производительности, тем более что там “по настоящему” используется всего 23Гб из 94 (в момент снимка топа).

o7412369815963
Когда вы перезапускаете скрипт, он начинает сначала, или продолжает с где прервался предыдущий?

Скрипт дампит свою память в файл. При старте считывает дамп в память.

o7412369815963
Кстати это локальный диск? (не сетевой?)

локальный логический, который физически использует три части на разных винтах.
На текущий момент нашли, что логические диски моей программы и оракла “пересекаются” на одном физическом диске. И похоже, что оракл тоже притормаживает параллельно с моей прогой, но не так сильно.
Внутри скрипта сделал перезагрузку по signal.alarm (с дампом памяти). В случае внештатного завершения скрипт поднимается фениксом…