Расширить python / django с помощью c и mod_wsgi с помощью apache - PullRequest
Новая
       12

Расширить python / django с помощью c и mod_wsgi с помощью apache

0 голосов
/ 27 июля 2011

У меня есть вопрос о расширении python с помощью кода c и mod_wsgi.

У меня есть приложение django на сервере apache, которое запрашивает базу данных postgresql для генерации отчетов. В некоторых отчетах система создает CSV-файл с результатами. Чтобы создать этот CSV-файл, иногда система должна обрабатывать более двухсот тысяч регистров с помощью Python, что, очевидно, очень медленно. Чтобы ускорить это, мы запрограммировали модуль c, который выполняет эту работу, и который повышает скорость во много раз. Мы попробовали с ctypes и создали модуль python с c, оба прекрасно работают в runserver, но вылетает при выполнении с apache и mod_wsgi.

Ошибка в httpd-error.log:

[Ср. 27 июля 02:33:52 2011] [извещение] дочерний пид 44657 выходной сигнал Ошибка сегментации (11)

¿Любое предложение?

Код: 

# Creates the HttpResponse object with the appropriate CSV header.
response = HttpResponse(mimetype='application/x-zip-compressed')
response['Content-Disposition'] = \
    'attachment; filename=' + filename + '.zip'

p0 = 'descarga_' + str(datetime.today()) + '.csv'

p1 = settings.DATABASES['default']['NAME']
p2 = settings.DATABASES['default']['USER']

#lib.generar(string_at(p0),p1,p2,string_at(str(init)),string_at(str(end)),string_at(str(provider)))

import generador
generador.generar(p0,p1,p2,str(init),str(end),str(provider))

Это происходит сбой после вызова generador.generar (), который является внешним модулем, разработанным в C

Я также пытался использовать GDb как @GrahamDumpleton suggets, и это вывод, не очень полезный: (* ​​1016 *

Отладчик запускается, и когда я щелкаю по ссылке, которая запускает модуль c, он падает снова при ошибке сегментации 

(gdb) run -X
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /usr/local/sbin/httpd -X
[New LWP 101064]
[New Thread 28501140 (LWP 101064)]


Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 28501140 (LWP 101064)]
0x2847d423 in fwrite () from /lib/libc.so.7

Через некоторое время после ошибки сегментации я попытался с помощью команды 'where' в отладчике, и вот что она выдает: 

(gdb) where
#0  0x2847d423 in fwrite () from /lib/libc.so.7
#1  0x293f8d09 in generar () from /ruta/al/codigo/generador.so
#2  0x28912caa in PyCFunction_Call () from /usr/local/lib/libpython2.7.so
#3  0x2896e49a in PyEval_EvalFrameEx () from /usr/local/lib/libpython2.7.so
#4  0x2897044b in PyEval_EvalCodeEx () from /usr/local/lib/libpython2.7.so
#5  0x288feafd in PyClassMethod_New () from /usr/local/lib/libpython2.7.so
#6  0x288d622c in PyObject_Call () from /usr/local/lib/libpython2.7.so
#7  0x2896c27a in PyEval_EvalFrameEx () from /usr/local/lib/libpython2.7.so
#8  0x2896fadc in PyEval_EvalFrameEx () from /usr/local/lib/libpython2.7.so
#9  0x2897044b in PyEval_EvalCodeEx () from /usr/local/lib/libpython2.7.so
#10 0x288fea0a in PyClassMethod_New () from /usr/local/lib/libpython2.7.so
#11 0x288d622c in PyObject_Call () from /usr/local/lib/libpython2.7.so
#12 0x288e4fd8 in PyClass_IsSubclass () from /usr/local/lib/libpython2.7.so
#13 0x288d622c in PyObject_Call () from /usr/local/lib/libpython2.7.so
#14 0x2893044c in _PyObject_LookupSpecial () from /usr/local/lib/libpython2.7.so
#15 0x288d622c in PyObject_Call () from /usr/local/lib/libpython2.7.so
#16 0x28968ec4 in PyEval_CallObjectWithKeywords () from /usr/local/lib/libpython2.7.so
#17 0x2889b229 in Adapter_run (self=0x28b4dd58, object=0x28c7d50c) at mod_wsgi.c:3841
#18 0x2889be50 in wsgi_execute_script (r=0x28cb4058) at mod_wsgi.c:6547
#19 0x2889de66 in wsgi_hook_handler (r=0x28cb4058) at mod_wsgi.c:9080
#20 0x08076b19 in ap_run_handler (r=0x28cb4058) at config.c:157
#21 0x08079dee in ap_invoke_handler (r=0x28cb4058) at config.c:376
#22 0x08084eb0 in ap_process_request (r=0x28cb4058) at http_request.c:282
#23 0x0808201b in ap_process_http_connection (c=0x28b201f0) at http_core.c:190
#24 0x0807de09 in ap_run_process_connection (c=0x28b201f0) at connection.c:43
#25 0x08089791 in child_main (child_num_arg=Variable "child_num_arg" is not available.
) at prefork.c:662
#26 0x080899e3 in make_child (s=0x28510f10, slot=0) at prefork.c:707
#27 0x0808a591 in ap_mpm_run (_pconf=0x2850f018, plog=0x2853d018, s=0x28510f10) at  prefork.c:983
#28 0x08064195 in main (argc=676384792, argv=0x28b1e018) at main.c:739

1 Ответ

2 голосов
/ 27 июля 2011

Попробуйте установить: 

WSGIApplicationGroup %{GLOBAL}

и принудительно запустить приложение в основном интерпретаторе Python.

Возможно, ваше расширение C написано неправильно для работы с подчиненными интерпретаторами Python.

См .:

http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Python_Simplified_GIL_State_API

Ваш код также может быть просто ошибочным, и использование его в mod_wsgi показывает проблему, где работает командная строка Python.

См.:

http://code.google.com/p/modwsgi/wiki/DebuggingTechniques#Debugging_Crashes_With_GDB

о способах отладки при возникновении сбоя.

ОБНОВЛЕНИЕ 1

При сборке модуля расширения, чтобыотладка помощи в GDB, убедитесь, что оптимизация не включена при компиляции модуля расширения и что параметры отладки.

Для сборки модуля расширения с управлением setup.py я считаю необходимым добавить: 

from distutils import sysconfig
dummy = sysconfig.get_config_vars('CFLAGS', 'OPT')
config_vars = sysconfig._config_vars
config_vars['CFLAGS'] = config_vars['CFLAGS'].replace(' -Os ', ' ')
config_vars['OPT'] = config_vars['OPT'].replace(' -Os ', ' ')

Таким способом можно избавиться от опций -Os.Будет ли это -Os или -O, будет зависеть от вашей установки Python.

Затем проверьте -g в опциях компилятора при сборке модуля расширения и добавьте его, если необходимо.

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

...