|
Разработчикам |
Байткод кэширует opcache, создан для этого, ничего другого не умеет, является стандартом для PHP на данный момент. |
|||
|
|
|
|
Дмитрий Тигиев, важное уточнение. Меню видно только в том случае, если авторизуетесь под root-пользователем.
|
|
|
|
|
Попробуйте тоже написать в сапорт, если у вас конечно есть какие-либо конкретные замечания. По поводу "ничего толком не ищется" - скорее всего у вас беда в том, что перед индексацией все слова проходят через стемминг (выделение основы слова), а ваша специфика не дает достаточно полной ситуации. Попробуйте расширить поисковый индекс на обработчиках, добавив туда ваши данные. |
|||||
|
|
|
Модуль поиска наполняет свои таблицы, на которые потом натравливается поисковый движок, будь то Битриксовый или Sphinx. Что, где и зачем прописать для более оптимальной работы Sphinx при прочих равных я знаю и это не сложно делать сразу при создании конфигов. Про это и речь. |
|||||||
|
|
|
1) apc, включен по ошибке, поскольку два кешера опкода не имеют смысла? 2) apcu хоть как то используется кодом ядра битрикс? --- Виктор |
|||||
|
|
|
загляните в конфиг подключения и посмотрите на название подключаемой библиотеки, должна быть apcu.so если конфига 2 и в одном apcu.so, в другом apc.so, то у вас произошла некая мистика или кто-то поставил apc по незнанию, опции конфигурации у них одинаковые практически в чистой Битрикс ВМ apc нет, если у вас есть отключите его 2) используется, если выбрать хранение кэша в apcu, а так нет, может работать без него |
|||||||
|
|
|
Какая тут может быть мистика? Смотрите, по шагам, каждый может повторить: - устанавливаем CentOS 7; - обновляем систему. На сегодня это: "CentOS Linux release 7.3.1611 (Core)" с ядром 3.10.0-514.6.1.el7.x86_64; - стандартно устанавливаем bitrix-env; Все, больше никто ничего руками не трогает. И что мы имеем? В папке /etc/php.d кроме 10-opcache.ini с включенным zend_extension=opcache.so, присутствуют: - 40-apcu.ini с включенным extension = apcu.so. Ладно, тут, вроде, проблем нет. - 50-apc.ini - с включенным extension=apc.so Можете повторить, не вопрос, не думаю, что у Вас получиться другой результат. --- Виктор |
|||||
|
|
|
VGrey, спасибо. Тикет написал, разберемся. |
|||||
|
|
|
Объясните, плиз, для простых смертных. Чтобы не ждать обновления и исправить это самостоятельно, достаточно просто удалить файл 50-apc.ini? |
|||||||
|
|
|
50-apc.ini -> 50-apc.ini.disabled |
|||
|
|
|
Резонно могу предположить, что сама конфигурация собрана теми кто разрабатывал модуль поиска и мало отношения имеет к тем, кто разрабатывает bitrix env. |
|||
|
|
|
|
VGrey, aleksandr.b, Владимир Ульянов, пакет php-pecl-apcu теперь тянет за собой php-pecl-apcu-bc - отсюда в папке /etc/php.d/ создается файл 50-apc.ini. Исправлено в 7.0.1. Пока можно поправить так: cd /etc/php.d/ && mv 50-apc.ini 50-apc.ini.disabled && systemctl restart httpd.service.
|
|
|
|
|
Для sphinx в 7.0.1 версии убрали все depricated опции и warnings, про оптимизацию конфига "со всеми вкусностями" подумаем в следующей версии  |
|||
|
|
|
|
а конверсия из образа для Оракла ничего не даёт хорошего. как уже тут писали
|
|
|
|
|
|
Коллеги, чистая установка, все вроде ок. Обновляем компоненты через меню, включая последний пост по репо. Все ок, но только после захода на веб морду и попытке скачать тот или иной модуль для локальной установки получаем ошибку 414. и БОЛТ. правка конфига нгинкса не дает ничего.
|
|
|
|
|
|
|||
|
|
|
|
попробуйте еще раз
|
|
|
|
|
UPD. Извините, все ок. Теперь работает UPD 2. Загрузка дистрибутива на 44 процентах уже минут 10.. |
|||
|
|
|
|
|||
|
|
|
На 7 окружении развернул бэкап и вот такая ерунда. 'className' => '\\Bitrix\\Main\\DB\\MysqliConnection', поменял - не помогло. в dbconn стояло define("BX_USE_MYSQLI", true); Куда дальше копать? |
|||
|
|
|
|
По поводу увеличения размера диска Bitrix VM 7.
Подскажите пож-та для данной VM7 информация в статье актуальна? В моем случае, когда дошел до шага 5. Отобразилось 2 только раздела: sda1 и sda2. В инструкции сказано про пересоздание раздела sda3. (шаг 7) Для теста на этом шаге я выбрал пересоздание sda2 (за неимением sda3). Но на 11 шаге (resize2fs /dev/sda2) теперь пишет : Device or resource busy whille trying to open sda2 Couldn't find valid filesystem superblock. Ранее на версиях VM 4.x и 5.x увеличение диска работало четко согласно инструкции. Прошу подсказать, в чем проблема? Что делается не так? |
|
|
|
|
|
Вот скрин.
Сейчас процесс остановился на выполнении комманды resize2fs |
|
|
|
|
Для CentOS 7 с файловой системой XFS использовать нужно xfs_growfs вместо resize2fs. Урок в процессе написания. Скоро выйдет. --------------- Если коротко: Смотрим сколько у вас разделов
запоминаем имя группы томов и имя тома. у вас имя группы томов - cl имя тома - root
n — создаём новый раздел; p — обозначаем его как primary; так как у вас 2 логических раздела, то на вопрос Partition number отвечаем 3; t — укажем тип раздела опять тот же вопрос Partition number, отвечаем 3; вводим 8e — это код типа раздела, соответствующий Linux LVM; далее p - проверяем, что 3й раздел создан. потом w - сохраняем изменения. ребут машины:
Создаем физический том sda3:
Расширяем группу томов на новое пространство. Используем ваше имя группы томов cl, которое записали ранее (из команды df -h: /dev/mapper/cl-root):
Теперь расширим логический том:
И последнее, расширяем файловую систему. Для CentOS 7 с файловой системой XFS нужно использовать xfs_growfs вместо resize2fs. Процесс займет некоторое время.
И проверяем итог:
|
|||||||||||||||||||||||||
|
|
|
||||||||||||||||||||||||
© 2001-2024 «Битрикс», «1С-Битрикс». Работает на 1С-Битрикс: Управление сайтом. 
Политика конфиденциальности
