Что может сделать странные изменения в коде opcached каркаса? - PullRequest
0 голосов
/ 16 мая 2018

Я столкнулся со странной ошибкой с моим php-fpm 5.6.30 с OPcache v7.0.6-dev на сервере Ubuntu.Я получил ошибку в /vendor/monolog/monolog/src/Monolog/Logger.php файле, касающемся array_keys(static::$levels) кода в нем:

array_keys () ожидает, что параметром 1 будет массив, объект задан

static::$levelsсвойство определяется в верхней части файла Logger.php как массив:

protected static $levels = array(
    self::DEBUG     => 'DEBUG',
    self::INFO      => 'INFO',
    self::NOTICE    => 'NOTICE',
    self::WARNING   => 'WARNING',
    self::ERROR     => 'ERROR',
    self::CRITICAL  => 'CRITICAL',
    self::ALERT     => 'ALERT',
    self::EMERGENCY => 'EMERGENCY',
);

Этот код был установлен через composer и никогда не редактировался вручную, поэтому нет причин для изменения файла.

Когда я смотрю на laravel.log, я вижу, что что-то изменило поведение кода, поэтому строки в журнале изменили свой формат:

[2018-05-16 00:19:22] production.INFO: blabla
[2018-05-16 00:20:04] production.[object] (DateTimeZone: {"timezone_type":3,"timezone":"UTC"}): blablabla

Ключевой факт заключается в том, что когда я открыл файл с помощьюnano, добавил в него строку комментария и сохранил, ошибка исчезла.Это означает, что неправильный код был в opcache, а не в коде фреймворка.

Итак, байт-код Logger.php был каким-то образом изменен, и php увидел объект с DateTimeZone объектами, а немассив строк.

Вопрос в том, как можно изменить кэшированный байт-код без полного сбоя?Что на земле может сделать это?Может ли высокое потребление памяти привести к таким неожиданным изменениям?

1 Ответ

0 голосов
/ 05 июня 2018

У нас была такая же проблема в нашем проекте (php 5.6.30, opcache v7.0.6-dev). Чтобы решить эту проблему, мы проанализировали настройки opcache и обнаружили, что interned_strings_buffer было 4Mb. Подняв это значение до 64 Мб, мы решили проблему.

...