Не мога да намеря цитат в документацията, но моят опит подсказва, че мрежовата инфраструктура на EC2 като цяло (която ще включва RDS и вероятно всяка друга услуга на AWS, която работи на виртуални машини, които се предоставят за всеки клиент, ако не и всички AWS и със сигурност не изглежда да е ограничен стриктно до „екземпляри на EC2“) прилага проверка на пакети със състояние и ще „забрави“, че TCP връзката е валидна след няколко минути абсолютна бездействие... причинявайки поведението, което описвате.
Машините от двата края на връзката може да са убедени, че връзката все още е налице, но мрежата няма да позволи на трафика да преминава между тях, тъй като TCP сесиите в SPI среда не се откриват, те са създадени и могат само се създава, когато мрежата види връзката в самото начало (SYN, SYN/ACK, ACK ). Първоначално се сблъсках с този проблем с MySQL сървъри в EC2 (не RDS), но бих бил много изненадан, ако основната причина не е същата.
Има два възможни подхода за заобикаляне на това.
Ако вашата PHP машина е Linux, конфигурирайте ядрото да поддържа връзките живи на слой 4. Тази промяна ще бъде невидима за вас в смисъл, че тези поддържащи активности няма да променят стойността в Time колона в SHOW PROCESSLIST за връзки в Sleep защото няма да нулира времето, през което връзката е била неактивна на слой 7 ... но трябва да избягва изчакванията от инфраструктурата на AWS, ако библиотеките, управляващи MySQL връзките, задават правилно опциите на сокета, за да се възползват от него.
http://tldp.org/HOWTO/TCP-Keepalive-HOWTO/usingkeepalive .html обяснява как да настроите това на живо и как да го направите постоянен при рестартиране.
Ако не успеете, другата възможност е да принудите MySQL да затвори връзката по-рано от изтичането на времето за изчакване на мрежата така че PHP машината веднага ще разпознае, че се опитва да говори в затворен сокет. Може да звучи противоположно интуитивно да се съкращава времето за изчакване, вместо да се удължава, но съкращаването на времето за изчакване би трябвало да доведе до неуспех на вашия пинг тест много бързо, ако сесията е била неактивна твърде дълго, което също (по същество) "решава" проблема, като се приеме, че е здрав в клиентската библиотека на PHP. След като приложението ви е по-заето, връзките вероятно рядко ще бъдат неактивни достатъчно дълго, за да достигнат времето за изчакване.
MySQL Server има две различни настройки за изчакване на неактивност: wait_timeout
(за неинтерактивни сесии, т.е. връзки от код, като PHP) и interactive_timeout
(от браузърите със заявки и клиента от командния ред), но сървърът знае само разликата, защото клиентската библиотека трябва да уведоми сървъра кой тип връзка установява. Ако приемем, че вашата клиентска библиотека използва правилната настройка, след това wait_timeout е този, който търсите. Задаването на това на стойност под 900 би трябвало да реши проблема, ако промяната на настройките за поддържане на TCP в ядрото на Linux не го прави. Имайте предвид обаче, че след като направите промяната, ще бъдат засегнати само бъдещи връзки - връзките, които вече са установени, когато е направена промяната, ще продължат да работят с текущата стойност, която по подразбиране е 8 часа (28800 секунди). Те могат да се конфигурират в групата параметри на RDS за вашия екземпляр.
Има намеци за подобно поведение в документите на AWS тук , заедно с настройките на системния регистър на Windows, които трябва да бъдат коригирани за промяна на TCP keepalives, ако използвате PHP сървъра на Windows, вместо Linux, както предположих по-горе... въпреки че статията е конкретно за Redshift и връзки, външни за EC2 изглежда все още потвърждава основния проблем, както беше обсъдено по-горе.
