Bug 49714
| Summary: | Сборка php-cgi (PHP 7, 8.1, 8.2) | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Branch p10 | Reporter: | Анатолий Кирсанов <kiav1976> | ||||||
| Component: | php-base | Assignee: | Anton Farygin <rider> | ||||||
| Status: | CLOSED FIXED | QA Contact: | qa-p10 <qa-p10> | ||||||
| Severity: | normal | ||||||||
| Priority: | P5 | CC: | rider | ||||||
| Version: | не указана | ||||||||
| Hardware: | x86_64 | ||||||||
| OS: | Linux | ||||||||
| Attachments: |
|
||||||||
расскажите, пожалуйста, подробнее про сценарии использования php-cgi. С момента отключения сборки этого SAPI прошло очень много времени и мне казалось что все уже давно перешли на FCGI интерфейс. (Ответ для Anton Farygin на комментарий #1) > расскажите, пожалуйста, подробнее про сценарии использования php-cgi. Стандартный WEB-сервер не для разработки. nginx -> Apache -> fcgid_module -> PHP nginx, как обычно, отрабатывает статику и https. Apache нужен для фрейморков и CMS, накарябанных с ним в мозгу. Они могут работать (и работают) на голом nginx + php-fpm. Но всегда есть беспокойство, что ты вылез на площадь с голым задом и кто-то пристраивается. Лучше в данной ситуации делать на том, что к чему приспособлена выбранная систему управления сайтом. Также Apache дает возможности по настройкам, от кторых не хочется отказываться. Они более привычны и удобны. fcgid_module удобный менеджер процессов, который интегрирован с Apache. Просто с php-fpm я дело имел. Не нравится. На безрыбье работать можно, но если есть другие варианты - лучше не трогать. Это уже вкусовщина. Но именно она определяет разнообразие решений. (Ответ для Anton Farygin на комментарий #1) > С момента отключения сборки этого SAPI прошло очень много времени и мне > казалось что все уже давно перешли на FCGI интерфейс. Думаю, дело в том, что на Альте не разворачивали WEB-серверов в достаточном количестве. Он позиционируется как офисный сервер. Время идет, есть попытки приспособить Альт для чего-то еще. В том числе и так https://www.ispmanager.ru/community/feature-request-177 (это мои проделки). А пока - ручные настройки (в них тоже есть свой шарм). В пакетной базе у вас актуальный Apache, fcgid_module (несмотря на его возраст). И PHP более-менее актуальные. Более того, намного лучше других дистрибутивов, т.к. есть не только самая-самая (ну почти ...) но и несколько последних (только 8.0 пропустили). Это крайне актуально для сайтостроителей. Где-то фреймворк пока не переваривает свежую версию, где-то не собирается даже, а где-то идет миграция, которая может занимать длительное время. Что "все перешли" я не уверен. Иначе бы не было "в других дистрибутивах" этого SAPI. (Ответ для Anton Farygin на комментарий #1) > все уже давно перешли на FCGI интерфейс. Забыл совсем. Я написал зачем нужна сборка php-cgi. А про FastCGI забыл. Сборка только так называется, поддерживает она FastCGI, если собрать с правильным ключом. Я ориентировался на статью https://stackoverflow.com/questions/12153518/connection-reset-by-peer-mod-fcgid-error-reading-data-from-fastcgi-server Там сказано, что если сконфигурить с параметром --enable-fastcgi Тогда получил на php-cgi -v ответ: PHP 5.2.17 (cgi-fcgi) (built: Jul 9 2013 18:28:12) Copyright (c) 1997-2010 The PHP Group Zend Engine v2.2.0, Copyright (c) 1998-2010 Zend Technologies (пример там для PHP 5) Важно здесь, что в скобках указано - (cgi-fcgi) А именно CGI в нем собирали другим ключом конфигурации. Я тоже не знаю зачем это сейчас нужно в массах. Был один случай с одним хостером. Они не могли иначе и подключили именно CGI. Больше такого не припомню. Сейчас этот SAPI собирают для FastCGI. В той статье накарябано "If this is enabled, the CGI module will be built with support for FastCGI also. Available since PHP 4.3.0" Это про --enable-fastcgi. так я всё-таки не понял чем php-cgi собранный с ключём fcgi лучше привычного уже решения - php-fpm fcgi (Ответ для Anton Farygin на комментарий #5) > так я всё-таки не понял чем php-cgi собранный с ключём fcgi лучше привычного > уже решения - php-fpm fcgi Менеджер процессов другой. Он работает. Чтобы точно сказать в чем именно дело, нужно снова настроить php-fpm. Если не копаться в воспоминаниях, то вспомнить можно про единый пул процессов в fcgid_module для всех пользователей (я о лимитах количества). При желании, можно сделать как у php-fpm (для каждого пользователя свой), но у меня такого желания, как раз и нет. А так, можно было бы копнуть классы приложений fcgid_module. Т.е. для слабеньких серверов лучше будет fcgid_module (для WEB-серверов они всегда таковы, если смотреть на нагрузку - резерва по железу нет практически всегда). Он не держит в резерве процессы в таком количестве, как php-fpm. И управляется проще. Ну а fcgid_module, раз он сам менеджерит процессы, работает не с php-fpm, а с php-cgi (собранным с поддержкой FastCGI). Так уже больше 10 лет делают. Он тоже привычный. Либо надо убирать из пакетной базы fcgid_module (правда, он может использоваться не только для php). А то мало ли как он собран. Может он в Альте не работает, как это было в свое время с php-cgi в https://bugzilla.altlinux.org/13332 А попробуйте, пожалуйста: https://packages.altlinux.org/ru/tasks/343013/ - Sisyphus https://packages.altlinux.org/ru/tasks/343014/ - p10 но это сборка для Sisyphus. Если всё заработает как ожидается - соберу для всех поддерживаемых версий. (Ответ для Anton Farygin на комментарий #7) > А попробуйте, пожалуйста: > https://packages.altlinux.org/ru/tasks/343014/ - p10 Похоже, еще собирается. В отдельных задачках я новичок. # apt-repo list rpm [p10] http://ftp.altlinux.org/pub/distributions/ALTLinux p10/branch/x86_64 classic rpm [p10] http://ftp.altlinux.org/pub/distributions/ALTLinux p10/branch/noarch classic rpm [p10] http://ftp.altlinux.org/pub/distributions/ALTLinux p10/branch/x86_64-i586 classic # apt-repo add task 343014 # apt-repo list rpm [p10] http://ftp.altlinux.org/pub/distributions/ALTLinux p10/branch/x86_64 classic rpm [p10] http://ftp.altlinux.org/pub/distributions/ALTLinux p10/branch/noarch classic rpm [p10] http://ftp.altlinux.org/pub/distributions/ALTLinux p10/branch/x86_64-i586 classic rpm http://git.altlinux.org repo/343014/x86_64 task # apt-get update Пропущено http://git.altlinux.org repo/343014/x86_64 release Получено: 1 http://ftp.altlinux.org p10/branch/x86_64 release [4223B] Получено: 2 http://ftp.altlinux.org p10/branch/noarch release [2844B] Получено: 3 http://ftp.altlinux.org p10/branch/x86_64-i586 release [1665B] Получено 8732B за 0s (45,2kB/s). Получено: 1 http://ftp.altlinux.org p10/branch/x86_64/classic pkglist [23,9MB] Ошибка http://git.altlinux.org repo/343014/x86_64/task pkglist 404 Not Found Пропущено http://git.altlinux.org repo/343014/x86_64/task release Получено: 2 http://ftp.altlinux.org p10/branch/x86_64/classic release [137B] Получено: 3 http://ftp.altlinux.org p10/branch/noarch/classic pkglist [7175kB] Получено: 4 http://ftp.altlinux.org p10/branch/noarch/classic release [137B] Получено: 5 http://ftp.altlinux.org p10/branch/x86_64-i586/classic pkglist [17,5MB] Получено: 6 http://ftp.altlinux.org p10/branch/x86_64-i586/classic release [142B] Получено 48,5MB за 5s (8749kB/s). E: Failed to fetch http://git.altlinux.org/repo/343014/x86_64/base/pkglist.task 404 Not Found E: Some index files failed to download. They have been ignored, or old ones used instead. Пакет объявился в 23:05. ввел в заблуждение сайт, который в блоке статистики показывал в строке Собрано значение 1. Пока так: # rpm -ql php8.2-cgi /etc/php/8.2/cgi-fcgi /etc/php/8.2/cgi-fcgi/browscap.ini /etc/php/8.2/cgi-fcgi/php.d /etc/php/8.2/cgi-fcgi/php.ini /usr/bin/php-cgi-8.2 /usr/share/doc/php8.2-cgi-8.2.16 /usr/share/doc/php8.2-cgi-8.2.16/CREDITS [root@vds2 ~]# php-cgi-8.2 -v PHP Warning: Cannot open "/etc/php/8.2/cgi/browscap.ini" for reading in Unknown on line 0 PHP Fatal error: Unable to start standard module in Unknown on line 0 С тестовой сборкой можно и выкрутиться. # ln -s /etc/php/8.2/cgi-fcgi /etc/php/8.2/cgi # php-cgi-8.2 -v PHP 8.2.16 (cgi-fcgi) (built: Mar 18 2024 17:24:35) Copyright (c) The PHP Group Zend Engine v4.2.16, Copyright (c) Zend Technologies Собрано как надо. Created attachment 15709 [details]
PHP 8.2.16 - phpinfo()
Попробовал. Настройки из /etc/php/8.2/cgi-fcgi/php.ini принимает (менять можно, значит правда оттуда берет). Но модулей практически нет. Как пример, GD, Free Type, SSL, mbstring, MySQL (mysqli). Это то, что бросается в глаза. ZTS для fcgid_module не требуется. В нем на один процесс обязан приходиться один поток. В целом, работает. Для полноценного тестирования мне нужно начинать с PHP 7.4. Там и модули помогут. Для 8.2 у меня будет что-то готово через 7.4 и 8.1. Насчет browscap все оказалось просто. Именно для запуска в FastCGI это не очень важно (phpinfo не валится). Эта болячка зашита в /etc/php/8.2/cgi-fcgi/php.ini: [browscap] ; https://php.net/browscap browscap = "/etc/php/8.2/cgi/browscap.ini" Символическую ссылку удалил. Не нужна она. по идее должно подхватывать модули из системы. проверьте, работает ли ? У нас модули пакуются в отдельные пакеты, подходящие сразу для всех SAPI. Ошибки я сейчас поправлю. поправил задание - теперь собрано для всех поддерживаемых версий php (для 7-й версии не ждите сборку). можно проверять: https://packages.altlinux.org/ru/tasks/343014/ (Ответ для Anton Farygin на комментарий #13) > по идее должно подхватывать модули из системы. проверьте, работает ли ? > У нас модули пакуются в отдельные пакеты, подходящие сразу для всех SAPI. Да, работает. Проверил на пакете php8.2-opcache. # rpm -ql php8.2-opcache /usr/lib64/php/8.2.16/extensions/opcache.so /usr/share/php/8.2/extconf/opcache /usr/share/php/8.2/extconf/opcache/config /usr/share/php/8.2/extconf/opcache/params Конфига /etc/php/8.2/cgi-fcgi/php.d/opcache.ini в пакете нет, а в системе после установки он есть и php-cgi его подхватывает (phpinfo). Похоже на волшебство, видна большая работа. Волшебство это, судя по всему, создано postinstall скриптом в пакете с модулем, а этот скрипт использует в своем брюхе /usr/share/php/scripts/php_postin.sh. В нем весь интеллект и он отработал успешно. Фокус здесь в том, что модули нужно ставить после установки всех SAPI. Не проверял, но по коду видно. (Ответ для Anton Farygin на комментарий #14) > ... (для 7-й версии не ждите сборку). > https://packages.altlinux.org/ru/tasks/343014/ Жаль. Тогда с проверкой удаляюсь на пару недель очень активной работы. Мне нужно настроить времянку на php-fpm 7.4 с mod_proxy для Apache. Просто, чтобы дотянуть софт до минимально поддерживаемой Альт версии php-cgi. Wordpress 5 не знаю пока что потребует. Битрикс 17 может пройти легко, а может потребовать PHP 7.3 для начала. А Piwik 2.18 может потребовать массу коротких обновлений и проведет через 5.6, 7.3, 7.4 ... Этот "тип" не любит обновляться сразу на много. На него в этом тесте я не рассчитывал, пишу для иллюстрации как бывает (с Piwik я почти сразу понял, что потребуется сторонний сервер с ISPManager и древними версиями PHP). Хорошо, тогда я текущий результат отправляю в репозиторий, он будет проходить тестирование и когда провалится в репозиторий - пакеты станут доступны уже без сборочного задания. Только смущает OPcache в phpinfo(): Zend OPcache Opcode Caching Disabled Optimization Disabled SHM Cache Enabled File Cache Disabled JIT On Startup Failed Opcode Caching is only supported in Apache, FPM, FastCGI, FrankenPHP, LiteSpeed and uWSGI SAPIs Подобная ситуация уже была в https://bugzilla.altlinux.org/30496 Но тогда строка cgi-fcgi бала в массиве supported_sapis. Что сейчас надо - непонятно. В основном блоке phpinfo (он есть в приложенном скриншоте) сказано: Server API CGI/FastCGI Модуль opcache установлен и загружен? https://packages.altlinux.org/ru/p10/srpms/php8.2-opcache/ (Ответ для Anton Farygin на комментарий #18) > Модуль opcache установлен и загружен? > https://packages.altlinux.org/ru/p10/srpms/php8.2-opcache/ # rpm -qi php8.2-opcache Name : php8.2-opcache Version : 8.2.16 Release : alt1.2 DistTag : p10+325159.4200.2.1 Architecture: x86_64 # ls -l /usr/lib64/php/8.2.16/extensions итого 996 -rw-r--r-- 1 root root 1018368 фев 19 12:19 opcache.so В phpinfo: Additional .ini files parsed /etc/php/8.2/cgi-fcgi/php.d/opcache.ini extension_dir /usr/lib64/php/8.2.16/extensions В /etc/php/8.2/cgi-fcgi/php.d/opcache.ini zend_extension=opcache.so opcache.enable = 1 opcache.enable_cli = 1 (это все умолчания, ничего не трогал) Но в phpinfo: Opcode Caching Disabled Optimization Disabled SHM Cache Enabled File Cache Disabled JIT On Startup Failed Opcode Caching is only supported in Apache, FPM, FastCGI, FrankenPHP, LiteSpeed and uWSGI SAPIs Created attachment 15711 [details]
Параметры OPCache когда он не доступен
Нашёл ошибку в сборке php-opcache, там остался старый патч с переименования cgi-fcgi SAPI в cgi Ждите обновления php и модулей для поддерживаемых версий. php 8.2 с исправлением opcache и cgi пошло на сборку. https://packages.altlinux.org/ru/tasks/343141/ (Ответ для Anton Farygin на комментарий #22) > php 8.2 с исправлением opcache и cgi пошло на сборку. > https://packages.altlinux.org/ru/tasks/343141/ Спасибо. Теперь OPcache доволен Opcode Caching Up and Running Optimization Enabled SHM Cache Enabled File Cache Disabled JIT Disabled Startup OK Более подробное тестирование мне придется продолжить уже с 8.0. Свежий WordPress поддерживает частично (“compatible with exceptions”) 8.0 и 8.1, а 8.2 и 8.3 - в бете. Полностью он поддерживает сейчас только 7.4. Битрикс точно взлетит на 8.1. 8.2. не проверял. Так что времени потребуется достаточно. bitrix точно работает на 8.2, это проверено. несмотря на окончание поддержки апстримом php 8.0 я собрал для него тоже пакеты: https://packages.altlinux.org/en/tasks/343014/ после тестирования нашим qa они попадут в репозиторий. Ковыряю php-cgi 8.2 тестовым скриптом.
Несмотря на memory_limit в php.ini на 256 МБ (вижу в phpinfo(), больше 128 МБ не выделяется.
Никаких ограничений на сервере я не ставил (банально не умею).
Умолчания смотрел.
ulimit -a (просто в терминале)
max memory size (kbytes, -m) unlimited
virtual memory (kbytes, -v) unlimited
По systemctl status вижу, что php-cgi крутится в рамках сервиса httpd2:
CGroup: /
└─system.slice
├─httpd2.service
│ ├─ 9363 /usr/sbin/httpd2 -DFOREGROUND -k start
│ ├─ 9365 /usr/sbin/httpd2 -DFOREGROUND -k start
│ ├─ 9366 /usr/sbin/httpd2 -DFOREGROUND -k start
│ ├─ 9367 /usr/sbin/httpd2 -DFOREGROUND -k start
│ ├─ 9368 /usr/sbin/httpd2 -DFOREGROUND -k start
│ ├─ 9454 /usr/sbin/httpd2 -DFOREGROUND -k start
│ ├─ 10175 /usr/bin/php-cgi-8.2
│ └─ 10183 /usr/bin/php-cgi-8.2
Значит и ограничения должны быть его.
# systemctl show httpd2.service | fgrep Memory
MemoryCurrent=293023744
MemoryAvailable=infinity
MemoryAccounting=yes
DefaultMemoryLow=0
DefaultMemoryMin=0
MemoryMin=0
MemoryLow=0
MemoryHigh=infinity
MemoryMax=infinity
MemorySwapMax=infinity
MemoryLimit=infinity
ManagedOOMMemoryPressure=auto
ManagedOOMMemoryPressureLimit=0
MemoryDenyWriteExecute=no
Смотрел в systemd-analyze cat-config sysctl.d - и там ничего про httpd2 и mod_fcgid.
Таращился в systemd-cgtop. Ничего интересного. Доходит до определенного размера память и все, тест отваливается. При этом из 2ГБ ОЗУ затрачено максимум 1,5. Т.е. есть куда еще идти.
OOM Killer в логе отсутствует.
Везде infinity может вкомпилено ограничение?
Порылся в исходниках php, apache, mod_fcgid. Искал поиском что-нибудь по memory и limit. И нашел только вкомпиленные в сам PHP ограничения по той самой настройке - memory_limit. Там 128 МБ. Изменения в php.ini видны только в phpinfo(). ini_set ничего не дает (хотя ini_get показывает, что я что-то сохранял). Накарябал простейший тестовый скрипт. Он дает память строго до 128МБ. На самом первом хите после перезагрузки httpd2. Так что утечка памяти от нескольких запросов тут исключается. Да и ставил я в тестах один запрос на процесс (получил обычный CGI по скорости). Получается, что php-cgi не видит настройки memory_limit в php.ini и использует только вкомпиленное умолчание. Осталось это как-то подтвердить. Лучше для этого использовать другой тикет (Ответ для Anton Farygin на комментарий #27) > Лучше для этого использовать другой тикет Рано еще. С этой болячкой с ума сойдешь. Работает только так (в скрипте FcgidWrapper): exec /usr/bin/php-cgi-8.2 -n -d memory_limit=512M И никаких опций "-с" с путем до конфига. Ни до опции "-n", ни после. Тем более, никаких отказов от "-n" (подключения любых конфигов, даже если в них нет memory_limit). ini_set('memory_limit', 'XXX') допустим, но должен повторять настройку из опции "-d". Тут фактуру надо собирать - запускать сайты. А то может такая же беда не только с memory_limit. С другой стороны, sendmail_path с нестандартным значением прошла, max_execution_time тоже прошла. Я такой дичи еще не видел. Для отдельного обращения нужно полностью описывать стенд, чтобы его дальше, в апстрим протолкнуть можно было. WordPress на php-cgi-8.0 взлетел. Ничего не редактировал. На просмотр работает, плагины и темы удаляются .... Скорее всего, с 8.0 все в порядке. А если к cgi ходить через nginx, то работает ? (Ответ для Anton Farygin на комментарий #30) > А если к cgi ходить через nginx, то работает ? На php-fpm 7 (тоже с участием Apache, не напрямую от nginx) (мне его развернуть все равно пришлось, как промежуточную точку) я такой болячки с memory_limit не заметил. Обратил на это внимание именно на cgi-fcgi. Я уже не думаю, что это совсем новая проблема. Просто диагностику не провел ранее. А проблема вот в чем - ты запросил в этой настройке 512, получил 256 (при этом, в phpinfo покажет 512). Он выделяет реально места в 2 раза меньше запрошенного. Просто я просил 256 и получал 128, а это совпадает с вкомпиленной настройкой. Не удивлюсь, что болячке много лет и вылезла она с перехода на 64 бита с 32. И происходит недуг при обработке php.ini. Если их нет, а есть только "-d" из командной строки, то выделяется реально именно столько, сколько запросил. Наблюдать еще надо. Тестовый стенд на 32 бита делать. Это надолго. Что касается проверок сборок php-cgi в других аспектах, то вот последние изменения: Провел обновление Piwik (ныне Matomo). Взлетел на PHP 8.2. Версия 7.4 и 8.0 требовались для процедур обновления. С 8.2 есть несовместимости, т.е. они еще до конца софтину не довели. Но несовместимости носят характер предупреждений (надеюсь катастрофы не будет). 8.1 пока не трогал. Думаю, Битрикс захочет с ней поиграть. Там работы много, время потребуется. У нас нет никаких специальных патчей на php в этом месте, поэтому эта старая болячка должна быть на всех вариантах установки php-cgi Нет, Битриксу оказалось достаточно 7.4 и 8.0. php-cgi 8.1 протестировать мне не удалось. Были сомнения насчет Piwik (что нужно откатить на 8.1), но пока они не укрепились. php-cgi для разных версий php уже в p10. |
Description
Анатолий Кирсанов 2024-03-15 19:38:28 MSK