Mysqltuner bitrix Улучшена производительность CMS Битрикс

В данный момент CMS «Битрикс» рекомендует своим пользователям обновить версию PHP до 7.4+.  В инструкции мы рассмотрим, как это сделать.

Доброго времени суток, уважаемые хабровчане.

Сегодня речь пойдет опять и снова про mySQL. Разберемся в оптимизации и поговорим про множество параметров сервера.
Давайте приступать.

Расскажем, что нужно делать системному администратору для сопровождения сервера с коробочной версией Битрикс24. На что нужно регулярно обращать внимание, куда смотреть в случае возникновения проблем и что делать, если всё сломалось.

Если вы задумались о повышении производительности вашего сайта на CMS Битрикс, в первую очередь необходимо перенести сайт на сервер с Bitrix7. с системой Bitrix7 можно в вашей панели управления.

Вы можете выполнить перенос самостоятельно или обратиться к нашим специалистам. Все подробности можно найти в статье Перенос сайта на сервер

Начало

Сервер у нас пусть будет на ​ CentOS​. Оптимизировать будем методом правки конфига ​my.cnf​ .

Настройка некоторых параметров может повысить
производительность БД сервера в несколько раз!

Для начала давайте определимся, что мы вообще оптимизируем — т.е сколько каких таблиц на каком движке имеем, какая железка у нас есть и под какие параметры мы будем всё это дело подгонять.
Для этого возьмем ​ htop​ (как красивый и наглядный инструмент):

yum install htop

Выведем ​ htop​ :

Получаем нечто такое:
Запишем себе в ​my.cnf​:

# 3 ядра, 4гб оперативной памяти

Теперь давайте узнаем количество таблиц и их типы.
Для этого возьмем ​mysql tuner​:

Запишем себе в ​my.cnf:

# 64M myisam, 770M innoDB

Типовой конфиг обычно рекомендуют какой-то такой:

