Comments 73
Вот это да.
Apache я принципиально не использую, так как nginx умеет все
Далеко не все. Даже и не знаю, что вам посоветовать, что бы развеять миф, который вы тут написали. Сравните список модулей хотябы.
Последовала небольшая правка opcache.enable=0
и… проблема исчезла. Ее больше нет. Три несчастных сайта радостно рабоют, сервер мерно сопит в 384 дырки вентиляционного отверсия, а я чуть коснулся нирваны и даже прослушал пару треков.
http://php.net/manual/ru/opcache.configuration.php#ini.opcache.use-cwd
UFO just landed and posted this here
Допустим ldap auth. На gh есть реализация сторонего разработчика и использовать его, увы нельзя, т.к. во многих компаниях присутствует ограничения связанные с ИБ.
Nginx отличный продукт, но он не позиционирует себя как полная альтернатива apache2.
.htaccess можно описывать в конфигах, просто основная масса разработчиков привыкла описывать все в .htaccess и многие делают это бездумно.
Nginx отличный продукт, но он не позиционирует себя как полная альтернатива apache2.
Знаете, какое основное преимущество nginx перед apache для меня лично? Нормальная система организации конфигурационных файлов (когда всё в одном месте, а не размазано где-то там по .htaccess) — это очень удобно, когда получаешь чужой проект.
.htaccess можно описывать в конфигах, просто основная масса разработчиков привыкла описывать все в .htaccess и многие делают это бездумно.
Давайте не будет мешать все в одну кучу.
Я не указал, что именно умеет nginx, написав как «все», в то же самое время не указан и сектор применения. Но три php сайта, упомянутых в заметке — явно не корпоративный сектор, где и iis используют.
В плане конфигов и написания конфигов — nginx удобнее и сподручнее. В плане скорости работы — тут ему апач не ровень, по статике и по динамике.
Спасибо ща линк, но я лучше оставлю opcache отключенным, ибо мне его функционал не нужен, у меня кеширование реализовано на стороне nginx.
Я не указал, что именно умеет nginx, написав как «все», в то же самое время не указан и сектор применения. Но три php сайта, упомянутых в заметке — явно не корпоративный сектор, где и iis используют.
В плане конфигов и написания конфигов — nginx удобнее и сподручнее. В плане скорости работы — тут ему апач не ровень, по статике и по динамике.
http://php.net/manual/ru/opcache.configuration.php#ini.opcache.use-cwd
Спасибо ща линк, но я лучше оставлю opcache отключенным, ибо мне его функционал не нужен, у меня кеширование реализовано на стороне nginx.
Допустим ldap auth
аж три варианта:
если есть деньги: https://www.nginx.com/blog/nginx-plus-authenticate-users/
если нет денег: https://github.com/kvspb/nginx-auth-ldap
если нет денег и не хочется что-то пересобирать — мидлвэр между приложением и nginx или же на уровне приложения.
Действительно, есть не всё и иногда приходится танцевать с бубном.
Но из-за обильности вариантов настройки Apache, он иногда ведет себя странно. И чем длиннее конфиг, тем чудесатее поведение Apache. Доходит до смешного — еженедельный рестарт Apache необходим, иначе через 2 недели он залипает.
Я не говорю что nginx абсолютно понятен и безглючен, но только при работе с Apache у нас в офисе выдается бубен.
В nginx нет AssignUserID, чтобы закрыть пользователя в его хомяке и не пускать к остальным, чтобы nginx писал под правами пользователя. Отключение htaccess в апаче кроме рутового существенно ускоряет его (хотя макросами можно подключить все необходиме htaccess). Ну и макросов в nginx очень нехватает. Приходится писать свой генератор конфига.
чтобы nginx писал под правами пользователя
У меня nginx-у запрещено "писать".
чтобы закрыть пользователя в его хомяке и не пускать к остальным
При верно настроенном в конфиге root nginx не лазает по серверу в целом, а проблему «кто-то закинул символич. ссылку» решается просто отключением обработки этих самых ссылок в соотв. конфигах (популярнные CMS, к примеру).
чтобы nginx писал под правами пользователя.
У меня nginx писал только в случае с webdav, которая так же изолорована в конфигах (nginx).
Ну и макросов в nginx очень нехватает
Из «коробки» в конфигах nginx можно реализовывать простую логику на основе if и переменных, но очень простую. Для продвинутого варианта конфигов есть lua модуль. Правда я им никогда не пользовался, но его потенциал мне интересен. Если вы про логику конфигов…
Увы, нам на сервере разработки (там у каждого разработчика и у каждого релиза свой поддомен на одном php-fpm) опция use-cwd проблему не решила, решал проблему так же — отрубил opcache.
Opcache не надо использовать в development окружении.
Если требуется полная изоляция, то надо юзать отдельный пулл fpm для проекта.
Если требуется полная изоляция, то надо юзать отдельный пулл fpm для проекта.
Если требуется полная изоляция, то надо юзать отдельный пулл fpm для проекта.
Мне уже лень отвечать таким комментаторам. ctrl+F пулл на страничке.
Из топика я увидел только проблему и никакой конкретики, все только на словах. Я использую opcache на всех проектах крупных проектах под нагрузкой и проблем таких не было. Суть поста сводится к нулю, ибо вы проблему не решили, а обошли.
Я использую php во всех 3х мелких проектах, на плавающей нагрузке (между лещем и золотой рыбкой). Проблема… Сие безобразие прекрасно устраняется отключением opcache на моем сервере.
Честное слово, кучу говна лучше обойти, чем рыться в ней и докапываться почему ее тутнасрали накодили.
Исправили в другой 5.6? Исправили в 7? Какая разница. PHP мне вообще не важен, крутился бы блок и форум.
Честное слово, кучу говна лучше обойти, чем рыться в ней и докапываться почему ее тут
Исправили в другой 5.6? Исправили в 7? Какая разница. PHP мне вообще не важен, крутился бы блок и форум.
Спустя год, при включении opcache проблема там же.
В моем случае — при использовании chroot opcache не отдупляет /home/user1/www & /home/user2/www, а отдупляет их как /www & /www. И соотв. даже при использовании опции cwd будет косяк, так как путь для профиля (в chroot) он в пределах chroot'а, а не глобальный.
Как же чудно что в 2017-ом можно решить эти проблемы банальной изоляцией на уровне LXC/Docker/Rkt...
Уникальными путями в пределах chroot'а.
ответ на вопрос, который подтвердает мои опасения.
[del]
Странно, сколько пользуюсь такой же связкой с десятком сайтов ни разу не натыкался на такую «коллизию». Статья без логов подобной «ошибки» выглядит пустоватой (логи nginx / php-fpm могли бы пролить свет на эту ситуёвину или хотя-бы помогли понять на какой стадии запрос «умирал» и с каким стактрейсом).
Хоть бы версию PHP сказали и опции php.ini, которые относятся к opcache
подозреваю что все по дефолту. А можно было бы побаловаться.
5.6.18
А настройки-то какие?
«Из коробки»:
В
Данный ini как наследие с более древней версии, но
04-suhosin.ini
05-opcache.ini
10-pdo.ini
20-curl.ini
20-gd.ini
20-imagick.ini
20-json.ini
20-mcrypt.ini
20-memcached.ini
20-memcache.ini
20-mysqli.ini
20-mysql.ini
20-pdo_mysql.ini
20-pdo_sqlite.ini
20-readline.ini
20-sqlite3.ini
20-xmlrpc.ini
20-xsl.ini
В
php.ini добавлены disable_functions, memory_limit и подкручены настройки smtp, safe mode выключен, а cgi.fix_pathinfo равен 0.Данный ini как наследие с более древней версии, но
diff -uraN выдает немного правок в сравнении с PHP-5.6.18/php.ini-production.
У меня с opcache вот такая проблема уже давно висит: https://toster.ru/q/126933.
Проблема в том, что проект нагруженный и без него нагрузка на сервер вырастает очень сильно.
Проблема в том, что проект нагруженный и без него нагрузка на сервер вырастает очень сильно.
Если php-fpm имел разный пул для каждого сайта, как они тогда пересекались? думаю в вашей конфигурации были не раздельные пулы.
Неверно думаете. Каждый из 3х сайтов висит на своем пуле в своей home под своей учеткой в своей группе на своем порте.
на порте? зачем?
Как зачем?
Можно использовать как tcp сокеты, так и unix сокеты. Последние никто использовать не заставляет, да и нет надобности 20%-30% бусте для передачи ответа от динамики, хотя для параноика будет приятнее (права к файлам).
Но проблема была на обоих сокетах (и tcp и unix) и, как я писал это в статье, разрешилась отключением opcache.
Можно использовать как tcp сокеты, так и unix сокеты. Последние никто использовать не заставляет, да и нет надобности 20%-30% бусте для передачи ответа от динамики, хотя для параноика будет приятнее (права к файлам).
Но проблема была на обоих сокетах (и tcp и unix) и, как я писал это в статье, разрешилась отключением opcache.
Точно не осталось примеров конфигурации с разными пулами? Дело в том что они действительно должны быть изолированы друг от друга. Про use-cwd вам уже писали. И кроме того, кеш nginx и opcache в php это сильно разные вещи все-таки. Вы проблему не нашли, вы её избежали путём сознательной просадки производительности.
Дело в том что они действительно должны быть изолированы друг от друга.
На разные сервера вынести?) Не удержался.
user/group, chroot и listen на своем порте.
И кроме того, кеш nginx и opcache в php это сильно разные вещи все-таки.
Конечная цель-то одна. Лишь пхп отдает свежий ответ от заранее скомпиленного скрипта, а nginx отдает заранее сохраненный ответ. Кеш nginx у меня сделан хитро, и бОльшая часть юзеров видит закешированный ответ на тех сайтах, и лишь некоторые имеют кеш по кукисам.
сознательной просадки производительности
Ничего не просело, все спрятано за nginx и сайты не рилтайм.
Насколько я понял описание всего вашего Web-хозяйства, оно а) малонагруженное, и б) использует достаточно мощное железо. Просадка просто незаметна. Полагаю, что если бы вам нужно было обслуживать высоконагруженный сервер с сотнями килопосетителей в час, вы бы слегка иначе смотрели бы на Opcache и его альтернативы.
Вам конкретно он не нужен. Замечательно. Я сам предпочитаю статику и кэширование везде, где только возможно — существенно улучшает ситуацию в т.ч. с точки зрения информационной безопасности.
Когда и если вам потребуется поддержка чего-то жутко нагруженного и требовательного е ресурсам, да ещё и работающего на PHP, будет веский повод вернуться к нашим барашкам. :)
Вам конкретно он не нужен. Замечательно. Я сам предпочитаю статику и кэширование везде, где только возможно — существенно улучшает ситуацию в т.ч. с точки зрения информационной безопасности.
Когда и если вам потребуется поддержка чего-то жутко нагруженного и требовательного е ресурсам, да ещё и работающего на PHP, будет веский повод вернуться к нашим барашкам. :)
обслуживать высоконагруженный сервер с сотнями килопосетителей в час
Самописные (JSP) легко держали около наплыв около 36000 уников за 24 часа (большей частью США, спасибо реддиту), больше проекты никогда собирали. Так что burst был хороший:-)
если вам потребуется поддержка чего-то жутко нагруженного и требовательного е ресурсам, да ещё и работающего на PHP
Надеюсь, что до такого PHP не дойдет :-)
А ежели и дойдет, то буду брать сервер, и специально фитить его для php, если хватит ресурсов, то и базу туда же воткну.
"Она уверенно разыгрывала испанскую партию, ей не менее уверенно отвечали сицилианской защитой".
Это к тому, что странно сравнивать JSP и PHP в данном контексте. Таки совершенно разные комплекты грабель. Примерно как тёплое с мягким сравнивать.
В общем, пока у вас нет необходимости в «акселераторах», спорить решительно не о чем.
Это к тому, что странно сравнивать JSP и PHP в данном контексте. Таки совершенно разные комплекты грабель. Примерно как тёплое с мягким сравнивать.
В общем, пока у вас нет необходимости в «акселераторах», спорить решительно не о чем.
Это к тому, что странно сравнивать JSP и PHP в данном контексте.
Потому, что каждый упорно делает аспект на том, что в «моем случае» или «если бы мои php», когда php это последнее,
И отключение глючного на 5.6.18 opcache пришлось к месту, так как решило проблему. И даже, если проблему пофиксили в будущих версиях, я все равно не буду обновлять PHP (и всю гирлянду его зависимостей), а оставлю как есть, без opcache.
> я все равно не буду обновлять PHP (и всю гирлянду его зависимостей), а оставлю как есть, без opcache
Сайты видны всем желающим в Интернете? Если да, то категоричное «не буду обновлять» таки может боком выйти. Уязвимости, знаете ли, это явления, с которыми лучше считаться.
Но это, естественно, ваше дело.
Сайты видны всем желающим в Интернете? Если да, то категоричное «не буду обновлять» таки может боком выйти. Уязвимости, знаете ли, это явления, с которыми лучше считаться.
Но это, естественно, ваше дело.
Так просто почитайте как эксплотирются уязвимоости!
Про движки я молчу — там апдейты регулярные, но и потенциальные дырки закрыты (xmlrpc или комменты на WP).
А до багов PHP пытаются достучаться или через запросы к серверу, или локально (аплоад файла через баг в CMS).
Никто не мешает вам контролировать что ваш сервер может получать из мира сего придумав логику в конфигах nginx, вооружившись регулярками в том числе.
Про движки я молчу — там апдейты регулярные, но и потенциальные дырки закрыты (xmlrpc или комменты на WP).
А до багов PHP пытаются достучаться или через запросы к серверу, или локально (аплоад файла через баг в CMS).
Никто не мешает вам контролировать что ваш сервер может получать из мира сего придумав логику в конфигах nginx, вооружившись регулярками в том числе.
Позвольте, мне-то зачем выговаривать? Я вроде бы категоричных заявлений не делаю.
Несогласие с вашим мнением = выговор?
в купе с
для PHP это из разряда "включи центр обновлений windows и думай, что получаешь наслаждение", аргументированное "но там же апдейты безопасности, security!", хотя на деле бОльшая часть апдейтов это частные случаи, которых можно избежать.
Пока для PHP есть (очень для старых) версий мелкие баги, которые эксплуатируются через строку запроса, я могу спать спокойно, так как я контролирую запросы к серверу.
Если же, вдруг, внезапно, забагала сама CMS (modx/phpbb/wp) и закачали левый файл, через который багнули мой fpm, то максимум, чем я рискую — это директория самого сайта. Учетки пула не могут лазить по серверу, у них не те права. У них свой chroot и они зарезаны дополнительным софтом. Сервер (система) всегда up to date.
Уязвимости, знаете ли, это явления, с которыми лучше считаться.
в купе с
то категоричное «не буду обновлять» таки может боком выйти
для PHP это из разряда "включи центр обновлений windows и думай, что получаешь наслаждение", аргументированное "но там же апдейты безопасности, security!", хотя на деле бОльшая часть апдейтов это частные случаи, которых можно избежать.
Пока для PHP есть (очень для старых) версий мелкие баги, которые эксплуатируются через строку запроса, я могу спать спокойно, так как я контролирую запросы к серверу.
Если же, вдруг, внезапно, забагала сама CMS (modx/phpbb/wp) и закачали левый файл, через который багнули мой fpm, то максимум, чем я рискую — это директория самого сайта. Учетки пула не могут лазить по серверу, у них не те права. У них свой chroot и они зарезаны дополнительным софтом. Сервер (система) всегда up to date.
А передёргивать зачем, простите?
> для PHP это из разряда «включи центр обновлений windows и думай, что получаешь наслаждение»
Отнюдь нет. Это из разряда «читай про обновления всех используемых модулей PHP, и не забывай обновлять, если они тебя касаются». Слегка отличается от «не обновляю, и не буду».
> для PHP это из разряда «включи центр обновлений windows и думай, что получаешь наслаждение»
Отнюдь нет. Это из разряда «читай про обновления всех используемых модулей PHP, и не забывай обновлять, если они тебя касаются». Слегка отличается от «не обновляю, и не буду».
А передёргивать зачем, простите?
не благодарите
Это из разряда
В плане PHP мне хватает зайти 1 раз в день-два на хабр, если справа ничего нет, значит нет смысла суетится.
Ну и, наконец, перечитайте внимательно, какие о каких апдейтах идет речь. Или вы пытаетесь меня ловить на словах, вертя их так и так? Мол такой школьный челленж? Уж не танцевать ли в треде пытаетесь?
Я не кричу, просто громко печатаю, у меня пальцы сильные.
Неа в топку, я на JSP код пишу.
Java разработчик не справился с php? :D ROFL
Java разработчик не справился с php? :D ROFL
С какой стати Java кодер должен разбираться с php? Разве нет более важных дел?)
Почему нет, «справился» — отрубил опкэш :)
Я вот хоть не java-разработчик, но было что-то похожее на php 7.0, перепробовал множество настроек, это не помогло (оно и понятно, до этого работало, после апгрейда перестало)
Не знаю помогло бы мне, будь я java-разработчиком, но временно пришлось отключить opcache
В итоге спустя пару php сборок это исправили и включил обратно
Не знаю помогло бы мне, будь я java-разработчиком, но временно пришлось отключить opcache
В итоге спустя пару php сборок это исправили и включил обратно
А сама логика opcache: кеширует результат компиляции php файла. По дефолту 2 секунды. Что позволяет выполнить 20 раз php файл за эти самые 2 секунды при 10 запросах в секунду без повторной перекомпилации.
Вроде бы круто. Но если на nginx у вас кеш от 1 до 10 секунд, а сайт не realtime, то я не вижу смысла (в моем случае) использовать opcache, чтобы быстрее отдавать, так как ответ сервера уже записан в кеш под тем или иным ключом (к примеру с учетом кукисов или нет).
Вроде бы круто. Но если на nginx у вас кеш от 1 до 10 секунд, а сайт не realtime, то я не вижу смысла (в моем случае) использовать opcache, чтобы быстрее отдавать, так как ответ сервера уже записан в кеш под тем или иным ключом (к примеру с учетом кукисов или нет).
Скорее запись в жалобную книгу, нежели информативная статья: «есть в PHP Opcache какой-то баг, проверять обновления я не стал, просто отключил Opcache». В статье, на которую ссылка, также нет упоминания записи в bugs.php.net, чтобы следить за статусом бага.
Так в статье есть ссылка, и даже приведена цитата, что ранее об этом сообщали. Какой смысл плодить новые тикеты?
Обновлять 5.6.18 на 7-ую версию я не буду, так как то, что требует php нормально себе работает на 5.6.18. И тут не хостинг компания, не хостинг сайтов клиентов, а 3 небольших сайта за мощной спиной nginx'а. Я бы рад от них избавится, но заменить нечем, хотя бы тот же wordpress.
Обновлять 5.6.18 на 7-ую версию я не буду, так как то, что требует php нормально себе работает на 5.6.18. И тут не хостинг компания, не хостинг сайтов клиентов, а 3 небольших сайта за мощной спиной nginx'а. Я бы рад от них избавится, но заменить нечем, хотя бы тот же wordpress.
В статье (англоязычной) нет ссылки на баг в трекере PHP, только общая фраза «This problem in opcache has been reported for a long time, but by the time of this article it has not been fixed yet.»
Насколько понимаю, возможные обходные манёвры, вроде «opcache.use_cwd = 1» не проверялись?
JFYI, текущая версия ветки 5.6: 5.6.23.
Насколько понимаю, возможные обходные манёвры, вроде «opcache.use_cwd = 1» не проверялись?
JFYI, текущая версия ветки 5.6: 5.6.23.
В статье (англоязычной) нет ссылки на баг в трекере PHP
Мне так же лень искать, как и им.
вроде «opcache.use_cwd = 1» не проверялись
Нет. После получения наводки на opcache и его отключения все встало на свои места. Немного погуглив про opcache я понял, что погоды он мне не сделает. Кеш nginx всем контентом заведует.
JFYI
Я уже не помню, зачем на 5.6.18 переходил. Вероятно из-за каких-то частных системных апдейтов поломался старый php, судя по датам конфигов это был апдейт libc.
Э-э-э… А вы не пробовали разные сайты в разных пулах fpm крутить? Это же не просто так придумано…
P.S. По сравнению с APC мне opcache дал очень много стабильности. Просто надо правильно его готовить.
P.S. По сравнению с APC мне opcache дал очень много стабильности. Просто надо правильно его готовить.
Вы очень вовремя с этой статьёй. Недавно переехал с Апача на NGINX + php-fpm и начал наблюдать на пуле клиентских сайтов с такую же проблему: один сайт работает, а какой-то другой валиться с 502-й. Точнее либо клиентские на Вордпрессе работают, либо мой самописный. Помогал перезапуск php-fpm. Надеюсь ваше решение поможет.
Напишите потом в комментарии помого или нет.
Постараюсь не забыть
3 дня – полёт нормальный. Раньше за это время уже что-нибудь упало бы. Можно сказать, способ рабочий.
3 дня – полёт нормальный. Раньше за это время уже что-нибудь упало бы. Можно сказать, способ рабочий.
Спасибо!
К сожалению не могу вам поставить плюс (время истекло), но плюс в карме от меня у вас есть!
nikitasius к сожалению, вчера снова php-fpm начал падать
Надеюсь ваше решение поможет.
отключение opcache это скорее кастыль нежели решение. Попробуйте запускать разные сайты в разных docker контейнерах к примеру. Тогда будет полная изоляция shared memory и при этом не нужно будет париться об этом. Один fpm пул на контейнер. Тоже своего рода кастыль но можно из этого огромное количество других плюсов вытащить.
Серьезно? Под полтора микросайта ставить докер, когда бага в PHP?! Объясните пожалуйста: нахрена?!!!
Это таких эпических размеров костылище, что мне аж на голову не налазит.
Ну я докер использую как часть моего процесса разработки (как поддержвание инфраструктуры так и для выкатки в продакшен) потому мне это не кажется кастылем. Специфика работы. Да и что за "полтора микросайта"? для "одного микросайта!". Мы же изолировать хотим.
А так я со своей позиции так же могу говорить что вырубать opcache который дает PHP адекватную производительность это и есть кастыль. Но если для ваших задач это не столь важно — то ок.
Вот читаю я комментарии, и понимаю что приблизительно половина «администраторов» не пытается разобраться в проблеме. «У меня ошибка 502». При этом логирование ошибок PHP не настроено, логирование ошибок OPCACHE тоже отключено. Попыток разобраться нет, но есть попытки решить проблему методом инженерного тыка. Автор статьи предложил простейший вариант, без глубокого анализа ситуации и без дисклеймера о возможных последствиях данного решения, при этом выставляя «серебрянной пулей» кеш nginx. Я, кстати, тоже с глубоким уважением отношусь к nginx и использую его в боевых системах, однако серебрянной пули в ИТ просто нет. Для каждой проблемы существует свой интрумент и свой путь решения, скорее всего не один.
Например, у opcache кроме use-cwd есть много других интересных настроек. Например, если мы знаем, что проблема в конкретном файле — opcache.blacklist_filename. Если мы получаем ошибку «Cannot redeclare class», то надо использовать opcache.dups_fix=1.
Судя по всему, автор выбросил микроскоп, потому что им неудобно забивать гвозди.
Поскольку в статье дисклеймера нет, позвольте его добавить: «Коллеги, будьте добры, разбирайте каждую проблему до конца. Бросать разбор на полпути — это достойно только мальчика-энекейщика, который банально не смог дочитать документацию и/или логи ошибок. Не выбрасывайте микроскоп, как и любой другой инструмент. Лучше позовите на помощь более опытного коллегу, и он покажет вам способ поиска корня проблемы».
Например, у opcache кроме use-cwd есть много других интересных настроек. Например, если мы знаем, что проблема в конкретном файле — opcache.blacklist_filename. Если мы получаем ошибку «Cannot redeclare class», то надо использовать opcache.dups_fix=1.
Судя по всему, автор выбросил микроскоп, потому что им неудобно забивать гвозди.
Поскольку в статье дисклеймера нет, позвольте его добавить: «Коллеги, будьте добры, разбирайте каждую проблему до конца. Бросать разбор на полпути — это достойно только мальчика-энекейщика, который банально не смог дочитать документацию и/или логи ошибок. Не выбрасывайте микроскоп, как и любой другой инструмент. Лучше позовите на помощь более опытного коллегу, и он покажет вам способ поиска корня проблемы».
Судя по всему, автор выбросил микроскоп, потому что им неудобно забивать гвозди
Просто автору нет дела до причин неработоспособности opcache в силу того, что php на сервере это как небольшая
Автор статьи предложил простейший вариант, без глубокого анализа ситуации и без дисклеймера о возможных последствиях данного решения, при этом выставляя «серебрянной пулей» кеш nginx.
Кеш nginx это очень и очень мощный инструмент. По дефолту, из коробки, opcache компилит php 1 раз в 2 секунды. У меня кеш от 1 до 20 секунд на тех php сайтах. Причем не просто кеш, а кеш с fastcgi_cache_lock. Некоторая динамика вынесена на CF как API, что вообще снимает с меня нагрузку на 4 часа.
В итоге:
- Узнав, что это opcache косячит — починить его потратив на это свои человекочасы, правильно настроить, потратив на это бесполезное в данном случае занятие снова человеко часы, протестировать сие в течении пары дней, читая логи (как хорошие так и плохий). Написать что-нить о починке, про траляля. Не себе, а людям php программистам.
- Узнав, чтр это opcache косячит — отрубить его. Написать об этом рассказав nginx и дав php программистах свободу для действий в случае если они натолкнутся на этот же самый баг.
Я ейбогу не хочу тратить свое время на решение этой проблемы. Для меня opcache это не что-то сверх важное, что бустит перфоманс или определяет мой доход, а просто очередная примочка, от которой я могу свободно отказаться в силу:
- мощного железа
- кеша nginx
- кеша CDN
- низкой популярности 3х сайтов
Баг — не баг: https://bugs.php.net/bug.php?id=67481
Фича анализируется: https://bugs.php.net/bug.php?id=69090
Фича анализируется: https://bugs.php.net/bug.php?id=69090
Sign up to leave a comment.
Как opcache портил мою жизнь и тратил мои нервы