У нас есть несколько веб-серверов (nginx, php5.6-fpm) на экземплярах ubuntu на AWS. Они работают нормально в течение нескольких месяцев, но в последние несколько дней мы начали получать проблемы, когда после запуска экземпляра все в порядке, но через 12 часов или около того сетевые вызовы начинают отказывать (особенно в этом экземпляр сокета tcp вызывает redis).
Покопавшись с помощью tcpdump, похоже, что поиск по dns выкидывается из-за ошибки контрольной суммы udp:
17: 13: 38.013346 IP (tos 0x0, ttl 64, id 46236, смещение 0, флаги [DF], протокол UDP (17), длина 103) 10.0.0.121.34071> 10.0.0.2.53: [bad udp cksum 0x14df -> 0x3ae1!] 25855+ Тип20736? xxxxxxxx.us-east-1.rds.amazonaws.com. (75)
Если я использую telnet для подключения к серверу Redis из того же экземпляра, тогда все в порядке, это влияет только на fpm. Странно, но это происходит через некоторое время после запуска экземпляра - изначально все запросы проходят нормально. Точно так же перезапуск службы php5.6-fpm, похоже, на время устраняет проблему.
Я почти исчерпал свои знания на этом этапе, так что, надеюсь, кто-нибудь может указать мне правильное направление!
У вас установлено дефектное исправление безопасности - похоже, проблема из USN-3239-2.
Обновление безопасности для GNU libc, которое касалось (среди прочего) ...
неограниченное выделение стека в
getaddrinfo()функция библиотеки GNU C.
.... содержал регрессию - непреднамеренное изменение ABI - которое, похоже, вызвало проблемы, подобные тем, которые вы описываете ... Разрешение DNS в конечном итоге перестанет работать, пока процессы не будут перезапущены.
Первоначальное обновление было выпущено 20 марта 2017 г., а исправление выпущено 21 марта 2017 г. Применение последних исправлений безопасности ОС должно решить проблему, если это так.
Ошибочные контрольные суммы могут быть вызваны выгрузка контрольной суммы.
Я бы проверил, так ли это, что вы можете сделать, запустив:
sudo ethtool --show-offload ethX
Возможно, стоит углубиться в то, что tcpdump может сказать о содержание ваших пакетов, однако - в частности, я бы хотел спросить, не попали ли вы в какое-то ограничение скорости. Вы можете проверить возвратные пакеты для NXDOMAIN или похожие.
Если проблема в этом, то может помочь какой-нибудь преобразователь кеширования.
обновлено чтобы учесть комментарии ниже:
Если перезапуск службы «решает» проблему (спасибо @Лиам Уилтшир для дополнительной информации), то я согласен, что ограничение скорости звучит неправильно (или, по крайней мере, ограничение скорости восходящим потоком не работает).
Я полагаю, что ограничение скорости из-за локальных ресурсов все же может быть возможностью, которую стоит рассмотреть: например, обеспечение отсутствия ограничения на количество записей conntrack или ulimit'ed открытые файлы (т.е. nofiles слишком низкий.
При этом плохой патч безопасности / плохое программное обеспечение кажутся более многообещающими, поэтому я бы определенно дал вес (и дал баллы) @Майкл - sqlbotпредложения.