- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
В 2023 году Одноклассники пресекли более 9 млн подозрительных входов в учетные записи
И выявили более 7 млн подозрительных пользователей
Оксана Мамчуева
Что делать, если ваша email-рассылка попала в спам
10 распространенных причин и решений
Екатерина Ткаченко
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
livetv просто думается что мои opcache настройки как то перекруччены или недокручены. nginx frontend, апач нужен из-за htaccess.
Вам не кажется, что не видя Ваш конфиг и статус, конкретные советы будут телепатией? :)
Не хотите давать весь вывод.
Дайте только касательно Opcache (там две секции). Но желательно увидеть положение вещей перед падением.
PHP - модуль апача или fastcgi/fpm?
Это у вас типа шаред хостинг (куча клиентов, бла-бла-бла)? На них обычно Opcache не включают :)
Не знаю, как сейчас, но раньше кеш Opcache был раздельный для всех процессов php.
Также покажите top перед падением.
Уменьшите кол-во апачей до 100 (хотя, если у вас 24 ядра у куча памяти, то можно и не делать).
Что в логах PHP/apache?
Установите PHP из исходников, хрен его знает, чего они туда намешали.
Добавление
Только что повис другой сервер, проанализировав всё детально, был 1 процесс апача который таки выжирал 100% ядра, если его прикончить, то сразу же за работу берётся другой процесс, от другого юзера. Причём эти все процессы запущены давно и спят, т.е. это те самые потомки что ждут ZendSem залоченный файл, хотя это не файл вовсе, поэтому и (deleted) - что оказывается нормально...
Так вот, такой процесс занят серьёзной бесконечной работой:
fcntl(2965, F_GETLK, {type=F_RDLCK, whence=SEEK_SET, start=1, len=1, pid=19389}) = 0
kill(19389, SIGKILL) = -1 EPERM (Operation not permitted)
fcntl(2965, F_GETLK, {type=F_RDLCK, whence=SEEK_SET, start=1, len=1, pid=19389}) = 0
kill(19389, SIGKILL) = -1 EPERM (Operation not permitted)
fcntl(2965, F_GETLK, {type=F_RDLCK, whence=SEEK_SET, start=1, len=1, pid=19389}) = 0
kill(19389, SIGKILL) = -1 EPERM (Operation not permitted)
fcntl(2965, F_GETLK, {type=F_RDLCK, whence=SEEK_SET, start=1, len=1, pid=19389}) = 0
kill(19389, SIGKILL)
Получается что всё стопорится на этом бесконечном локе F_RDLCK и странном киллинге, а все другие процессы апача как раз ждут окончание этого деяния ☝ хммм...
livetv я ведь в самом начале привёл те параметры что отличают opcache от дефолтного, php модуль apache itk.
Вот все параметры:
opcache.consistency_checks 0 0
opcache.dups_fix Off Off
opcache.enable On On
opcache.enable_cli On On
opcache.enable_file_override Off Off
opcache.error_log no value no value
opcache.fast_shutdown 0 0
opcache.file_cache no value no value
opcache.file_cache_consistency_checks 1 1
opcache.file_cache_only 0 0
opcache.file_update_protection 2 2
opcache.force_restart_timeout 180 180
opcache.huge_code_pages Off Off
opcache.inherited_hack On On
opcache.interned_strings_buffer 16 16
opcache.lockfile_path /tmp /tmp
opcache.log_verbosity_level 1 1
opcache.max_accelerated_files 10000 10000
opcache.max_file_size 0 0
opcache.max_wasted_percentage 5 5
opcache.memory_consumption 256 256
opcache.optimization_level 0x7FFFBFFF 0x7FFFBFFF
opcache.preferred_memory_model no value no value
opcache.protect_memory 0 0
opcache.restrict_api no value no value
opcache.revalidate_freq 2 2
opcache.revalidate_path Off Off
opcache.save_comments 1 1
opcache.use_cwd On On
opcache.validate_timestamps On On
Апатч тоже последней версии?
Ваша ситуация:
http://forum.ubuntu.ru/index.php?topic=129216.0
---------- Добавлено 01.10.2016 в 13:21 ----------
livetv я ведь в самом начале привёл те параметры что отличают opcache от дефолтного, php модуль apache itk.
Мне больше интересен был статус перед проблемой.
Можно сделать php не модулем: fastcgi/fpm, тогда проблема должна уйти.
Но я не знаю, как настраивать многопользовательность при этом (тем более с Apache).
Можете каждому пользователю выделить отдельный пул fpm.
Поэтому повторю, что на шаред хостингах обычно нету Opcache (хотя они как бы могли снизить нагрузку и использование памяти).
livetv, действительно, по вашей ссылке ситуация очень похожа, попробую обдумать, но наверное придётся просто отключить opcache везде, жаль жаль...
У Вас
opcache.revalidate_freq 2 2
Если много файлов, то может стоит увеличить?
Чтобы реже проверяло.
Это вызовет задержку при изменении файлов.
Увеличение не устроит пользователей которые меняют свои php в лайв режиме)
Вот на что наткнулся в ченжлоге:
php 7.0.10
Opcache:
Fixed bug #72590 (Opcache restart with kill_all_lockers does not work).
https://bugs.php.net/bug.php?id=72590
Самое печальное что они якобы исправили это в 7.0.10, с которой у нас собственно и началось всё, просто проявляется это на паре самых нагруженных серверов, которые были как раз нагружены за последние пару месяцев. Поэтому чётко не получится сказать, прямая связь с нагрузкой или с версией 7.0.10 :(
Хотел бы подытожить для тех кому это интересно.
Проблема действительно связана с https://bugs.php.net/bug.php?id=72590
Это подтвердилось как через strace так и через логи opcache.
Суть проблемы в том что PHP внёс исправление после которого теперь работает форсированный рестарт opcache, ранее рестарт не работал. А суть рестарта заключается в том, что если рестарт не проходит гладко то сам opcache начинает убивать некоторые процессы апача, НО, так как мы имеем дело с itk, то один юзерский процесс апача не может прикончить другого, так как это разные юзеры. От сюда получаем бесконечный вечный цикл, пока процесс сам не умрёт, как это бывает? Один из процессов выполняет долгую работу, может быть даже выставлен set_time_limit(0), пока процесс не завершится, лежит весь апач, так как убить этот процесс невозможно.
Что делать? Кручение каких либо настроек, не дало никаких результатов, единственное и последнее что сейчас тестируется это настройка opcache.force_restart_timeout = 180 (default), собственно она и регулирует процесс перезагрузки, если перезагрузка не проходит гладко то через 180 секунд начиниется killing. Я просто выставил значание 100000, что по сути превышает 1 день, в данном случае если гадкий залоченный процесс и будет висеть около дня, то зачистка не запустится так как будет выжидание этого времени. В добавок к этому у нас идёт ежедневная зачистка таких висящих процессов. Денёк полёт нормальный, скорее всего это решит проблему, если нет, то последнее решение это полностью отключать opcache. 🙅
Dimanych, 7ку ещё пол года-год надо обходить стороной, 5.6 вполне годный и без глюков.
Dimanych, 7ку ещё пол года-год надо обходить стороной, 5.6 вполне годный и без глюков.
7ка у нас ещё с беты в продакшене обхаживалась - без каких либо проблем, проблема с опкеш возникла только недавно. А в 5.6 эта проблема ещё успеет повсплывать, исходя из того что этот bugfix импортирован и в 5.6:
[2016-09-05 15:06 UTC] jpauli@php.net
Backported to PHP-5.6 today
Так что будьте на чеку, особенно те кто c itk :)