У меня очень загруженные веб-серверы, и я хотел провести некоторый анализ, чтобы увидеть, какой трафик присутствует. А именно, общее количество всех подключений, количество времени ожидания, установленные подключения, подключения UDP и TCP.
Во-первых, я сделал график простым - отображая только общее количество подключений, читая /proc/sys/net/netfilter/nf_conntrack_count с участием:
$ cat /proc/sys/net/netfilter/nf_conntrack_count
1994
Все было красиво представлено на графике, поэтому я ввел в него больше деталей. Сейчас обрабатывается /proc/net/nf_conntrack с аналогичными командами и помещением в соответствующий мониторинг:
$ grep -c tcp /proc/net/nf_conntrack
1273
$ grep -c udp /proc/net/nf_conntrack
49
Сделал этот анализ nf_conntrack для запуска каждую минуту. Изначально все отображалось правильно, поэтому я оставил это на день.
На следующий день я заметил огромные падения и повторные отказы в общем количестве подключений (/proc/sys/net/netfilter/nf_conntrack_count), что не было нормальным для веб-сервера, происходившее каждые пару минут. После долгих испытаний и устранения неполадок я, наконец, определил причину загадки.
Я поставил терминал watch -n0 "cat /proc/sys/net/netfilter/nf_conntrack_count" (чтобы проверить количество подключений почти в реальном времени), а во второй я сделал только cat /proc/net/nf_conntrack, и как только был нажат ввод nf_conntrack_count сильно упал с 1993 по 1411 год, а затем через 2-3 секунды восстановился до «нормального» значения. Пробовал с cp, grep, conntrack -L -p tcpи т.д., и каждый раз, когда я запускал команду, было это падение.
По сути, каждый раз, когда читали /proc/net/nf_conntrack- огромный, временный, заглянуть /proc/sys/net/netfilter/nf_conntrack_countпроизошел, и мониторинг иногда выбирает низкие значения и отображает их на графике.
Кроме того, я заметил огромную разницу в результатах cat nf_conntrack и conntrack -L. Также количество строк в nf_conntrack отличается от nf_conntrack_count. Ядро v4.19.5. Все так заметно с этими двумя командами, развернутыми с интервалом в три секунды:
[07:30:14] root@web1(~)$ wc -l /proc/net/nf_conntrack; \
cat /proc/sys/net/netfilter/nf_conntrack_count
1236 /proc/net/nf_conntrack
1575
[07:30:18] root@web1(~)$ cat /proc/sys/net/netfilter/nf_conntrack_count;\
wc -l /proc/net/nf_conntrack
2009
1191 /proc/net/nf_conntrack
У меня вопрос: что именно здесь происходит, почему это происходит (падение), почему есть разница между файлами в списке и как предотвратить это падение?
В целом я думаю, что это зависит от версии вашего ядра и количества отслеживаемых соединений. IIRC, ядру необходимо получить некоторые блокировки, чтобы сгенерировать и / proc / net / nf_conntrack, что, вероятно, является причиной падения.
Лучше использовать conntrack утилита, которая получает информацию с помощью netlink и не страдает от того же набора проблем.
Я попытался провести такое же тестирование с grep -c tcp /proc/net/nf_conntrack и watch -n0 "cat /proc/sys/net/netfilter/nf_conntrack_count" на одном нашем производственном сервере под управлением CentOS 7.4.1708 с ядром 3.10.0-693.21.1.el7.x86_64, и я не могу подтвердить, что существует та же проблема, с которой вы столкнулись.
Попробуйте прислать хотя бы свою версию ядра, может быть, кто-нибудь, у кого запущен сервер с той же версией, тоже сможет ее протестировать.
Одна из идей, что может происходить, заключается в том, что при использовании grep вы достигаете некоторых ограничений системной памяти или процессора, и это влияет на nf_conntrack. Вы можете попробовать запустить т.е. nice -n19 grep -c tcp /proc/net/nf_conntrack и используйте ulimits или cgroups для работы с RAM. Другая идея - попробовать Google для версии ядра или версии nf_conntrack в сочетании с вашим определением проблемы. Это может быть какая-то ошибка, но маловероятная.