Realpath cache size что это
Проблемы с параметром realpath_cache_size
realpath_cache_size 16K 16K
realpath_cache_ttl 120 120
То что установленно nano etc/php5/apache2/php.ini:
и в nano /usr/local/Zend/etc/php.ini
Тогда все правильно. Вы устанавливаете в /etc/php5/apache2/php.ini, а PHP считывает /usr/local/Zend/etc/php.ini. Возможно, конечно, там симлинки, но, судя по всему, нет.
Битрикс не виноват, вы правите не тот файл.
| Цитата |
|---|
| Александр Демчишин пишет: подправьте значение 1024 в строке @ini_set(«memory_limit», «1024M») |
столкнулись с аналогичной проблемой:
Помогите советом. Хостинг от Reg.ru.
Проверяю через phpinfo Всё без изменений. Хотя правил еще некоторые опции всё нормально стало, а эти ну ни в какую прям.
Сегодня столкнулся с такой же проблемой. Решение получилось такое. Нужно строчку realpath_cache_size разместить как можно выше в файле. у меня стоит после
обновил. и в phpinfo() и в битриксе все отобразилось корректно
PHP и realpath_cache
От переводчика: разбираясь на днях с ошибкой, возникшей после деплоя сервиса, натолкнулся на эту замечательную статью про механизм кэширования файловых статусов в PHP. Предлагаю сообществу перевод.
Кэш realpath — довольно важный механизм PHP, который нужно иметь в виду. Особенно, когда приходится работать с символическими ссылками, например, при деплое проекта. Настройка кэширования realpath может значительно влиять на быстродействие сервера и нагрузку на дисковую подсистемы сервера. Этот параметр был введен в версии 5.1, когда начали появляться первые PHP-фреймворки.
Далее мы разберемся, как все это работает под капотом, и как с этим жить. Под катом много ссылок на исходники.
Вспоминаем о системном вызове stat()
Вы знаете, как работает ваша система? Давайте я освежу вашу память. Когда вы работаете с путём, системное ядро и файловая система должны понимать, что вы от них хотите. Когда вы используете путь для доступа к файлу, ваша библиотека или ядро системы должны разрешить его. Разрешение пути — это получение информации о нем: это файл, директория или, может быть ссылка?
Обычно для разрешения относительного пути используется C-функция realpath(). Она, в свою очередь, делает системный вызов stat().
Вызов stat() достаточно тяжелый. Во-первых, это системный вызов, влекущий за собой прерывание и переключение конекста. Во-вторых, работает с данными на медленном диске. В коде можно найти обращения к файловой системе inode->getattr(). Обычно ядро использует собственный кэш (buffer-cache), поэтому влияние на производительность должно быть незначительным. Однако, на нагруженном сервере кэш может не содержать необходимую информацию, что влечет за собой повышенную нагрузку на дисковую подсистему. Поэтому, в наших же интересах предупреждать такое поведение.
Что делает PHP?
И в этом месте происходят интересные вещи: вызываются функции вроде realpath_cache_find() для поиска сохраненных в кеше данных для запрашиваемого файла. Для хранения информации используется структура realpath_cache_bucket, которая инкапсулирует большой пакет данных:
Если данные в кэше не найдены, вызывается функция php_sys_lstat(), которая является прокси для системного вызова lastat(). Результат этого вызова сохраняется в realpath cache.
Настройки PHP
Итак, со стороны PHP нам необходимо знать несколько вещей про realpath cache. Для начала, настройки php.ini :
realpath_cache_size
realpath-cache-ttl
В документации есть ремарка про увеличение этих параметров на серверах, где исходный код меняется редко. Так же стоит учесть, что стандартный размер кэша 16КБ ничтожно маленький. Он весь исчерпается одним запросом с фреймворком вроде Symfony2. Для поддержания настройки размера кэша в актуальном состоянии стоит следить за выводом функции realpath_cache_get(). Если доступный объем быстро исчерпывается — это явный повод увеличить размер кэша вплоть до 1МБ. В случае, если кэш переполнится, PHP начнет злоупотреблять вызовами stat(), что напрямую скажется на производительности. Требуемый размер кэша сложно посчитать с достаточной точностью. Покопавшись в исходниках, можно сделать вывод, что каждая сущность в кэше занимает место, равное: `sizeof(realpath_cache_bucket) + кол-во символов разрешенного пути + 1`
Для 64-битной системы (LP64) sizeof(realpath_cache_bucket) = 56 байт.
Почему? Для начала, это требуется для проверки доступа к каждому уровню пути. Во-вторых, многие пользователи формируют пути, используя конкатенацию, поэтому, PHP может проверять пути по частям, каждый раз запрашивая уже закэшированную сущность. Доступ к кэш очень быстрый, детали можно посмотреть в исходниках tsrm_realpath_r(). Это
рекурсивная функция, вызываемая по умолчанию на каждый элемент пути.
Итого, первый вывод из предыдущего параграфа: кэш — это хорошо!
Второй — «дернуть» несколько страница сайта после выкладки — необходимая задача перед открытием публичного доступа к сайту. Это не только сбросит OPcode cache, но так же актуализирует realpath cache и page cache ядра системы.
Пример
Возьмем с потолка простой пример^
Что мы видим? Полный путь до скрипта разрешается по частям, с самого начала. Так как файл /tmp/bar.php не существует, записи о нем нет в кэше. Однако, путь до /tmp разрешен, поэтому каждый следующий запрос во вложенные файлы будет немного быстрее, чем в первый раз.
Поговорим про кэш OPcode
Готовы к очередному подводному камню?
Кэш realpath привязан к конкретному процессу и не сохраняется в разедляемую память (shared memory).
Это означает, что каждый раз, когда элемент кэша устаревает, изменяется или кэш очищается вручную, это необходимо делать для каждого запущенного процесса. Именно из-за этого пользователи часто испытывают трудности при развертывании приложения на серверах, использующих кэш OPCode.
Лучшим найденным решением для предотвращения этого побочного эффекта стало подготовка отдельного пула воркеров PHP и переключения балансировщика на него, позволяя старым воркерам нормально завершить работу. Это позволяет изолировать две версии друг от друга, тем самым, предотвратив использование неактуального кэша. Все окружение, включая кэш realpath и кэш OPCode, будет новым. Этот прием доступен как минимум при использовании Lighttpd и Nginx. И он успешно работает в продакшне.
Конец
Меня попросили написать несколько строк о кэше realpath. Скорее всего из-за проблем, возникающих при выкладке кода. Ну, теперь вы знаете, как это работает и как этим управлять.
Just a thought, should clearstatcache() force the reset of the cache? I cant think of many situations where you would re-build directory tree’s on the fly, but you never know what to expect from PHP users 🙂
Во всём виноват PHP OPCache?
Когда я начинал карьеру разработчика, то очень удивился, прочитав фразу, которую приписывают Филу Карлтону (Phil Karlton): «В информатике есть лишь две сложности: инвалидация кеша и присвоение имён». Я отнёсся к этому недоверчиво, поскольку не понял сути фразы. Но немного позже я начал понимать.
Я хочу рассказать о проблеме, с которой мы столкнулись не так давно в нашей production-инфраструктуре. Сразу после успешного развёртывания при обновлении страниц, изменённых новым релизом, какое-то время не отображался новый код. Вообще-то такое далеко не редкость для веб-приложений, написанных на PHP. Мы сталкивались с подобным и раньше, а после перехода на новую production-среду проблема стала заметнее. Поэтому мы решили заняться расследованием.
Наша процедура деплоя
Наша технология по большей части написана на PHP, а также использует фреймворки Symfony и Zend. Для отправки кода в production мы применяем внутренний проект shark-do, его автор — лидер команды Luca.
«Если ты можешь это сделать, то можешь сделать это в bash».
Проект представляет собой bash-скрипт, умеющий определять задачу и исполнять её по алгоритму. Для каждого проекта свой алгоритм управления разными этапами, например удалением ненужных файлов, генерированием конфигурационных файлов и т. д.
Например, больше пяти раз в день я с помощью команды shark-do deploy collaboratori запускаю задачи по развёртыванию для проекта «collaboratori», над которым я работаю. Обычно развёртывание состоит из следующих этапов:
Рассмотрим пятый шаг. Ansible-сценарий отвечает:
Каждая процедура развёртывания состоит из многих нужных операций, но поворотная точка — изменение текущей папки проекта: это делается с помощью symlink-передачи из предыдущей папки релиза в новую. Текущая папка проекта — это корневое расположение документов конкретного веб-приложения.
Мы применяем стандартную для PHP стратегию развёртывания. Релизы одного приложения хранятся на production-серверах, а к текущей версии мы обращаемся по символьной ссылке. Это позволяет развёртывать атомарно и безопасно, не влияя на рабочий трафик.
Наконец, за балансировщиком с карусельной (round-robin) политикой у нас стоит 15 фронтенд-серверов (в два с лишним раза больше, чем раньше). Вопрос: что происходит после переключения релиза?
Во всём виноват PHP OPCache (?)
Некоторые оговорки: мы не будем углубляться в поток выполнения PHP-скриптов, а обсудим основные вещи, чтобы вам было легче понять мои рассуждения о проблеме. Также мы станем рассматривать только PHP 7.
Иногда полезно вспомнить, как выполняется PHP-код. При запуске скрипта наш исходный код проходит через четыре фазы:
Третья фаза — компилирование. AST преобразуется в упорядоченную последовательность инструкций-опкодов. Каждый опкод можно считать низкоуровневой операцией виртуальной машины Zend. Полный список поддерживаемых опкодов можно посмотреть здесь.
Наконец, последняя фаза — исполнение. ВМ Zend выполняет каждую задачу, описанную в опкодах, и генерирует результат.
Первые три фазы (лексический анализатор, парсер и компилятор) объединены в «конвейер» (pipeline). Причём третья фаза занимает гораздо больше времени и потребляет больше ресурсов (памяти и процессора). Чтобы снизить вес фазы компилирования, в PHP 5.5 ввели расширение Zend OPCache. Оно кеширует выходные данные фазы компилирования (опкоды) в общей памяти (shm, mmap и т. д.), так что каждый PHP-скрипт компилируется только один раз, а разные запросы могут исполняться без фазы компилирования. Если в среде, не предназначенной для разработки, код меняется редко, то скорость исполнения PHP увеличивается как минимум вдвое.
Расширение OPCache также отвечает за оптимизацию опкодов, но это уже выходит за рамки статьи.
В связи со сказанным выше логично предположить, что в странном поведении, с которым мы столкнулись в нашей production-среде, виноват OPCache. Для проверки этого предположения я сделал простенькую демонстрационную среду из контейнера Docker, PHP 7.0 и Apache 2.4. Полный код можно скачать отсюда.
Для упрощения работы я написал несколько скриптов:
Можете просто клонировать GitHub-репозиторий, и всё готово к проверке, если у вас уже установлен Docker.
Чтобы воспроизвести проблему с кешем, нужно параллельно запустить эти команды в трёх разных командных строках:
Исполнение с конфигурацией production.
Повторилась проблема с кешем: после переключения релиза мы не видим правильный код после выполнения HTTP-запроса.
Теперь отключим OPCache и повторим тест.
Исполнение с конфигурацией production-no-opcache.
Удивительно, но проблема осталась, так что предположение было ошибочным: OPCache ни в чём не виноват.
realpath_cache: настоящий виновник
Пожалуй, при использовании функции include/require или автозагрузки PHP нужно вспомнить о realpath_cache. Кеш настоящего пути (real path cache) позволяет кешировать разрешения путей для файлов и папок, чтобы реже тратить время на поиск по диску и улучшить производительность. Это очень полезно при работе со многими сторонними библиотеками или фреймворками вроде Symfony, Zend и Laravel, поскольку они используют огромное количество файлов.
Дальше идут выходные данные print_r(realpath_cache_get()) ; в нашей тестовой Docker-среде:
В посте Джульена Паули также говорится:
«Кеш настоящего пути привязан к процессу и не помещается в общую память».
Теперь всё понятно, можно снова включить OPCache и отключить кеш настоящего пути, настроив его размер и время жизни:
Снова запустим тест:
Исполнение с конфигурацией production-no-realpath-cache.
Хочу отметить, что нашу последнюю конфигурацию настоятельно не рекомендуется использовать в production-среде, потому что PHP вынужден разрешать каждый встреченный путь, что плохо влияет на производительность.
Заключение
Я хотел рассказать о решении таинственной проблемы с кешем, о том, что узнал об OPCache и кеше настоящего пути, а также об их различиях. Сценарий, описанный в начале статьи, выдуман, но, к примеру, если запрос начинается при одной версии кода, затем во время исполнения пытается обратиться к другим файлам, а их обновили, переместили или удалили в последующих версиях кода, то могут возникнуть реальные проблемы. В худшем случае придётся обеспечивать совместимость двух последовательных релизов, но в описанных условиях этого очень трудно достичь.
Необходимо внедрять стратегию атомарного развёртывания (в строгом смысле). Например, можно использовать контейнеры или новый изолированный пул памяти PHP-FPM для каждого развёрнутого релиза. В последнем случае нужно как минимум удвоить объём памяти, чтобы можно было держать побольше одновременно работающих FPM-пулов.
В результате nginx будет разрешать символьные ссылки, пряча их от PHP.
Это лишь некоторые из способов борьбы с проблемами кеша настоящего пути. Не существует универсального, «правильного» способа. Вам придётся находить своё идеальное решение в зависимости от ваших требований и инфраструктуры.
Realpath cache size что это
Представленные здесь значения по умолчанию используются в случае, если не был подключен php.ini ; значения для боевого php.ini и для разработки могут различаться.
Языковые опции
| Имя | По умолчанию | Место изменения | Список изменений |
|---|---|---|---|
| short_open_tag | «1» | PHP_INI_PERDIR | |
| asp_tags | «0» | PHP_INI_PERDIR | Удалена в PHP 7.0.0. |
| precision | «14» | PHP_INI_ALL | |
| serialize_precision | «-1» | PHP_INI_ALL | До версии PHP 5.3.5 значение по умолчанию было равно 100. До версии PHP 7.1.0 значение по умолчанию было равно 17. |
| y2k_compliance | «1» | PHP_INI_ALL | Удалена в PHP 5.4.0. |
| allow_call_time_pass_reference | «1» | PHP_INI_PERDIR | Удалена в PHP 5.4.0. |
| disable_functions | «» | Только PHP_INI_SYSTEM | |
| disable_classes | «» | Только php.ini | |
| exit_on_timeout | «» | PHP_INI_ALL | Доступна с версии PHP 5.3.0. |
| expose_php | «1» | Только php.ini | |
| hard_timeout | «2» | PHP_INI_SYSTEM | Доступна с версии PHP 7.1.0. |
| zend.exception_ignore_args | «0» | PHP_INI_ALL | Доступна с версии PHP 7.4.0 |
| zend.multibyte | «0» | PHP_INI_ALL | Доступна с версии PHP 5.4.0 |
| zend.script_encoding | NULL | PHP_INI_ALL | Доступна с версии PHP 5.4.0 |
| zend.detect-unicode | NULL | PHP_INI_ALL | Доступна с версии PHP 5.4.0 |
| zend.signal_check | «0» | PHP_INI_SYSTEM | Доступна с версии PHP 5.4.0 |
| zend.assertions | «1» | PHP_INI_ALL с ограничениями | Доступна с версии PHP 7.0.0. |
| zend.ze1_compatibility_mode | «0» | PHP_INI_ALL | Удалена в PHP 5.3.0 |
| detect_unicode | «1» | PHP_INI_ALL | Доступна с версии PHP 5.1.0. Переименована на zend.detect-unicode с версии PHP 5.4.0. |
Краткое разъяснение конфигурационных директив.
| Версия | Описание |
|---|---|
| 7.0.0 | Удалена из PHP. |
Нужно ли выводить предупреждение, если аргументы передаются по ссылке при вызове функции. Рекомендуется указывать в объявлении функции передаваемые по ссылке аргументы. Попробуйте выключить эту опцию и убедиться, что ваши скрипты правильно работают без нее и что они будут работать с будущими версиями языка (вы будете получать предупреждение каждый раз, когда вы будете пользоваться этой возможностью).
Передача аргументов по ссылке во время вызова функции была объявлена устаревшей из соображений чистоты кода. Функция может менять свои аргументы недокументированным способом, если бы аргумент не объявлялся передаваемым по ссылке. Чтобы избежать побочных эффектов, лучше явно указывать, какие аргументы передаются по ссылке только при объявлении функции.
Эта директива позволяет отключить некоторые функции. Она принимает список имен функций, разделенный запятыми.
Только внутренние функции могут быть отключены с помощью этой директивы. Пользовательские функции ей не подвержены.
Если процесс стартован в режиме релиза, zend.assertions не может быть изменен во время выполнения, так как код утверждений не генерируется.
Включает режим совместимости с Zend Engine 1 (PHP 4). Это влияет на клонирование, приведение типов (объекты без свойств приводятся к false или 0) и сравнение объектов. В этом режиме объекты по умолчанию передаются по значению вместо ссылки.
Эта возможность была помечена УСТАРЕВШЕЙ и БЫЛА УДАЛЕНА в версии PHP 5.3.0.
Исключает аргументы из трассировки стека, сгенерированных из исключений.
Разрешает парсинг исходных файлов в многобайтных кодировках. Включение zend.multibyte требуется для использования кодировок символов подобных SJIS, BIG5 и т.д., содержащих специальные символы в многобайтных строковых данных. Совместимые с ISO-8859-1 кодировки, например UTF-8, EUC и т.д., не требуют эту опцию.
Модуль zend.multibyte требует установленного модуля «mbstring».
Данное значение будет использовано, только при отсутствии директивы declare(encoding=. ) в начале скрипта. При использовании кодировок несовместимых с ISO-8859-1, нужно использовать опции и zend.multibyte и zend.script_encoding.
Определяет, нужно ли проверять замененные обработчики сигналов при завершении скрипта.
Эта директива только для Apache1 mod_php, которая заставляет потомка Apache завершиться, если произошел тайм-аут исполнения скрипта PHP. Такой тайм-аут приводит к внутреннему вызову longjmp() в Apache1, который оставляет некоторые расширения в несогласованном состоянии. По завершении процесса все неснятые блокировки или память будут очищены.
Ограничения ресурсов
| Имя | По умолчанию | Место изменения | Список изменений |
|---|---|---|---|
| memory_limit | «128M» | PHP_INI_ALL | «8M» до PHP 5.2.0, «16M» в PHP 5.2.0 |
Краткое разъяснение конфигурационных директив.
Настройка производительности
| Имя | По умолчанию | Место изменения | Список изменений |
|---|---|---|---|
| realpath_cache_size | «4M» | PHP_INI_SYSTEM | Доступна с версии PHP 5.1.0. До PHP 7.0.16 и 7.1.2, по умолчанию было «16K» |
| realpath_cache_ttl | «120» | PHP_INI_SYSTEM | Доступна с версии PHP 5.1.0. |
Использование open_basedir отключит кеш realpath.
Краткое разъяснение конфигурационных директив.
Определяет размера кэша realpath, используемого в PHP. Это значение должно быть увеличено на системах, в которых PHP открывает большое количество файлов соответственно количеству выполняемых файловых операций.
Размер равный общему числу байт, хранящимся в строках путей, плюс размер данных связанных с кешируемым элементом. Это значит, что для хранения длинных путей в кэше, размер этого кэша должен быть больше. Это значение не определяет напрямую количество разных путей, которые могут быть закэшированы.
Размер, необходимый для кэширования, зависит от системы.
Время (в секундах) в течение которого будет использован кэш realpath для указанного файла или директории. Для систем с редко меняющимися файлами это значение можно увеличить.