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

XCoder
Так где же истина? … РНР в ограничения на уровне языка …

Если вы будете использовать Python вместо PHP, то вы не только ничего не потеряете, но еще и много найдете.

Lexander

Благодарю за ссылку. Прочитал многие материалы по линку и далее.

doza_and
У вас есть multiprocessing на крайний случай

Ок. Этот момент ясен на уровне языковой абстракции, но не ясен на уровне глубже. Пытаюсь выяснить нюансы, т.к. вся суть в деталях.

Я попробую изобразить свое понимание графически двумя блок-схемами:

Меня интересует процесс отработки на уровне интерпретатора Python:

1) Как происходит обработка запросов на исполнение 16 независимых скриптов?

2) И как происходит обработка Fork (multiprocessing), если использовать эту возможность в рамках кода одного скрипта (допустим в рамках Script 1), ведь исполнение байт-кода лежит на плечах VM. То есть по сути скрипт - это инструкции для VM, и, следовательно, Fork - это вызов операции для VM, который предполагает вызов системной операции на уровне ОС для выделения области памяти новому независимому дубликату основного процесса VM?

Ведь, насколько я понимаю, машинные инструкции перегнанные в оперативную память в рамках области доступа виртуалки не могут получить доступ к иным областям, т.е. иными словами на уровне ОС будет дополнительно выделена память для VM, в рамках которой процесс (скрипт) выполняется и производятся все манипуляции с синхронизацией потоков, чтобы обеспечивать целостность данных.

Мое непонимание по поводу работы интерпретатора Python я выразил образно на схеме выше.

В идеале читать исходники VM Python и документацию по ядру ОС (а еще лучше исходники), но, боюсь, не осилю, да и не так много времени, чтобы изучать все это досконально =(

Отредактировано (Ноя. 12, 2011 10:11:18)

>>> Как происходит обработка запросов на исполнение 16 независимых скриптов?
Какие запросы и какие скрипты? Ничего не понял.

Андрей Светлов
>>> Как происходит обработка запросов на исполнение 16 независимых скриптов?
Какие запросы и какие скрипты? Ничего не понял.

Хм. Ок, попробую задать вопрос иначе:

Допустим, есть физический сервер с 4 цпу (по 4 ядра каждый, итого 16 ядер), на котором установлен веб-сервер и Python.

Мы размещаем там 16 разных файлов, содержащих какой-то программный код, неважно при этом, что код делает, и настраиваем все таким образом, что скрипты запускаются при обращении к веб-серверу по адресам:

http://site.zz/1/ - Отрабатывает 1.py
http://site.zz/2/ - Отрабатывает 2.py
…
http://site.zz/16/ - Отрабатывает 16.py

Вы не могли бы мне подробно объяснить, как произойдет выполнение этих скриптов, если 16 пользователей одновременно (почти одновременно) обратятся к ним?

Будет ли отработка полностью параллельной: произойдет ли распределение нагрузки на 16 ядер?
Не встанут ли запросы в очередь, и не начнет ли Python VM отрабатывать (интерпретировать и выполнять) эти 16 скриптов последовательно (параллельно выполняя не сами скрипты, а потоки в них)?

Я просто хочу понять что происходит на низком уровне.

> Будет ли отработка полностью параллельной: произойдет ли распределение нагрузки на 16 ядер?
Да,
процессы работают независимо друг от друга.

XCoder, это вопрос не к питону как таковому и не к его интерпретатору.
Вы заводите web server (к примеру apache+mod_wsgi). Указываете в настройках mod_wsgi: держать 8 процессов по 8 потоков в каждом (точные цифры подбираются смотря на реальную загрузку, они зависят от особенностей вашего приложения).
mod_wsgi распределяет нагрузку на все имеющиеся процессы-потоки. Получаете желаемое быстродействие.

Это самая простая, но не единственная схема использования.

Можно запускать по CGI «скрипту» на каждый запрос — медленно и неудобно.
Можно использовать неблокирующие фреймворки — и т.д.

Самый распростаненный сейчас способ — завести nginx и под uwsgi (аналог mod_wsgi) наделать рабочих процессов.
Затем, используя любой WSGI framework (Django, Pyramid, Flask и т.д. — выбор за вами) писать ВЕБ-ПРИЛОЖЕНИЕ в качестве сайта.
Скриптов просто нет — это не PHP, здесь работаю программы а не отдельные скрипты.

Хм. Так, давайте, попробуем разобраться, как говорится “на пальцах”. Из всего выше сказанного, я смог сделать примерно следующий вывод:

Поясню:

1) Запущен главный процесс NGINX с модулем uWSGI

