Как перезагрузить службу php7.0-fpm / php5.0-fpm
Я являюсь новым пользователем системы Linux и Unix. Я хочу перезагрузить или перезапустить службу PHP-fpm. Как перезапустить PHP-fpm? Как перезапустить php7.0-fpm на сервере Ubuntu Linux 16.04 LTS?
PHP-FPM — это простой и надежный менеджер процессов FastCGI для PHP. Вы можете использовать его с Apache, Nginx и другими веб-серверами. Он включает в себя множество дополнительных функций. Посмотрим, как остановить или перезапустить или перезагрузить PHP-FPM после обновления файла php.ini.
Как отредактировать файл php.ini или www.conf?
Чтобы изменить php.ini:
Чтобы отредактировать файл конфигурации php-fpm:
После редактирования сохраните и закройте файл. Теперь вам нужно запустить команду в соответствии с версией дистрибутива Linux / Unix после редактирования файла.
Запустите php-fpm на CentOS / RHEL 7
Остановить php-fpm CentOS / RHEL 7
Перезагрузить php-fpm CentOS / RHEL 7
Перезапустите php-fpm CentOS / RHEL 7
Запуск / остановка / перезапуск / перезагрузка php-fpm на CentOS / RHEL 6.x или старше
Введите следующую команду:
Как запустить / остановить / перезагрузить / перезапустить php5-fpm (версия php 5.x) на Ubuntu / Debian Linux
ИЛИ, если вы используете дистрибутив на основе systemd, такой как Ubuntu Linux 16.04+ LTS или Debian Linux 8.x +:
Как запустить / остановить / перезагрузить php7.0-fpm (php version 7.x) на Ubuntu / Debian Linux
ИЛИ, если вы используете дистрибутив на основе systemd, такой как Ubuntu Linux 16.04+ LTS или Debian Linux 8.x +:
Bitrix vm перезапустить php
Виртуальная машина сэкономит вам время и силы на правильное развертывание и администрирование вашего сайта или внутреннего информационного ресурса на базе продуктов «1С-Битрикс».
Курс предназначен для администраторов и пользователей продуктов «1С-Битрикс», устанавливающих для ознакомления либо переносящих готовые проекты на виртуальную машину BitrixVM. Аналогичным способом можно переносить проекты с удаленного сайта на виртуальную машину, между виртуальными машинами и т.д. В курсе рассматриваются процедуры установки всех необходимых приложений для работы продукта на виртуальной машине BitrixVM.
Описание установки VMWare Player не входит в данное руководство. По всем вопросам установки этой программы обращайтесь к документации VMWare Player.
На текущий момент рекомендуется к использованию виртуальная машина в версии 7.х. Описания остальных машин оставлены для тех, кто пока не переходит на более совершенную версию.

Android:
EPUB Reader
CoolReader
FBReader
Moon+ Reader
eBoox
iPhone:
FBReader
CoolReader
iBook
Bookmate
Windows:
Calibre
FBReader
Icecream Ebook Reader
Плагины для браузеров:
EpuBReader – для Firefox
Readium – для Google Chrome
iOS
Marvin for iOS
ShortBook
обновляются периодически, поэтому возможно некоторое отставание их от онлайновой версии курса.
Bitrix vm перезапустить php
Виртуальная машина сэкономит вам время и силы на правильное развертывание и администрирование вашего сайта или внутреннего информационного ресурса на базе продуктов «1С-Битрикс».
Курс предназначен для администраторов и пользователей продуктов «1С-Битрикс», устанавливающих для ознакомления либо переносящих готовые проекты на виртуальную машину BitrixVM. Аналогичным способом можно переносить проекты с удаленного сайта на виртуальную машину, между виртуальными машинами и т.д. В курсе рассматриваются процедуры установки всех необходимых приложений для работы продукта на виртуальной машине BitrixVM.
Описание установки VMWare Player не входит в данное руководство. По всем вопросам установки этой программы обращайтесь к документации VMWare Player.
На текущий момент рекомендуется к использованию виртуальная машина в версии 7.х. Описания остальных машин оставлены для тех, кто пока не переходит на более совершенную версию.

