Периодический сбой HTTP-соединения

У нас есть два сервера, т.е.

host1.example.com
host2.example.com

Один из них действует как основной веб-сервер для двух наших основных веб-сайтов, example.com и example2.com. Другой действует как резервный, на который мы можем переключать трафик, изменяя записи DNS.

example.com и example2.com - это два отдельных сайта, но каждый из них полагается на API другого. Таким образом, регулярно страницы на example.com будут делать запросы curl к конечным точкам формы https://example2.com/api/endpointa , а страницы на example2.com будут делать запросы curl к конечным точкам формы https://example.com/api/endpointb . Это запросы curl, сделанные из внутреннего php-кода.

До недавнего времени все это работало без проблем. Однако в последнее время эти запросы очень редко оказываются невыполненными. Мы получаем сообщения журнала о неудачных межсайтовых запросах API такого рода примерно 5 раз в день, и каждый сайт делает порядка 100 тыс. Таких запросов в день.

При просмотре журналов dom сервера входящие запросы не регистрируются во время сбоев, поэтому они фактически не достигают Apache в качестве входящего запроса. На отправляющей стороне curl запрашивает ошибку в основном мгновенно, без получения кода состояния http. ~ На самом деле похоже, что время ожидания истекло. Обычно они возвращаются почти мгновенно, но теперь у них наступает (долгий) тайм-аут. Но опять же, это происходит очень редко.

Эти сбои происходят только для запросов, отправленных на host1, независимо от того, исходят ли они от самого host1 или от host2. (Я пробовал запустить example.com на host1 и example2.com на host2, и наоборот, а также оба сайта на каждом из двух хостов, чтобы подтвердить это.)

Они не кажутся признаком загрузка сервера, насколько я могу судить. Загрузка процессора и используемой памяти намного ниже, чем сервер успешно справлялся в прошлом. То же самое и с потоками Apache (хотя, если бы это была проблема, я бы ожидал увидеть некоторое указание на то, что запрос был получен в журнале apache dom и журнале ошибок).

Это похоже на проблему с сетью,так как это прерывисто, и запрос, кажется, никогда не достигает сервера. Кроме того, поскольку эти серверы почти идентичны, это происходит только на одном из них. Но часть, которая здесь не имеет смысла, заключается в том, что это происходит, даже когда оба сайта размещены на одном сервере. В этом случае я не уверен, почему запрос вообще будет маршрутизироваться через внешнюю сеть.

Итак, я немного не понимаю, что тестировать. Будет ли внешняя сеть играть роль при выполнении запроса curl на сайт, размещенный на том же сервере, с использованием его внешнего домена? то есть, может быть, коммутатор в центре обработки данных сбрасывает пакеты или что-то в этом роде? Если нет, то что еще я могу проверить?

Изменить: еще один признак того, что эти сбои не совпадают с загруженным периодом дня, когда трафик в два раза выше среднего и намного выше ночного уровня. Кажется, что они случаются так же часто, когда трафик низкий, что снова наводит на мысль, что это что-то вне сервера. Просто пытаюсь выяснить, что за пределами сервера может вызвать отбрасывание запроса curl от host1.example.com к странице на example.com, размещенной на том же сервере.

0
задан 3 December 2018 в 07:35
1 ответ

Оказывается, проблема заключалась в том, что мы несколько раз в день загружали большие файлы каналов. и импортируйте их в MariaDB. Импорт файлов не вызывал проблем, поскольку они естественным образом блокировались Интернетом. Однако у нас также настроена репликация между нашими серверами, и когда каждая из этих массивных таблиц была импортирована, она помещала большой объем данных в двоичный журнал, который затем передавался на другие серверы. Эти всплески сетевого трафика, которые были очень большими, поскольку серверы находятся рядом друг с другом и не имеют внешнего узкого места для замедления передачи, совпадают с наблюдаемыми нами обрываемыми соединениями.

При необходимости мы можем удалить эту базу данных из репликации и распространить импортированные файлы другим способом. Однако сначала я собираюсь изучить, можем ли мы ограничить или отменить приоритет трафика репликации базы данных, чтобы он не превышал максимальное количество соединений.

Редактировать: Похоже, мы можем использовать эту новую настройку MariaDB, чтобы ограничить чтение двоичного журнала скорость: https://mariadb.com/kb/en/library/restricting-speed-of-reading-binlog-from-master-by-a-slave/

0
ответ дан 5 December 2019 в 05:01

Теги

Похожие вопросы