Как я могу создать длинную блокировку GIL

Я создаю REST API на Python, используя Python 2.6, Flask для 64-битной Linux.

Меня попросили определить, как GIL может повлиять на производительность этой службы. Что, если произойдет что-то, что заставит интерпретатор заблокироваться на несколько секунд? Интуитивно это помешает производительности, но мне нужно продемонстрировать влияние.

Конкретная проблема заключается в том, что если кто-то вводит код (например, расширение C), который вызывает большое количество дополнительных блокировок, может ли это сделать весь API полностью бесполезным?

Я хотел бы что-то вроде time.sleep(), которое в основном блокирует интерпретатор на определенный период времени. Я мог бы создать модельный API, в котором запросы запускают блокировки разной длины, а затем продемонстрировали бы степень сокращения параллелизма в зависимости от количества времени, проведенного в блокировке.


python gil
person Salim Fadhley    schedule 17.06.2015    source источник
comment
Обеспокоенность обоснована, но если вы позволяете людям вводить код C, вы в любом случае в значительной степени зависите от их милости. Проблемное расширение C также может содержать ошибку, которая приводит к сбою (или, что еще хуже, незаметному повреждению) процесса, что также делает ваш API бесполезным. Я думаю, что единственное, что можно сделать, это разрешить выполнение кода C только в том случае, если вы уверены, что в нем нет проблем (и это верно как с GIL, так и без него).   -  person Jeremy Friesner    schedule 18.06.2015
comment
Я работаю в организации, которая имеет огромное количество устаревшего кода C. Он достаточно высокого качества (глюков не больше, чем мой код на Python), но предположим, что нужная нам функция написана на C. Есть ли у меня потенциал для ее использования? Если да, то какова стоимость параллелизма в моем API. Недопустимо отклонять его, потому что он может содержать ошибки — мне нужно предоставить менеджерам реальные данные о вероятном влиянии, даже если он не содержит ошибок.   -  person Salim Fadhley    schedule 18.06.2015
comment
хороший вопрос. Вы можете сделать собственное расширение C, которое спит. Или иным образом выполните длинный цикл (т.е. занятое ожидание).   -  person Pynchia    schedule 18.06.2015
comment
Достаточно справедливо, но вероятное воздействие будет таким, как и следовало ожидать: когда блокировка удерживается в течение длительного периода времени, любой другой поток, который хочет получить блокировку, будет задержан до тех пор, пока блокировка не будет снята. Величина влияния на производительность будет зависеть от того, как долго расширение C удерживает блокировку.   -  person Jeremy Friesner    schedule 18.06.2015
comment
Кстати: я ничего не знаю о Flask. Порождает ли он потоки или процессы? GIL влияет на первое, а не на второе (см. здесь )   -  person Pynchia    schedule 18.06.2015
comment
Не разработчик C - есть ли что-то готовое, что может иметь правильные свойства? Например, что, если я просто взбил большую матрицу в numpy? Точное время не важно, важно относительное время. Например, если бы я усложнил объем внешнего кода в два раза.   -  person Salim Fadhley    schedule 18.06.2015
comment
По умолчанию Flask имеет многопоточность. Приложению требуется большой объем общей памяти (в частности, большая таблица, возможно, реализованная в чем-то вроде numpy), поэтому я беспокоюсь о расширениях C.   -  person Salim Fadhley    schedule 18.06.2015
comment
Не могли бы вы снизить потенциальные риски путем балансировки нагрузки между несколькими процессами (Использовать веб-инфраструктуру асинхронного ввода-вывода) и даже между несколькими узлами/хостами?   -  person James Mills    schedule 18.06.2015
comment
@James Mills - мы бы в любом случае использовали балансировщик нагрузки, однако на самом деле он не отвечает на вопрос о том, как блокировка GIL повлияет на сервер. Возможно, будет приятно узнать (позже), что хорошее кэширование и балансировка нагрузки могут уменьшить масштаб проблемы.   -  person Salim Fadhley    schedule 18.06.2015
comment
Как сказал @Jeremy Friesner; у вас более серьезные проблемы, если вы разрешаете расширения C в вашей системе, чем GIL, блокирующий интерпретатор. В любом случае вы должны проектировать с учетом масштабируемости и не беспокоиться о том, что произойдет с одним процессом/потоком IHMO.   -  person James Mills    schedule 18.06.2015