Android:
EPUB Reader
CoolReader
FBReader
Moon+ Reader
eBoox
iPhone:
FBReader
CoolReader
iBook
Bookmate
Windows:
Calibre
FBReader
Icecream Ebook Reader
Плагины для браузеров:
EpuBReader – для Firefox
Readium – для Google Chrome
iOS
Marvin for iOS
ShortBook
обновляются периодически, поэтому возможно некоторое отставание их от онлайновой версии курса.
Обновление PHP в окружении BitrixVM с использованием Docker
Введение
В данной статье я бы хотел рассмотреть проблему обновления PHP в виртуальной машине BitrixVM, и действия, которые возможно применить если выполнение переезда на машину с обновленным ПО невозможно. Надеюсь, что статья будет полезна для вас.
Предыстория
Несколько месяцев назад перед нами встала задача обновления PHP до версии 7.4 на одном из наших проектов. Проект был расположен внутри виртуальной машины с развернутой на ней BitrixVM версии 7.2.2. Заглянув в меню Битрикс при обращениях к скрипту /root/menu.sh было обнаружено, что обновление PHP невозможно без обновления Битрикс окружения. При этом само обновление окружения выполняется из бета репозиториев, так как текущая стабильная версия не поддерживала работу с PHP версии 7.4 согласно курсу:
Прошерстив форумы Битрикс, мы не нашли конкретного ответа, когда будет выполнено обновление BitrixVM до стабильной версии с поддержкой с PHP 7.4. В связи с чем, нами было принято решение обновить версию окружения до актуальной беты на одном из виртуальных серверов разработки, предварительно сделав snapshot.
Проблема BitrixVM в том, что это готовое решение, использующее Ansible скрипты для выполнения операций. При этом в случае нарушения работы скрипта операция будет прервана, а идентифицировать ошибку крайне сложно, как и понять на какой именно стадии она возникла.
BitrixVM хранит лог выполняемых задач по пути /opt/webdir/temp/, в ходе выполнения обновления окружения в логе возникали различные ошибки, вызывавшие нарушение процесса обновления. Поиск и решение подобных ошибок занимало достаточный период времени. Как пример, возникали ошибки подключения репозитория:
Второй проблемой было то, что в случае если обновление из Бета репозиториев было выполнено неудачно и нарушало работу проекта, скрипты BitrixVM не предусматривают откат до стабильной версии, согласно информации:
Обратного отката установленной бета-версии к текущей стабильной нет, т.е если вы перешли, например, на бету 7.4.13, то вернуться к стабильной 7.4.4 нельзя. В этом случае чтобы перейти на стабильную версию, нужно дождаться релиза стабильной версии, новее беты, или установить стабильную версию заново. Например для бета-версии 7.4.13, нужно ждать стабильную версию 7.5.
В нашем случае обновление несколько раз проходило неудачно, нарушалась работа всех сервисов, при этом идентифицировать проблему было крайне сложно в виду отсутствия подробного логирования, из-за чего приходилось откатывать состояние виртуальной машины из собранного ранее снэпшота.
Когда обновление до Бета версии прошло удачно, всплыла проблема при разворачивании новой версии PHP. Ansible роли виртуальной машины Битрикс предусматривают откат до предыдущей версии PHP, для этого в меню виртуальной машины есть, например следующие пункты:
Однако на тестовом стенде мы также тестировали откат до предыдущих версий, эти операции также завершались различными ошибками. Ниже пример одной из них:
После нескольких часов работ и восстановлений состояния виртуальной машины из снэпшота, было принято решение отказаться от обновления окружения BitrixVM и развернуть отдельный сервер под управлением ОС Debian по общим стандартам с требуемым ПО. И выполнить переезд проектов на него. От себя хочу добавить, что данный вариант, при выполнении работ по обновлению BitrixVM, считаем оптимальным, а именно переезд на новый сервер, либо с уже установленной новой версией BitrixVM, на борту, или на новый сервер под управлением другого дистрибутива Linux.
После задача была закрыта и проект работал в штатном режиме. Однако, буквально через несколько месяцев перед нами вновь встала задача обновления PHP до версии 7.4 для BitrixVM, в этот раз с CRM Битрикс24 на борту. Ситуация усложнялась тем, что обновление необходимо было выполнить в течении нескольких дней, а сам сервер располагался физически в офисе заказчика, что означало для нас невозможность переезда на новую инфраструктуру в кратчайшие сроки.
Битрикс24 это CRM система, которая предполагает большой объем данных БД, что также усложняло переезд и сильно било по стоимости новой инфраструктуры. При этом проект, на котором необходимо было выполнить работы не предусматривал какого либо резервного контура.
Времени на детальное составление плана не было, первоначальным вариантом было выполнить обновление стандартными средствами Битрикс при этом на случай появления проблем, решить которые не удастся, использовать lvm snapshot для отката состояния сервера.
Также рассмотрен вариант разворачивания Docker контейнера c необходимой версией PHP7.4 и настроенный для работы с BitrixVM. Данный вариант показался для нас более выгодным, так как исключал все потенциальные проблемы, которые могли возникнуть при обновлении BitrixVM, а также предусматривал минимальный простой в работе проекта (в последствии простой был, однако он составил не более 5 минут, это то время, которое потребовалось для переключения Nginx для работы с Apache2 в контейнере).
Имея большой опыт работы с Docker мы не видели проблемы в разворачивании контейнера, также в отличии от BitrixVM, с Docker мы могли полностью контролировать процесс обновления, а в случае появления проблем изучать логи Apache в контейнере и сервисов установленных на сервере, которые более информативны, чем логи Ansible ролей виртуальной машины Битрикс. После небольших консультации внутри команды было принято решение развернуть контейнер. На сервере была установлена БитриксВМ 7.3.4, под управлением Centos7.4. Данные работы будут описаны в статье ниже. Я постарался максимально подробно описать проделанные нами шаги, для тех, кому это решение окажется полезным. Также в конце статьи будет приложена ссылка на github с конфигурацией контейнера.
Ход работ
Перед началом работ ставим пакеты docker-ce, docker-ce-cli, containerd.io для Centos7 согласно инструкции:
После устанавливаем docker-compose (на момент публикации статьи актуальной версией является 1.29.2):
Подготавливаем docker-compose файл где описываем контейнер. Контейнер был собран но основании php:7.4-apache, в Dockerfile были включены все необходимые PHP модули. За основу виртуального хоста Apache был взят оригинальный файл BitrixVM, с небольшими правками, учитывающими работу в контейнере. В частности, вам придется указать AssignUserId в конфигурации виртуального хоста Apache, в виду отсутствия пользователя bitrix в контейнере. Добавлю, что apache2 в нашем случае работает с модулем mpm_prefork настройки для которого также прокинуты в контейнер.
Для корректной работы в docker-compose файле потребуется прокинуть в контейнер стандартные директории площадки для bitrix. В целом блок volumes в нашем варианте выглядит следующим образом:
Логи apache2 для площадки были прокинуты на сервер в стандартную директорию, что также учтено в виртуальном хосте:
Логи самого apache2 в контейнере расположены в /volumes/var/log/apache2.
Также потребуется внести ряд правок в php.ini и прокинуть файл в контейнер, эти шаги я опишу ниже, в рамках части про Битрикс оптимизацию.
Для решения проблем с правами необходимо добавить в описание контейнера в docker-compose строки:
Для удобства указания общения контейнера с сервером присваиваем ему IP:
и настраиваем сеть:
После потребуется добавить подсеть docker контейнера в список разрешенных для фаервола, в нашем случае правила выглядят так:
Для корректной отправки почты, необходимо будет настроить почтовый сервер таким образом, что бы он мог принимать и ретранслировать почту отправленную из контейнера. В нашем случае для отправки почты использовался exim настроенный для работы в режиме smarthost, поэтому потребовалось добавить адрес контейнера (172.24.1.4) в следующие строки:
Битрикс оптимизация
После того как контейнер был готов и запущен, перед переключением площадки необходимо было провести Битрикс оптимизацию, то есть устранить все ошибки в тестировании конфигурации. От себя добавлю, что до переноса в контейнер ошибок в тестировании конфигурации не было.
Для решения этих задач была создана отдельная тестовая площадка на основном сервере, в которую был помещен установочный скрипт Битрикс. Площадка развернута через стандартное меню Битрикс /root/menu.sh.
Для тестовой площадки настраиваем проксирование на уровне Nginx в контейнер, потребуется изменить переменную proxyserver в файлах виртуального хоста площадки.
После прокидываем созданный скриптом Битрикс виртуальный хост для apache2 в контейнер, при этом обязательно указываем UID пользователя Bitrix:
В нашем случае apache2 работает на стандартном 80 порту в контейнере, поэтому в виртуальном хосте указываем:
После внесения всех этих изменений переходим в административную панель тестовой площадки, а далее заходим в Проверка системы > Тестирование конфигурации. В первую очередь всплывет ошибка работы с сокетами, для ее решения прописываем в docker-compose.yml параметр extra_hosts, указав внешний IP сервера и доменное имя площадки:
Перезапускаем контейнер. Также для корректной отправки почты, потребуется указать в настройках PHP sendmail_path:
Прохождение проверки отправки почты внутри административной панели Битрикс еще не означает, что ваше письмо будет доставлено, поэтому рекомендуем также выполнить самостоятельную отправку письма c помощью скриптов площадки, а после проверить наличие письма в почтовом ящике и логи почтового сервера.
Остальные настройки стандартны и выполняются также как, если бы контейнера не было. Поэтому я не стану на них подробно останавливаться, достаточно сказать, что в настройках PHP должны присутствовать параметры:
Дополню, что в случае использования контейнера с Битрикс24 будет всплывать предупреждение вида:
Ошибка! Для гарантированной работы «1С-Битрикс24» необходимо его устанавливать на веб-окружении Битрикс, у вас используется собственное серверное окружение.
Предупреждение можно обойти, указав актуальную версию в виде переменной в скриптах Битрикс. В случае если вы используете продукт Управление сайтом, данного предупреждения не будет.
Также вы можете выполнить тестирование производительности конфигурации и анализ площадки с помощью сканера безопасности. В нашем случае цифры в тестировании конфигурации были практически идентичны как в случае с контейнером, так и без него.
После того, как оптимизация для тестовой площадки будет выполнена, возможно будет приступить к переключению основной площадки для работы в контейнере, при этом учесть все шаги, проделанные в рамках тестовой оптимизации ранее.
Заключение
Целью данной статьи не является пропаганда такого решения, оно будет полезно тем, кому жизненно важно обновление PHP на текущем этапе работы проекта, при этом нет возможности переехать на новую инфраструктуру, а также нет уверенности в том, что обновление Битрикс из бета репозиториев пройдет гладко.
BitrixVM является простым в установке решением, однако в случае администрирования кастомной конфигурации решение проблем и проведение каких-либо обновлений проходит сильно проще.
Для удобства выложили конфигурацию нашего контейнера на GitHub, вы всегда можете ознакомится с ней по мере необходимости. Там же расположен отредактированный виртуальный хост площадки, все вносимые в PHP и Apache2 настройки и docker-compose.yml.
В заключении от себя хочется сказать, что в процессе администрирования мы видим больше минусов, чем плюсов в разворачивании BitrixVM в качестве окружения, в частности это связано со следующими пунктами:
Сложность внесения каких-либо настроек в систему и установки нового ПО. Запутанность файлов конфигураций ПО в BitrixVM, а также использование ansible-скриптов для управления сервером через меню с псевдографическим интерфейсом приводит к тому, что внесение даже самых элементарных настроек требует большого количества времени со стороны администраторов, которое уходит именно на то, чтобы понять где именно необходимо внести данные изменения, чтобы в дальнейшем они не были перезаписаны ansible-скриптами, а так же не имели негативного влияния на работу других элементов системы.
В случае возникновения каких-либо проблем на сервере, на анализ и устранения причин неисправности уходит намного больше времени, чем при разборе ситуаций на кастомной настройке. В виду плохо настроенной системы логирования.
Также как показывает наш опыт, интеграция со сторонними сервисами в случае с BitrixVM зачастую очень сложна или невозможна.
Из плюсов такого решения могу отметить то, что конфигурация BitrixVM проста в первоначальной настройке. Однако рекомендовать это решение, можно разве что для простых проектов.
В очередной раз пришлось повозиться с настройкой Bitrixenv и сайта на нем. В какой-то момент bitrix сайт стал сыпать 500-е ошибки на некоторые операции. По логам было видно, что не хватает памяти для работы некоторых скриптов, хотя раньше хватало. Пришлось заняться расследованием и оптимизацией потребления памяти bitrix сайтом.
Цели статьи
Введение
Разработчики bitrixenv упростили работу системных администраторов по настройке сервера, внедрив службу bvat, которая автоматически при запуске сервера подбирает оптимальные параметры следующих служб:
Настройки будут зависеть от количества доступной оперативной памяти. В целом, это неплохой шаг, который упрощает начальную настройку сервера. Чаще всего конфигурация служб получается адекватной и подохдящей для типовых сайтов.
В моем случае стандартные настройки перестали подходить. На сервере время от времени появлялась нехватка оперативной памяти. Приходил OOM Killer (OOM — Out of memory) и грохал mysql сервер, так как он потреблял больше всего оперативной памяти. Какое-то время все работало нормально, потом провторялось то же самое.
Мое внимание привлекли события из мониторинга Zabbix, такие как Lack of available memory on server. Посмотрел график и все сразу стало ясно, еще до подключения к серверу.
Зашел на сервер, посмотрел системный лог. Увидел там вот это:
План дальнейшей настройки сервера для стабильной работы сайта на bitrix следующий:
Изменение стандартных настроек BitrixVM
Как я уже говорил, служба bvat автоматически регулирует некоторые настройки стандартных служб bitrixenv. Чтобы применять наши настройки, нужно их указывать в отдельных конфигурационных файлах.
А вот общий список всех основных конфигурационных файлов bitrixenv:
Оптимизация настроек Mysql
На подопытном сервере имеется 12 Гб оперативной памяти. Я решил половину этой памяти отдать под mysql. Приступим к тюнингу конфигурации mysql. В общем случае достаточно будет одного параметра, который в основном отвечает за потребление памяти:
Итак, копируем себе на сервер сам скрипт:
Для того, чтобы рекомендации получились более эффективные, служба mysql должна поработать у вас несколько дней. Если накануне перезапускали ее, а я это делал, то рекомендую через несколько дней зайти и еще раз прогнать тесты. Будут новые советы по конфигу.
Для оптимизации потребления памяти, достаточно будет прогнать скрипт в любое время. Я вам рекомендую внимательно изучить его возможности. Подробно на них я сейчас не буду останавливаться, а рассмотрю только то, что касается памяти. Помимо прочего, вы увидите следующую информацию.
У меня уже все оптимизировано под потребленее не более примерно 6 Гб памяти. Расскажу, какие параметры за это отвечают. Как уже сказал ранее, это параметр innodb_buffer_pool_size. В общем случае для mysql сревера рекомендуют указывать этот параметр равный 80% доступной памяти сервера. Но это в том случае, если у вас кроме mysql на этом сервере ничего не крутится. А у нас там полно других служб, поэтому нам такой совет не подходит.
Параметр read_buffer_size установлен по-умолчанию в 128 КБ. Я его не стал трогать. Остальные два я изначально выставил по рекомендациям mysqltuner, а значение max_connections, которое отвечает за максимальное количество подключений, выставил такое, чтобы сумма трех буферов, помноженная на количество подключений не превышала 2 Гб памяти. Сервер немного поработал в таком режиме и выяснилось, что выставленных подключений не хватает. Тогда я снизил join_buffer_size до 18 Мб, а количество подключений увеличил. В итоге остановился на таких настройках.
С такими настройками максимальное потребление памяти службой mysql не будет превышать 6.8 Гб, о чем подсказывает вывод mysqltuner. Конкретно моему сайту 70 подключений к mysql достаточно. До этого поставил 50, были сообщения о нехватке подключений. На своем сервере выбирайте параметры сами, у меня не копируйте.
На практике так и получилось. Через несколько дней я зашел и прогнал еще раз проверку, которая показала, что реально использование памяти не вышло за эти пределы. Плюс, подредактировал некоторые параметры.
Приведу список основных параметров mysql, которые влияют на производительность и на которые надо в первую очередь обращать внимание:
Список взял отсюда. Очень полезная статья, рекомендую.
Оптимизация настроек apache в bitrixenv
Чтобы узнать, количество запущенных процессов httpd, обслуживающих работу bitrix сайта, введите в консоли сервера команду:
Вы получите число, на 2 больше, чем указано в приведенном конфиге, в параметрах модуля mpm_prefork. В моем случае bvat выставлял максимально возможное количество процессов httpd равное 60, но для меня это было слишком много, сервер не тянул такое количество процессов. Я его уменьшил до 30.
Привожу скриншотом, потому что движок сайта проглатывает все строки в угловых скобках. Не получается выложить полностью конфиг в текстовом виде. В общем случае, вам надо посмотреть, сколько у вас занимает памяти один процесс httpd и рассчитать максимальное количество процессов, которое потянет ваш сервер.
Посмотреть, сколькло памяти занимает один процесс httpd можно в htop или с помощью команды:
Будет один основной процесс, который занимает больше всего памяти и дальше его форки, которые потребляют примерно одинаково. На них и ориентируйтесь. У меня основной процесс потребляет 500 Мб и 30 форков по 100 Мб. В сумме получается 3.5 Гб.
Итого в пике у меня 6.5 Гб использует mysql и 3.5 Гб использует httpd, итого 10 Гб из доступных 12-ти. На практике, свободной памяти обычно больше, чем 2 Гб, так как mysql чаще всего потребляет ниже максимального предела.
Оптимизация php под bitrix
Из настроек php я бы обратил внимание на следующие параметры:
Так или иначе, эти параметры, кроме sendmail, влияют на производительнойсть сервера и потребление памяти. Не ставьте эти значения слишком большими без особой надобности. Я бы для начала выставил в 256 Мб и увеличивал по мере необходимости. Да, 256 Мб это и так очень много, но сайт на bitrix требует высоких значений этих параметров для корректной работы. 256 мб это общая рекомендация для дефолтных значений.
Настройка nginx для сайта bitrix
В самом nginx в bitrixenv настраивать для производительности особо нечего. Он работает в качестве proxy сервера для apache. С помощью proxy_pass он перенаправляет все динамические запросы, а сам отдает только статику. В таком режиме работы он потребляет минимум ресурсов и оптимизировать в нем нечего. Если вам все же интересно разобраться в настройках nginx, то читайте мою отдельную подробную статью.
Отдельной настройки требует только модуль Push and Pull, если он у вас используется. Его конфигурация располагается в файле /etc/nginx/bx/conf/push-im_settings.conf. В контексте данной статьи нас интересует только параметр push_stream_shared_memory_size, который отвечает за использование оперативной памяти.
В принципе, дефолтного значения 256 Мб обычно хватает, хотя по сути это небольшие цифры. Но имейте ввиду, что если свободной памяти совсем нет, то можно подрезать этот параметр.
Заключение
После оптимизации всех указанных выше параметров в bitrixenv, потребление памяти сервером стабилизировалось. Bitrix сайт стал работать ровно с предсказуемой производительностью без неожиданных тормозов и падений.
На этом у меня все по теме оптимизации настроек сервера под bitrix. Система интересная и многогранная. Всегда любопытно заглянуть под капот bitrixenv. Как по мне, сделано неплохо, хотя и доставляет хлопот при разборе каких-то иницидентов.
В целом считаю, что в общем случае, все сделано удобно и функционально для быстрого запуска bitrix сайта. Справится даже неподготовленный человек, а конкретно какой-нибудь программист. Он бы запарился настраивать эту связку самостоятельно, а тут все из коробки работает. Но вот если возникают проблемы, то разобраться бывает не всегда просто.
Следующим этапом жду появление docker сборок с bitrixenv внутри. Либо один общий образ, либо набор через docker-compose. Это было бы логичное продолжение развития в свете популярности контейнеров и микросервисов.





