PDOException: пакеты не в порядке. Ожидается 0, получено 1. Размер пакета = 23.Php

Кемеровские программисты php общаются здесь
Ответить
Anonymous
 PDOException: пакеты не в порядке. Ожидается 0, получено 1. Размер пакета = 23.

Сообщение Anonymous »

У меня есть проект Laravel Spark, который использует Horizon для управления очередью заданий с помощью Redis.
Локально (на моем компьютере Homestead, Mac OS) все работает так, как ожидалось, но на нашем новый дроплет Digital Ocean (предоставленный Forge), который представляет собой оптимизированный для памяти 256 ГБ, 32 виртуальных процессора, 10 ТБ и 1x 800 ГБ VPS, я продолжаю получать ошибку:

Код: Выделить всё

PDOException: Packets out of order. Expected 0 received 1. Packet size=23
Или какой-то вариант этой ошибки, где информация о размере пакета может отличаться.
После многих часов/дней отладки и исследований у меня есть встречал множество сообщений на StackOverflow и в других местах, которые, кажется, указывают на то, что это можно исправить, выполнив ряд действий, перечисленных ниже:
  • Установить PDO::ATTR_EMULATE_PREPARES в true в моя конфигурация data.php. Это абсолютно не влияет на проблему и фактически создает еще одну проблему, при которой целые числа преобразуются в строки.
  • Установите DB_HOST на 127.0.0.1 вместо localhost, чтобы вместо UNIX-сокета использовался TCP. Опять же, это не имеет никакого эффекта.
  • Задайте для DB_SOCKET путь к сокету, указанный в MySQL, войдя в MySQL (MariaDB) и запуск переменных показа, таких как '%socket%';, в которых путь к сокету указан как /run/mysqld/mysqld.sock. Я также оставляю для DB_HOST значение localhost. Это тоже не имеет никакого эффекта. Я заметил одну вещь: для переменной pdo_mysql.default_socket установлено значение /var/run/mysqld/mysqld.sock. Я не уверен, является ли это частью проблемы?
  • Я значительно увеличил параметры конфигурации MySQL, находящиеся в /etc/mysql/mariadb.conf.d/50-server.cnf к следующее:
Должен признаться, что изменение этих настроек было последним сценарий типа «прибегать/хвататься за соломинку». Тем не менее, это в некоторой степени облегчило проблему, но не устранило ее полностью, поскольку MySQL по-прежнему дает сбой в 99% случаев, хотя и на более позднем этапе.
С точки зрения очередь, у меня всего 1136 рабочих, разделенных между 6 супервизорами/очередями, и все это обрабатывается через Laravel Horizon, который запускается как демон.
Я также использую PHP-пакет Laravel Websockets для широковещания, который также запускается как демон.
Моя текущая конфигурация среды следующая (конфиденциальная информация опущена).

Код: Выделить всё

APP_NAME="App Name"
APP_ENV=production
APP_DEBUG=false
APP_KEY=thekey
APP_URL=https://appurl.com
LOG_CHANNEL=single

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=databse
DB_USERNAME=username
DB_PASSWORD=password

BROADCAST_DRIVER=pusher
CACHE_DRIVER=file
QUEUE_CONNECTION=redis
SESSION_DRIVER=file
SESSION_LIFETIME=120

REDIS_HOST=127.0.0.1
REDIS_PASSWORD=null
REDIS_PORT=6379

MAIL_MAILER=smtp
MAIL_HOST=smtp.gmail.com
MAIL_PORT=587
MAIL_USERNAME=name@email.com
MAIL_PASSWORD=password
MAIL_ENCRYPTION=tls
MAIL_FROM_ADDRESS=name@email.com
MAIL_FROM_NAME="${APP_NAME}"

AWS_ACCESS_KEY_ID=
AWS_SECRET_ACCESS_KEY=
AWS_DEFAULT_REGION="us-east-1"
AWS_BUCKET=

PUSHER_APP_ID=appid
PUSHER_APP_KEY=appkey
PUSHER_APP_SECRET=appsecret
PUSHER_APP_CLUSTER=mt1

MIX_PUSHER_APP_KEY="${PUSHER_APP_KEY}"
MIX_PUSHER_APP_CLUSTER="${PUSHER_APP_CLUSTER}"

AUTHY_SECRET=

CASHIER_CURRENCY=usd
CASHIER_CURRENCY_LOCALE=en
CASHIER_MODEL=App\Models\User
STRIPE_KEY=stripekey
STRIPE_SECRET=stripesecret

# ECHO SERVER
LARAVEL_WEBSOCKETS_PORT=port
Настройка сервера следующая:
  • Максимальный размер загрузки файлов Размер: 1024< /li>
    Максимальное время выполнения: 300
  • Версия PHP: 7,4
  • Версия MariaDB: 10.3.22
Я проверил все журналы (см. ниже) на момент Сервер MySQL выходит из строя/отключается, а в журналах MySQL вообще ничего нет. Никакой ошибки. Я также ничего не вижу в: Сейчас я все еще копаюсь и отлаживаю, но сейчас я в тупике. Я впервые сталкиваюсь с этой ошибкой.
Может ли это быть связано со слишком быстрым обращением к базе данных (чтение/запись)?
Немного информации о том, как работают очереди.
  • У меня есть начальный контроллер, который отправляет задание в очередь.
  • После завершения этого задания оно запускает событие, которое затем запускает процесс последовательного запуска нескольких других прослушивателей/событий, все из которых зависят от завершения предыдущих заданий, прежде чем будут запущены новые события и новые прослушиватели/задания возьмут на себя работу. .
  • Всего транслируется 30 событий.
  • Всего 30 слушателей.
  • Всего существует 5 заданий.
Все они работают последовательно в зависимости от запущенного прослушивателя/задания и события, которое оно запускает.< /p>
Я также отслеживал laravel.log в реальном времени, и когда происходит сбой, вообще ничего не регистрируется. Хотя иногда у меня все же появляется продукция. ОШИБКА: Не удалось подключиться к Pusher. независимо от того, происходит сбой MySQL или нет, поэтому я не думаю, что это имеет какое-либо влияние на эту проблему.
Я даже заметил, что предел скорости API Laravel был превышен, поэтому я резко увеличил его с 60 до 500. Все равно никакой радости.
Наконец, похоже, это не так. не имеет значения, какое событие, задание или прослушиватель выполняется, поскольку ошибка возникает в случайных случаях. Так что не уверен, что это зависит от кода, хотя вполне может быть.
Надеюсь, я предоставил достаточно исходной и подробной информации, чтобы получить некоторую помощь с этим, но если я что-то пропустил, пожалуйста, дайте мне знать, и я добавлю это в вопрос. Спасибо.

Подробнее здесь: https://stackoverflow.com/questions/633 ... et-size-23
Ответить

Быстрый ответ

Изменение регистра текста: 
Смайлики
:) :( :oops: :roll: :wink: :muza: :clever: :sorry: :angel: :read: *x)
Ещё смайлики…
   
К этому ответу прикреплено по крайней мере одно вложение.

Если вы не хотите добавлять вложения, оставьте поля пустыми.

Максимально разрешённый размер вложения: 15 МБ.

Вернуться в «Php»