У меня есть небольшая ферма веб-серверов (HP Proliant и IBM x, с сетевыми адаптерами Broadcom Corporation NetXtreme II BCM5), на которых работает Apache 2.2.15 на CentOS 6, за балансировщиком нагрузки Cisco ACE, обслуживающая веб-портал на основе PHP / JS. Эта ферма ежедневно получает множество запросов (обслуживает целую небольшую страну), пытаясь получить доступ к странице-заставке (чтобы перейти оттуда на страницу индекса)
Я боролся со следующей проблемой:
Я заметил, что иногда запросы к вебу откладывают довольно «долгое» время для ответа (с точки зрения клиента), а иногда они даже не получают ответа (тайм-аут на стороне веб-клиента). В последнем я даже не видел запроса в логах Apache.
Я также заметил, что netstat сообщает об увеличивающемся количестве отправленных сбросов TCP (netstat -st | grep 'resets sent')
Также, dropwatch -l kas показывает, что отбрасывается много пакетов:
Инициализация kallsyms db dropwatch> start Включение мониторинга ... Мониторинг ядра активирован. Выпуск Ctrl-C, чтобы остановить мониторинг 53 капель на tcp_v4_md5_hash_skb + 248 (0xffffffff8149fa08) 26 капель в tcp_rcv_established + 926 (0xffffffff814981b6) 3 капли на tcp_v4_reqsk_destructor + фа (0xffffffff814a104a) 1 капли на netlink_unicast + 251 (0xffffffff81471b11) 56 капель в tcp_v4_md5_hash_skb + 248 ( 0xffffffff8149fa08) 29 капель на tcp_rcv_established + 926 (0xffffffff814981b6) 4 капли на tcp_v4_reqsk_destructor + фа (0xffffffff814a104a) 51 капель в tcp_v4_md5_hash_skb + 248 (0xffffffff8149fa08) 32 капель в tcp_rcv_established + 926 (0xffffffff814981b6) 2 капли на tcp_v4_reqsk_destructor + фа (0xffffffff814a104a) 1 капли на ip_rcv_finish + 199 (0xffffffff8147ea49) 1 капли на tcp_v4_destroy_sock + 115 (0xffffffff814a0cf5) 1 капли на tcp_v4_reqsk_destructor + фа (0xffffffff814a104a) 22 капель на tcp_rcv_established + 926 (0xffffffff814981b6) 36 капель в tcp_v4_md5_hash_skb + 248 (0xffffffff8149fa08) 2 капли на tcp_v4_reqsk_destructor + фа (0xffffffff814a104a ) 49 капель на tcp_v4_md5_hash_skb + 248 (0xffffffff8149fa08) 29 выпадает в tcp_rcv_established + 926 (0xffffffff814981b6) 26 падает в tcp_rcv_established + 926 (0xffffffff814981b6)
Я следую рекомендациям RH (Руководство по настройке производительности сети Red Hat Enterprise Linux), хотя я не видел некоторых из описанных там симптомов на своих серверах. Коротко:
Все вышеперечисленное безуспешно.
Все сетевые карты работают на скорости: 1000 Мбит / с, загрузка ЦП и диска низкая, и ни то, ни другое. netstat ни ethtool показывает ошибки.
Есть идеи, что еще можно сделать?
Сброс TCP - это немедленное закрытие TCP-соединения. Это позволяет освободить ресурсы, выделенные для предыдущего подключения, и сделать их доступными для системы.
причины генерации RST
Подтвердить, сбросить
отправлено в ответ на Syn. Ack Reset, отправляемый в ответ на кадр Syn, отправляется для подтверждения получения кадра, но затем для того, чтобы сообщить клиенту, что сервер не может разрешить соединение на этом порту. Среди причин появления Ack, Reset:
а. Узел, к которому подключается, не прослушивает порт, к которому пытается подключиться клиентский узел.
б. По какой-то причине серверный узел не может установить соединение с этим портом. Например, на сервере закончились ресурсы, и поэтому он не может выделить необходимые ресурсы, чтобы разрешить соединение.
RST
Если соединение находится в каком-либо несинхронизированном состоянии (LISTEN, SYN-SENT, SYN-RECEIVED), и входящий сегмент подтверждает что-то еще не отправленное (сегмент несет недопустимый ACK), отправляется сброс.
Следующий сброс - это сброс TCP, который происходит, когда сетевой кадр отправляется шесть раз (это будет исходный кадр плюс пять повторных передач кадра) без ответа. В результате отправляющий узел сбрасывает соединение.
Как вы и пытались использовать различные параметры настройки ядра, попробуйте использовать параметр tcp cookies ядра
Включить защиту TCP SYN cookie
Edit the file /etc/sysctl.conf, run:
# vi /etc/sysctl.conf
Append the following entry:
net.ipv4.tcp_syncookies = 1
Save and close the file. To reload the change, type:
# sysctl -p
решение может быть дано только путем анализа ваших логов, IPtables тоже может помочь