Мой экземпляр RDS перегружен моим экземпляром EC2, но мой экземпляр EC2 работает без сбоев

Мой экземпляр RDS перегружен моим экземпляром EC2, но мой экземпляр EC2 работает без сбоев

У меня довольно сложная настройка в консоли AWS.

  1. У меня есть экземпляр EC2 в регионе A с установленным LAMP для того, что я буду называть своей CRM.
  2. У меня есть RDS в том же регионе А для моей CRM, которая содержит информацию о моих заказах/клиентах.
  3. У меня есть экземпляр EC2 в регионе B с установленным LAMP, который я назову «Корзина покупок».
  4. У меня есть RDS в том же регионе B, где находится база данных моей корзины покупок.
  5. Несколько незначительных деталей (я думаю): у меня есть два других экземпляра EC2 в регионах C и D с установленным LAMP, которые являются вторичными "корзинами покупок". У них также есть свои собственные экземпляры RDS.

Два основных сервера EC2 соединяются друг с другом через вызовы через CURL. Таким образом, когда заказ поступает на мой сервер EC2 B, на мой сервер EC2 A отправляется вызов curl для вставки заказа, добавления информации о клиенте и т. д. Кроме того, мой сервер A может отправлять вызовы CURL на мой сервер B для обновления цен и т. д. Сервер B может отправлять вызовы CURL на сервер A для получения текущих цен на доставку в город.

Теперь проблема, с которой я столкнулся, заключается в том, что вчера, около 4 утра, мой экземпляр RDS B начал переполняться соединениями и превысил свой лимит в 50 одновременных соединений. Поэтому я обновился с t2.small до t2.medium, и теперь у меня 90 одновременных соединений, но проблема осталась, постоянно достигая лимита в 90 соединений где-то от пары минут до получаса.

Я также обновил свой экземпляр EC2 A, но это опять ничего не меняет. Когда я запускаю следующее на своем экземпляре RDS B, я обычно получаю 6-10 потоков, но иногда это начинает подскакивать, и когда это происходит, то достигает 90 соединений, как правило, в течение одной или двух минут.

ПОКАЗАТЬ статус, КАК «Threads_connected»;

+-------------------+-------+
| Variable_name     | Value |
+-------------------+-------+
| Threads_connected | 6     |
+-------------------+-------+
1 row in set (0.01 sec)

Выполнение следующей команды на моем экземпляре RDS B показывает, что он сбрасывает соединения, когда я достигаю предела в 90 одновременных подключений:

показывать статус как 'Conn%';

+-----------------------------------+--------+
| Variable_name                     | Value  |
+-----------------------------------+--------+
| Connection_errors_accept          | 0      |
| Connection_errors_internal        | 0      |
| Connection_errors_max_connections | 6856   |
| Connection_errors_peer_address    | 0      |
| Connection_errors_select          | 0      |
| Connection_errors_tcpwrap         | 0      |
| Connections                       | 123258 |
+-----------------------------------+--------+
7 rows in set (0.03 sec)

Всякий раз, когда я достигаю 90 подключений на RDS B, мой экземпляр EC2 A замедляется до минимума, а количество подключений на экземпляре RDS A резко возрастает. А мой экземпляр EC2 B отправляет ошибки HTTP 500, поскольку соединение mysqli не удалось из-за слишком большого количества подключений.

Наконец, если я запущу следующее на экземплярах RDS A или RDS B, я увижумногоспящих команд, но почти никогда не было запросов:

ПОКАЗАТЬ ПОЛНЫЙ СПИСОК ПРОЦЕССОВ;

Временное «решение», которое я придумал, — перезапустить службу Apache на экземпляре EC2 A. Как только я это делаю, все процессы на RDS A и B останавливаются в течение нескольких секунд.

Я не понимаю, как это могло внезапно начать происходить, и как даже после увеличения мощности моих экземпляров это может продолжаться. У меня нет идей, куда смотреть дальше. Единственная «проблема», с которой я столкнулся, насколько я могу судить, заключается в том, что мой лимит RDS-подключений исчерпан. Средние показатели нагрузки EC2 очень хорошие (сейчас 0,02). Насколько я помню, за последнюю неделю я не менял ни одного кода.

решение1

Я наконец нашел эту проблему после 8 часов поиска. На одном из моих сайтов был внедрен какой-то вредоносный код фрилансером, который не мог закрыть соединения mysql.

Надеюсь, это поможет кому-то еще. Если вы столкнулись с похожей ситуацией, проверьте сервер на наличие недавно измененных файлов с помощью:

find . -type f -mtime -$n

Где $n— это целое число, представляющее количество дней назад, когда у вас начались проблемы. Запустите эту команду в каталоге, где, как вы ожидаете, могли произойти изменения.

Связанный контент