Назад | Перейти на главную страницу

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

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

  1. У меня есть экземпляр EC2 в регионе A с установленной LAMP для того, что я назову своей CRM.
  2. У меня есть RDS в том же регионе A для моей 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). За последнюю неделю я не изменил ни одного кода, который мог бы придумать.

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

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

find . -type f -mtime -$n

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