2) Он порождает три worker'a, они висят и ждут работы

И тут вдруг к нам на сервер приходят три запроса почти одновременно:

1.1) Main process NGINX раскидывает запросы worker'aм и те совершенно независимо и параллельно (допустим, ядер у нас хватает) отрабатывают их на разных ядрах.

2.1) Worker'ы обращаются через интерфейс к PVM (ведь, насколько я понял, процесс у PVM всего один по умолчанию)

3) PVM начинает последовательно интерпретировать коды (в один поток)

3.1) По мере интерпретирования, допустим, нулевой код 0.py использует multiprocessing и PVM вынуждена сделать системный вызов Fork для того, чтобы породить собственный параллельный процесс для интерпретирования и выполнения нулевого кода.

3.2) Далее последовательно в главном потоке PVM интерпретируются коды 1.py и 2.py, содержащие threading.

3.2.1) Основной процесс PVM инициирует дополнительные потоки, которые используются в рамках одного из доступных ядер, на котором из-за GIL возникает псевдо-праллелизм в рамках исполнения кода 1.py

3.2.2) То же самое на другом ядре цпу, но уже с кодом 2.py

—

Итого:

Многопоточный код 0.py используется в отдельном процессе PVM на отдельном ядре с псевдо-параллелизмом из-за GIL.

Многопоточный код 1.ру используется на отдельном ядре, но в главном процессе PVM с псевдо-параллелизмом из-за GIL.

Многопоточный код 2.ру используется на отдельном ядре, но в главном процессе PVM с псевдо-параллелизмом из-за GIL.


Остальные ядра ЦПУ ничего не делают, так как, насколько я понял, потоки не могут быть раскиданы процессом PVM так, чтобы один код мог выполнять свои потоки независимо на разных ядрах взаимно не блокируя их.

Хм. Но так как GIL относится к процессу PVM целиком, тогда, вероятно, даже на разных ядрах будет иметь место псевдо-параллелизм, что еще более усугубляет картину, так как коды 1.ру и 2.ру вообще не смогли бы исполняться параллельно, постоянно блокируясь из-за GIL (ведь они исполняются в потоках одного и того же процесса PVM), лишь местами уступая друг другу время в моменты I/O одного из потоков.

P.S.
Обратите внимание на желтые блоки на схеме, я таким образом сгруппировал потоки, относящиеся к одному коду.

Андрей, я Вас правильно понимаю, под программой / веб-приложением Вы подразумеваете именно исполнение PVM совокупности потоков относящихся к одному коду (желтый блок - “отдельное приложение”)? Иными словами, грубо говоря, исполняется на PVM код из файла 1.ру - это и есть т.н. “отдельное приложение”?

Т.е. я просто хочу понять, что “приложение” как таковое является лишь абстракцией выполнения набора команд виртуальной машиной, и одному реальному процессу (PVM) с точки зрения ОС, могут соответствовать N-ое количество т.н. “отдельных приложений” на Python ?

Отредактировано (Ноя. 12, 2011 10:10:39)

XCoder
Т.е. я просто хочу понять, что “приложение” как таковое является лишь абстракцией выполнения набора команд виртуальной машиной, и одному реальному процессу (PVM) с точки зрения ОС, могут соответствовать N-ое количество т.н. “отдельных приложений” на Python ?

Нет. 1 реальный процесс = 1 PVM = 1 скрипт. (Желтые прямоугольники - отдельные процессы, не связанные между собой, работают параллельно, могут работать на разных ядрах)

nginx
. uwsgi (server 1)
. . process
. . . thread
. . . thread
. . process
. . . thread
. . . thread
. uwsgi (server 2)
. . process
. . . thread
. . . thread
. . process
. . . thread
. . . thread

nginx, uwsgi, process - отдельные процессы, причем разные uwsgi запущены (как правило) на разных серверах и сам ngnix может быть на отдельном сервере.
ngnix общается с uwsgi через сокеты.
thread'ы в пределах одного процесса конкурируют за gil.

Не надо думать о python как о неком демоне, у которого есть главный поток и которому передают код на выполнение, а он сам делает форки и т.д.
Вызов питона - это либо запуск программы “python” (например, при использовании CGI), либо вызов функций из библиотеки, которая выполняется в текущем потоке. В любом случае, передается один скрипт на выполнение.

Все, теперь более менее разбрался: nginx -> uwsgi -> 16 PVM = 16 скриптов = (16 * N) тредов, итого под каждый код запуск отдельного процесса PVM.

хм…