Теперь давайте разбираться, что мы будем оптимизировать здесь, зачем, как и почему (особенно почему этих параметров маловато.

Нашел хороший и быстрый способ оптимизации работы баз данных mysql.

Есть очень хороший скрипт на перл, который позволяет узнать, что вам нужно оптимизировать в настройках, дабы у вас все было очень круто.

Закачать его можно вот так:

Скрипт запросит рут-доступ к вашему серверу БД. Дайте ему то, что он просит.

Вот выдача скрипта с моего компа:

:~$ perl mysqltuner.pl

Удачной оптимизации товарищи.

Навигация по записям

MySQLTuner — это скрипт, который анализирует работу MySQL и выводит рекомендации по его оптимизации.

Обратите внимание! Перед запуском скрипта сервер MySQL должен проработать около суток без перезагрузок и смены конфигурации, чтобы MySQLTuner мог получить достаточно данных для полноценного анализа. В противном случае результаты работы скрипта будут бесполезны.

MySQLTuner выведет результат, который будет состоять из нескольких секций и выглядеть примерно следующим образом (реальный вывод будет подробнее и длиннее):

Параметры, приведенные в пункте Variables to adjust, необходимо изменять в конфигурационном файле MySQL. Если в файле такой параметр отсутствует, его необходимо вписать.

Конфигурационный файл MySQL может размещаться по различным путям.

В Debian/Ubuntu это могут быть:

После каждого изменения конфигурационного файла необходимо перезапускать MySQL:

systemctl restart mysql

Дополнительные рекомендации

1. Перед изменением конфигурационного файла сделайте его бэкап (в команде необходимо указать актуальный для вас путь):

cp /etc/mysql/my.cnf ~/my.cnf.backup

2. После внесения правок подождите, чтобы сервер проработал около суток, после чего можно снова запустить MySQLTuner. Так вы сможете проанализировать работу MySQL уже с новыми настройками и продолжить оптимизацию.

3. Правки по рекомендациям MySQLTuner имеет смысл вносить постепенно и после каждого изменения наблюдать за работой сервера. В этом случае, если возникнут какие-либо проблемы, вы сможете быстро определить их причину и откатить нежелательные изменения.

Не забывайте после каждого изменения настроек перезапускать службу MySQL.

Проверки каждый год

На самом деле Битрикс24 стоит обновлять чаще, чем раз в год. Вместе с обновлениями постоянно приезжает новый функционал, улучшение интерфейса и производительности, исправления старых и добавление новых ошибок, исправление уязвимостей.

Можно узнать дату последней установки обновлений в админке в разделе «Marketplace — Обновление платформы»:

Если эта дата была больше года назад, стоит запланировать обновление.

Битрикс24 будет успешно работать, несмотря на то, что на сервере стоят не самые последние версии пакетов, поэтому необходимость обновлять систему возникает довольно редко. Обновления безопасности должны ставиться автоматически. Остальные обновления достаточно ставить раз в год, чтобы система устаревала не очень сильно.

Как и всегда, перед обновлением системы нужно сделать резервную копию и убедиться, что она выгрузилась в облако Битрикс24. Для установки всех доступных обновлений пишем так:

$ yum-y upgrade

Если при обновлениях была сгенерирована новая версия загрузчика — обязательно нужно перезагрузить сервер и убедиться, что он корректно стартует:

В некоторых случаях для обновления необходимо будет воспользоваться скриптом menu.sh. Например, веб-окружение не станет самостоятельно пытаться проапгрейдить версию БД или PHP, на это нужно согласиться явно.

Поэтому кроме технических аспектов нужно проконтролировать, что лицензия будет продлена вовремя.

Настройка сервера

• Подключитесь к серверу по с реквизитами пользователя root.
• Запустите меню виртуального окружения Битрикс командой:

• Выберите пункт 4 «Configure memcahed servers».
• Начнется установка memcached. В процессе установки будет запрошен hostname вашего сервера — необходимо указать значение ServerName из выведенной на экране таблицы.
• После завершения установки настройте конфигурационный файл

Откройте файл в текстовом редакторе, например, nano:

Если nano отсутствует, можно установить его командой yum install nano либо использовать имеющийся на сервере редактор (например,

Задайте следующие параметры:

# количество одновременных подключений (по умолчанию 1024)MAXCONN = «1024»# объем выделяемой памяти для кэша (по умолчанию 64MB)CACHESIZE=»1024″# количество потоков memcachedOPTIONS=»-t 4″

systemctl restart memcached.service

» укажите корректное значение для вашей системы.

Укажите в файле следующие параметры:

Укажите в нем следующие параметры:

Для этого выполните следующие действия:

9.1. Создайте папку для хранения временных файлов, например,

9.2. Измените владельца папки и группу на mysql:

chown mysql:mysql /var/lib/mysql/tmp

9.3. Определите идентификатор пользователя (uid) и группы (gid) mysql:

В самый конец файла добавьте строку с указанием полученных выше значений:

tmpfs /var/lib/mysql/tmp tmpfs rw,gid=27,uid=27,size=1G,nr_inodes=10k,mode=0700 0 0

Параметр size необходимо установить в зависимости от количества имеющейся оперативной памяти.

9.5. Примонтируйте новый tmpfs-раздел:

9.6. В файл конфигурации MySQL

systemctl restart mysqld

Данный параметр позволит использовать отложенные транзакции.

Что делать дальше

Большую часть перечисленных проверок можно автоматизировать. Например, настроить нормальный мониторинг, отслеживание подозрительной активности, информирование о возникающих проблемах. Мы описали самый простой случай, который закрывает 80% потребностей среднестатистической коробки на ~50 человек.

Проверки каждую неделю

1. Проверка создания резервных копий
На портале должно быть настроено автоматическое резервное копирование. Это делается в админке, в разделе «Настройки — Инструменты — Резервное копирование — Регулярное резервное копирование»:

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

Список созданных резервных копий можно посмотреть в разделе «Настройки — Инструменты — Резервное копирование — Список резервных копий»:

Если очередная резервная копия не создалась и в списке отображаются только её предыдущие версии, нужно разобраться, почему это произошло и устранить проблему. Две наиболее частые причины — отсутствие места на диске и неправильно настроенное расписание.

Также резервную копию можно создать вручную вне очереди:

2. Проверка журнала событий
В админке, в разделе «Настройки — Инструменты — Журнал событий» отображаются события, фиксируемые в Битрикс24:

Нужно время от времени в него заглядывать и просматривать, что происходит в системе. Если некоторые записи кажутся подозрительными, нужно принять соответствующие меры.

Череда безуспешных попыток авторизации, закончившаяся успехом, может означать взлом аккаунта пользователя, нужно убедиться, что это не так. Хотя чаще это означает, что пользователь забыл свой пароль.

Если модуль проактивной защиты обнаружит на сайте вирус или попытку вторжения — информация об этом так же окажется в этом журнале.

Когда кто-то пользуется PHP или SQL-консолью в админке, информация об этом фиксируется в журнале. Если мы видим, что из под аккаунта бухгалтера кто-то выполнял SQL-запросы — это как минимум странно.;

Как минимум, все события главного модуля должны быть включены/

3. Проверка логов
После журнала событий стоит также посмотреть системные логи. В них может оседать информация о низкоуровневых ошибках. Например, в настройках Битрикс24 можно определить файл, в который будет записываться информация о всех сбоях, возникающих в системе.

Чтобы узнать, где конкретно он находится на вашем портале, нужно выполнить в PHP-консоли такой код:

В этом файле в зависимости от текста ошибки можно понять, что произошло. Так, если в ошибке фигурируют строки вида «Too many connections» или «MySQL server has gone away» — нужно перепроверить настройки сервера БД. В остальных случаях нужно обратиться к разработчику.

Кроме Битрикса, стоит просматривать логи отправки почты. В зависимости от того, как настроена отправка почты они пишутся либо в /home/bitrix/msmtp_default.log, либо в /var/log/maillog.

В них можно найти:
— Кому и сколько писем отправляется, не идёт ли рассылки спама
— Коды ответов почтового сервиса, принимает ли он письма нашего портала
— Как быстро почта уходит с сервера

В зависимости от вашего опыта работы с Linux вам могут также пригодиться логи в /var/log, как минимум эти:
/var/log/cron
/var/log/dmesg
/var/log/messages
/var/log/mysql/error.log
/var/log/mysql/slow.log
/var/log/nginx/error.log
/var/log/httpd/error_log
/var/log/firewalld
/var/log/secure

Шаг 2. Обновление версии PHP

В BitrixEnv версии 7.5 вы можете изменить версию PHP на 7.4. Для этого:

• В основном меню выберите пункт 1. Manage servers in the pool8. Update PHP and MySQL
• 1. Upgrade PHP.
• 1. Update PHP to version 7.4y для подтверждения обновления.

Версия РНР 7.4 установлена.

Если не удается выполнить обновление

Если обновление версии не происходит или завершается с ошибкой, необходимо отредактировать файл /etc/yum.repos.d/remi-php74.repo

Откройте файл в предпочитаемом редакторе, например:

И замените его содержимое на следующее:

После снова выполните обновление версии PHP по инструкции выше.

Также, в процессе обновления bitrixenv может завершиться работа веб-сервера nginx. Для решения проблемы необходимо создать обращение в поддержку.

Проверки каждый месяц

1. Проверка системы штатными средствами Битрикс24
Нужно зайти в админку (раздел «Настройки — Инструменты — Проверка системы»), нажать кнопку «Выполнить проверку» и дождаться результатов. После чего исправить выданные рекомендации, а также выполнить проверки на вкладках «Тестирование конфигурации» и «Проверка доступа».

2. Проверка производительности
Нужно зайти в админку (раздел «Настройки — Производительность — Панель производительности»), запустить процесс тестирования, после чего ознакомиться с рекомендациями и принять соответствующие меры.

3. Проверка базы данных
Характер нагрузки на БД сильно зависит от того, как именно в текущий момент пользователи пользуются Битрикс24 и какие модули установлены в системе, поэтому настройки по умолчанию чаще всего не оптимальны и нужно их время от времени корректировать.

В Битрикс24 имеется раздел «Настройки — Производительность — Сервер БД», где можно получить рекомендации о том, что нужно подкрутить в настройках вашей БД.
Выглядит вот так:

Предлагаемые изменения нужно вносить в файл /etc/mysql/conf.d/z_bx_custom.cnf. Корневой файл конфига (/etc/my.cnf) лучше не трогать, потому что ваши изменения могут перезаписаться при обновлении веб-окружения.

После каждого изменения параметров нужно перезапускать сервер MySQL:

$ systemctl restart mysql

Также можно воспользоваться более продвинутым инструментом — MySQLTuner, с которого собственно в Битрикс и портировали свою систему выдачи рекомендаций. В CentOS его можно поставить прямо из репозиториев:

$ yum -y install mysqltuner

4. Проверка настроек PHP
Находится в разделе «Настройки — Производительность — PHP». Крайне редко в этом разделе будет полезная информация, но зайти на минутку и проверить наличие рекомендаций стоит.

5. Продление SSL-сертификатов
Срок действия SSL-сертификата можно проверить с помощью сервиса SSL Shopper

Сертификат может быть платным и бесплатным. Если вам ставили платный, то продление будет происходить примерно раз в год и потребует ручных действий. Если бесплатный, то вместе с установкой должны были настроить автоматическое его продление. Бывает, что автоматическое продление сбоит или не работает, в таком случае необходимо обновить сертификат вручную такой командой:

# обновить
$ /opt/webdir/bin/bx-dehydrated

# посмотреть результаты
$ cat /home/bitrix/dehydrated_update.log

6. Проверка баланса на хостинге
Если вы арендуете виртуальный или физический сервер у хостера, нужно регулярно проверять, что на вашем аккаунте достаточно средств для оплаты услуги на ближайшие 30 дней. Если просрочить оплату, ничего страшного обычно не случается, но всё равно неприятно прийти утром на работу и обнаружить, что Битрикс24 не работает, потому что хостер выключил виртуалку за неуплату.

7. Восстановление из резервной копии
Резервные копии мало только делать, нужно также быть уверенным в том, что в случае чего из неё можно будет восстановиться. Чтобы это проверить нужно попробовать восстановить резервную копию на каком-либо сервере, отличном от боевого и посмотреть, как всё прошло. Чтобы сделать это нужно воспользоваться соответствующей инструкцией.

Кроме успешного завершения процесса восстановления, нужно авторизоваться и походить по развёрнутой копии портала. Убедиться, что все файлы, записи звонков, фотографии сотрудников, задачи, сделки, сообщения остались на месте. Если резервная копия не восстановилась или оказалась неполной, нужно перенастроить правила создания резервных копий и выяснить причину, почему так произошло.

8. Проверка монитором качества
В разделе «Настройки — Инструменты — Монитор качества» есть возможность проверить проект на соответствие стандартам качества Битрикс24.

После запуска система автоматически проверит большинство пунктов и выдаст рекомендации:

Некоторые из этих проверок неактуальны для Битрикс24 (например, все проверки по интеграции дизайна имели бы смысл только для интернет-магазинов), но секции “Веб-окружение”, “Безопасность”, “Производительность”, “Размещение на хостинге”, “Сдача проекта” — несут достаточно ценную информацию независимо от типа проекта.

По каждому проверяемому пункту можно получить детальное описание и рекомендации:

9. Проверка безопасности
Продолжаем использовать штатные средства системы, раздел «Настройки — Проактивная защита — Сканер безопасности»:

Результаты выглядят так:

Для каждой найденной проблемы можно нажать на “Что делать” и посмотреть человекопонятное описание:

10. Проверка инспектора сайтов
Инспектор сайтов позволяет мониторить работоспособность сайта и сроки действия лицензии Битрикс24, SSL-сертификатов и домена. В админке можно найти все мониторируемые сайты в разделе «Настройки — Облако 1С-Битрикс — Инспектор сайтов».

Страница настроек выглядит так:

Если вы укажете свой адрес в поле «e-mail для оповещений», будете получать письмо, если на портале возникнут неполадки, а также когда придёт время обновить домен, лицензию или сертификат.

Шаг 1. Обновление версии BitrixEnv

Перед началом работы обязательно создайте резервную копию сервера: самостоятельно или с помощью инструмента бэкапов в панели управления.

подключитесь к серверу по SSH и выполните в меню Bitrix следующие действия.

Если версия BitrixEnv ниже 7

Сначала необходимо обновить версию окружения до актуальной (7.5+).

Для обновления до 7.5. выполните:

• 1. Manage servers in the pool4. Update packages on host.
• Enter server address
• Please choose update type введите на выбор: — для обновления только BitrixEnv до актуальной версии, либо для обновления всех имеющихся пакетов, в том числе BitrixEnv:
• Дождитесь завершения обновления.

Теперь версия окружения — 7.5, и вы можете выполнить следующие шаги по инструкции.

Если версия BitrixEnv 7. 5 или выше

Переходите к обновлению версии PHP.

Проверки на каждый день

Контролируем самые критичные для работы сервера параметры. Их всего три.

1. Расход памяти
Можно смотреть утилитой htop:

На сервере всегда должен быть запас, который можно использовать. В идеале расход RAM не должен быть выше, чем 50% при пустом swap’е. Но на практике достижение такого уровня может оказаться нецелесообразным или невозможным. Например, если мы хостим Битрикс24 на VPS — можно неожиданно упереться в бюджет, выделенный на оплату этого сервера, т.к. добавление памяти будет не бесплатным.

В целом нужно смотреть по поведению системы. Если на вашем сервере память заполнена на 80% и ещё 50% лежит в swap’е, но портал работает без перебоев, то всё нормально.

Кстати swap должен быть всегда. Нам время от времени встречаются настроенные по-ковбойски сервера, на которых его нет, из-за чего при повышенном расходе памяти сервер намертво зависает вместо того, чтобы продолжить работать.

2. Средняя нагрузка
Смотрится так же через htop:

Три числа, следующие за “Load Average” — средняя нагрузка на систему за 1, 5 и 15 минут. Нам наиболее интересна 15-минутная, т.к. при её расчёте сглаживаются кратковременные всплески нагрузки, искажающие статистику за 1 и 5 минут.

Приближённо говоря, пределы нормы для Load Average — от нуля до количества процессорных ядер в системе. Для VPS с двумя ядрами, как на скрине значение 2.00 будет означать 100% утилизацию процессорного времени. Вообще эти числа считаются несколько сложнее, но для ориентировки нам хватит такого понимания.

При этом на сервере всегда должен быть запас как минимум на две резервных копии Битрикс24. Их размеры разнятся от портала к порталу, но в среднем одна резервная копия будет занимать от 4 до 16 ГБ.

Также можно воспользоваться разделом «CRM — Настройки — Чем занято место» и оценить, как Битрикс24 расходует выделенное ему пространство:

Настройка CMS

После переноса сайта можно приступить к настройке CMS.

• В разделе «Проверка системы» не должно присутствовать каких-либо записей с ошибками.
• В разделе «Панель производительности» во вкладке Битрикс должно быть значение — «Битрикс (оптимально)».
• Измените тип таблиц базы данных на InnoDB и выполните оптимизацию базы данных. Предварительно рекомендуем создать

Оптимизация и конфиг

Для начала можно пролистать в конец вывода ​mysql tuner​ и посмотреть, что же он там рекомендует. В нашем случае это выглядит как-то так:

wget
https://raw.github.com/major/MySQLTuner-perl/master/mysqltuner.pl
perl mysqltuner.pl

Не будем заниматься бездумной подстановкой, а пройдемся по параметрам ​mysql​ , которые могут нас интересовать в первую очередь. Что к чему:
skip-external-locking​, — убирает внешнюю блокировку, что быстрее;
skip-name-resolve​ , — позволяет ​MySQL ​ избегать ответа на запрос DNS ​ при проверке подключения клиентов к серверу ​MySQL​ .
Таким образом, сервер ​MySQL ​ будет использовать только
IP​ -адреса, а не имена хостов, что немного, но быстрее.
binlog_cache​ _ ​ size​, — размер кэша для хранения изменений в двоичном журнале. Задает размер только для кэша транзакций. Сделаем ​ 100M​ — больше не нужно.

innodb_stats_on_metadata​ =​ 0 (OFF),​ — для ускорения работы с
INFORMATION_SCHEMA​, ​ SHOW TABLE STATUS​ или ​ SHOW INDEX​ отключим обновление статистики при выполнении таких операций

quer​ y ​ _cache_size ​ = ​ 128M ​ и ​ query_сache_type​
​ = ​ 1,​ ​ — ​ кэши запросов. ​ 1​ — в принципе включен, ​ 128M​ ограничение. Не
рекомендуется ставить выше ​ 256M​ , т.к это может привести к блокировке.
Так как у нас больше​InnoDB​ таблиц, то зануляем cache​ _ ​ size​ .
С версии MySQL 5.6 ​ query_cache_size​ отключен, а с версии 8.0 удален

Значение ​ innodb_open_files​ и ​ table_open_cache​ — рекомендуется устанавливать обе опции в ​ 4096 ​ или ​ 8192​ . А вообще рассчитывается как количество таблиц во всех базах, умноженное на ​ 2​ , ориентировочно.

При работе с ​ InnoDB ​ является важнейшим параметр innodb_buffer_pool_size​ , ​ он устанавливается по принципу «чем больше, тем лучше». Рекомендуется выделять до ​ 70-80% оперативной памяти сервера.

innodb_log_file_size​ — влияет на скорость записи, устанавливает размер лога операций (операции сначала записываются в лог, а потом применяются к данным на диске). Чем больше этот лог, тем быстрее будут работать записи (т.к. их поместится больше в файл лога). Файлов всегда два, а их размер одинаковый. Значением параметра задается размер одного файла.

ВНИМАНИЕ!️При изменении параметра innodb_log_file_size остановите MySQL, сделайте резервную копию файлов ib_logfile-n (файлы чаще всего лежат в /var/lib/mysql/), измените значение параметра innodb_log_file_size и запустите MySQL. В результате
MySQL создаст новый лог-файл указанного в конфигурации размера.

Установка большого размера ​ innodb_log_file_size​ может привести к увеличению быстродействия, но при этом увеличится время восстановления данных, выберите от ​ 256M​ до​ 1G​ .

innodb_log​ _ ​ buffer_size​ — размер буфера транзакций. Обычно рекомендуется не применять, если не используете ​ BLOB ​ и ​ TEXT больших размеров.

innodb_flush​ _ ​ method,​ — определяет логику сброса данных на диск. В современных системах при использовании RAID и резервных узлов, вы будете выбирать между ​ ODSYNC​ и ​ ODIRECT, — первый параметр быстрее, второй безопаснее.

key_buffer​ _ ​ size​ — буфер для работы с ключами и индексами, и sort_buffer​ — буфер для сортировки. Если Вы не используете MyISAM ​ таблицы, рекомендуется установить размер key_buffer_size ​ в ​ 32Мб ​ для хранения индексов временных
таблиц.

Параметр ​ thread_cache​ _ ​ size​ указывает количество тредов (threads), уходящих в кеш при отключении клиента. При новом подключении тред не создается, а берется из кеша, что позволяет экономить ресурсы при больших нагрузках.

innodb_flush_log_attrx_commit​, — может повысить пропускную способность записи данных в базу в сотни раз. Он определяет, будет ли ​Mysql ​ сбрасывать каждую операцию на диск (в файл лога).

innodb_flush_log_at_trx_commit = 1​ используется для случаев,
когда сохранность данных — это приоритет номер один.

innodb_flush_log_at_trx_commit = 2​ для случаев, когда небольшая потеря данных не критична. Есть еще 0 (ноль) — самый производительный, но небезопасный вариант.

max_connections ​ — если вы получаете ошибки «​ Too many connections​ «, эту опцию стоит увеличить. А так большой пользы в оптимизации от неё нет.

Количество потоков ввода/вывода файлов в InnoDB задается опциями ​ innodb_read_io_threads​ , ​ innodbwrite_io_threads​, обычно этому параметру присваивается значение ​ 4 ​ или ​ 8​ , на быстрых ​ SSD​ -дисках установите в ​ 16​. Значение innodb_thread_concurrency​ установите в количество ядер ​ * 2​ .

Конфиг получается вот такой:

Ну и напоследок можно посмотреть рекомендации тюнера и последовать им.

Предисловие

Прежде чем что-то делать на боевом сервере, пожалуйста, убедитесь, что полностью понимаете смысл происходящего и возможные последствия выполняемых действий.

В самом простом случае для сопровождения сервера достаточно иметь к нему доступ по SSH и владеть базовыми знаниями об администрировании систем на Linux. Ничего специфичного для своей работы Битрикс24 почти не использует — под капотом всем давно известные технологии:
— Nginx
— Apache
— MySQL
— Sphinx
— Memcached
— Munin
— Nagios
— NodeJS

Архитектурно Битрикс24 почти не отличается от любого другого сайта или интернет-магазина, разработанного на фреймворке Битрикса. Применяемые при разработке принципы у них одни и те же. Однако в отличие от сайтов у Битрикс24 повышенные требования к системе, в которой он запускается.

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

Если нет полной уверенности, так ли это — можно проверить наличие в системе пакета “bitrix-env”:

Если веб-окружение стоит, мы можем в интерактивном режиме в консоли выполнять наиболее типовые задачи по администрированию, используя скрипт /root/menu.sh:

скрипт /root/menu.sh;;
И вообще там много полезного. Более подробно познакомиться с веб-окружением и его возможностями управления сервером можно в специально разработанном для этого курсе.

Заключение

Вот такой вот интересный конфиг получился. Если Вам сложно, то на первых порах стоит пользоваться ​mySQL ​ калькулятором, который подскажет основные параметры и позволит не выходить за пределы доступной памяти — как-никак всё упирается в неё:

Спасибо за внимание. Присоединяйтесь к обсуждению.,