我有一個(gè) Laravel Spark 項(xiàng)目，它使用 Horizon 來(lái)管理 Redis 的作業(yè)隊(duì)列。在本地（在我的 Homestead 盒子、Mac OS 上）一切都按預(yù)期工作，但在我們新的 Digital Ocean（Forge 配置）Droplet（內(nèi)存優(yōu)化的 256GB、32vCPU、10TB 和 1x 800GB VPS）上，我不斷收到錯(cuò)誤:PDOException: Packets out of order. Expected 0 received 1. Packet size=23或者該錯(cuò)誤的某些變體，其中數(shù)據(jù)包大小信息可能不同。經(jīng)過(guò)數(shù)小時(shí)/數(shù)天的調(diào)試和研究，我在 StackOverflow 和其他地方看到了許多帖子，這些帖子似乎表明可以通過(guò)執(zhí)行以下列出的許多操作來(lái)解決此問(wèn)題：在我的 database.php 配置中設(shè)置PDO::ATTR_EMULATE_PREPARES為 true。這對(duì)問(wèn)題絕對(duì)沒(méi)有影響，實(shí)際上引入了另一個(gè)問(wèn)題，即整數(shù)被轉(zhuǎn)換為字符串。設(shè)置DB_HOST為127.0.0.1而不是localhost，以便它使用 TCP 而不是 UNIX 套接字。同樣，這沒(méi)有任何效果。DB_SOCKET通過(guò)登錄 MySQL (MariaDB) 并運(yùn)行將套接字路徑列出為 來(lái)設(shè)置為 MySQL 中show variables like '%socket%';列出的套接字路徑/run/mysqld/mysqld.sock。我也離開(kāi)DB_HOST設(shè)置為localhost。這也沒(méi)有效果。我確實(shí)注意到的一件事是，變量pdo_mysql.default_socket設(shè)置為/var/run/mysqld/mysqld.sock，我不確定這是否是問(wèn)題的一部分？我已將 MySQL 配置設(shè)置大幅增加到/etc/mysql/mariadb.conf.d/50-server.cnf以下內(nèi)容：key_buffer_size = 2048Mmax_allowed_packet = 2048Mmax_connections = 1000thread_concurrency = 100query_cache_size = 256M我必須承認(rèn)，改變這些設(shè)置是最后的手段/抓住稻草類(lèi)型的場(chǎng)景。然而，這確實(shí)在一定程度上緩解了這個(gè)問(wèn)題，但并沒(méi)有完全解決它，因?yàn)?MySQL 在 99% 的情況下仍然會(huì)失敗，盡管是在后期。就隊(duì)列而言，我總共分為1,136 workers6 個(gè)主管/隊(duì)列，并且全部通過(guò) Laravel Horizon 處理，它作為守護(hù)進(jìn)程運(yùn)行。我還使用 Laravel Websockets PHP 包進(jìn)行廣播，同樣，它也作為守護(hù)進(jìn)程運(yùn)行。我當(dāng)前的環(huán)境配置如下（敏感信息省略）。服務(wù)器設(shè)置如下：最大文件上傳大小：1024最大執(zhí)行時(shí)間：300PHP 版本：7.4MariaDB 版本：10.3.22我檢查了 MySQL 服務(wù)器崩潰/消失時(shí)的所有日志（見(jiàn)下文），MySQL 日志中根本沒(méi)有任何內(nèi)容。沒(méi)有任何錯(cuò)誤。我也沒(méi)有看到任何內(nèi)容：/var/log/nginx/error.log/var/log/nginx/access.log/var/log/php7.4-fpm.log我目前仍在挖掘和調(diào)試，但現(xiàn)在，我被難住了。這是我第一次遇到這個(gè)錯(cuò)誤。這可能是因?yàn)樵L問(wèn)數(shù)據(jù)庫(kù)（讀/寫(xiě)）太快嗎？有關(guān)隊(duì)列如何工作的一些信息。我有一個(gè)初始控制器，它將作業(yè)分派到隊(duì)列。一旦該作業(yè)完成，它就會(huì)觸發(fā)一個(gè)事件，然后啟動(dòng)按順序運(yùn)行其他幾個(gè)偵聽(tīng)器/事件的過(guò)程，所有這些都取決于在觸發(fā)新事件和新偵聽(tīng)器/作業(yè)占用工作之前完成的先前作業(yè)?？偣膊コ隽?30 個(gè)事件?？偣灿?30 名聽(tīng)眾。總共有5個(gè)職位。這些都根據(jù)運(yùn)行的偵聽(tīng)器/作業(yè)及其觸發(fā)的事件按順序工作。我還監(jiān)控了laravel.log現(xiàn)場(chǎng)情況，當(dāng)崩潰發(fā)生時(shí)，根本沒(méi)有記錄任何內(nèi)容。雖然，我偶爾會(huì)得到production.ERROR: Failed to connect to Pusher.MySQL是否崩潰的信息，所以我認(rèn)為這與這個(gè)問(wèn)題沒(méi)有任何關(guān)系。我什至注意到 Laravel API 速率限制已達(dá)到，因此我確保將其從 60 大幅增加到 500。仍然沒(méi)有高興。最后，運(yùn)行哪個(gè)事件、作業(yè)或監(jiān)聽(tīng)器似乎并不重要，因?yàn)殄e(cuò)誤是隨機(jī)發(fā)生的。因此，不確定它是特定于代碼的，但很可能是。希望我已經(jīng)提供了足夠的背景和詳細(xì)信息來(lái)獲得一些幫助，但如果我錯(cuò)過(guò)了任何內(nèi)容，請(qǐng)告訴我，我會(huì)將其添加到問(wèn)題中。謝謝。
4 回答
慕神8447489
TA貢獻(xiàn)1780條經(jīng)驗(yàn) 獲得超1個(gè)贊
對(duì)我來(lái)說(shuō)，解決這個(gè)問(wèn)題的是增加最大數(shù)據(jù)包大小。
在 中my.cnf，我添加了：
max_allowed_packet=200M
然后service mysql stop，，，service mysql start它成功了:)
慕妹3242003
TA貢獻(xiàn)1824條經(jīng)驗(yàn) 獲得超6個(gè)贊
我們收到了類(lèi)似的關(guān)于數(shù)據(jù)包亂序的 PHP 警告。為我們解決這個(gè)問(wèn)題的是增加MySQL my.cnf 中的max_connections 。您當(dāng)前的 max_connections 可能是 1024。我們將其增加到 4096，警告消失了。在 MySQL 中，您可以使用以下命令查看當(dāng)前的 max_connections：
SHOW VARIABLES LIKE "%max_connections%"; or mysqladmin variables | grep max_connections
楊__羊羊
TA貢獻(xiàn)1943條經(jīng)驗(yàn) 獲得超7個(gè)贊
我遇到了一個(gè)可重現(xiàn)的類(lèi)似問(wèn)題，這是一個(gè)編程錯(cuò)誤：
我使用的是無(wú)緩沖的數(shù)據(jù)庫(kù)游標(biāo)，并且在觸發(fā)其他數(shù)據(jù)庫(kù)操作之前沒(méi)有關(guān)閉游標(biāo)。拋出的確切錯(cuò)誤是Packets out of order. Expected 1 received 2.
慕標(biāo)5832272
TA貢獻(xiàn)1966條經(jīng)驗(yàn) 獲得超4個(gè)贊
首先要檢查的是wait_timeoutMySQL 服務(wù)器的時(shí)間，與應(yīng)用程序在查詢之間花費(fèi)的時(shí)間有關(guān)。通過(guò)在 SQL 查詢之間休眠時(shí)間超過(guò)wait_timeout秒，我能夠一致地重新創(chuàng)建此錯(cuò)誤。
如果您的應(yīng)用程序執(zhí)行查詢，然后在一段時(shí)間內(nèi)執(zhí)行其他操作，并且花費(fèi)的時(shí)間超過(guò)該時(shí)間，則 MySQL 服務(wù)器將終止連接，但您的 PHP 代碼可能不知道服務(wù)器已斷開(kāi)連接。如果 PHP 應(yīng)用程序隨后嘗試使用關(guān)閉的連接發(fā)出另一個(gè)查詢，它將生成此錯(cuò)誤（在我的測(cè)試中，與Expected 0 received 1.
您可以通過(guò)以下方式解決此問(wèn)題：
wait_timeout在服務(wù)器上全局?jǐn)U展或使用命令在每個(gè)會(huì)話的基礎(chǔ)上擴(kuò)展SET session wait_timeout=<new_value>;捕獲錯(cuò)誤并重試一次
wait_timeout當(dāng)您知道查詢之間已經(jīng)過(guò)去了超過(guò)幾秒時(shí)，搶先重新連接到服務(wù)器。
此錯(cuò)誤也可能由于其他問(wèn)題而發(fā)生。我會(huì)檢查您是否使用持久連接，而不是一遍又一遍地連接到服務(wù)器。有時(shí)，連接過(guò)程，尤其是許多并發(fā)工作人員的連接過(guò)程，會(huì)導(dǎo)致大量網(wǎng)絡(luò)開(kāi)銷(xiāo)，從而可能導(dǎo)致此類(lèi)問(wèn)題。
另外，有時(shí)，在生產(chǎn)、高交易量的服務(wù)器中，會(huì)發(fā)生奇怪的網(wǎng)絡(luò)問(wèn)題，并且這種情況可能只是偶爾發(fā)生，甚至在您的情況下似乎是通過(guò)環(huán)回接口發(fā)生的。
無(wú)論如何，最好編寫(xiě)您的代碼，以便它可以優(yōu)雅地處理錯(cuò)誤并重試。通常，您可以將 SQL 查詢包裝在 a 中try..catch，以便在發(fā)生此錯(cuò)誤時(shí)捕獲它并重試。
- 4 回答
- 0 關(guān)注
- 332 瀏覽
添加回答
舉報(bào)
0/150
提交
取消