Стресс-тестирование для tcp_mem
Linux имеет параметр tcp_mem для объема памяти, который он будет выделять для TCP-соединений для всех запущенных приложений. Согласно официальной документации :
tcp_mem - вектор из 3 INTEGER: min, pressure, max min: ниже этого количества страниц TCP не заботится о своем аппетите памяти.
давление: когда объем памяти, выделенной TCP, превышает это число страниц, TCP снижает потребление памяти и входит в режим давления памяти , который выходит, когда потребление памяти падает ниже {{1 }} "мин".
max: количество страниц, разрешенных для постановки в очередь всеми сокетами TCP.
Значения по умолчанию рассчитываются во время загрузки из объема доступной памяти.
Мы видим, что одно приложение нарушает этот порог в Prod, и его журнал dmesg содержит строку вроде: TCP: недостаточно памяти - рассмотрите возможность настройки tcp_mem .
По какой-то причине я не могу повторно запустить то же приложение локально. Итак, я хотел бы написать еще одно простое приложение, которое воспроизводит эту ошибку локально.
Пока что я пробовал:
- Большие загрузки по сети (HTTP GET для предварительно подписанных URL-адресов S3 с использованием NodeJS и S3-Get-Objects с использованием Python Boto3 SDK).
- Библиотека сокетов Python для передачи клиент-сервер (при закрытии / не закрытии клиентских сокетов) по TCP.
Во всех случаях я вижу, что могу достичь верхнего предела tcp_mem , но не нарушить его. В то время как я вижу, что приложение Prod значительно превышает лимит (например, 6000 против 4400).
Итак, вопрос: что я могу попытаться воспроизвести, нарушив ограничение tcp_mem локально?
Я думаю, что превышение лимита tcp_mem является следствием другой проблемы. Высокое потребление памяти для уровня TCP может быть вызвано потерей сегментов TCP. Пока не будет выполнена повторная передача потерянного сегмента, в стеке TCP будут храниться другие полученные данные. Только после того, как все недостающие данные будут получены, данные могут быть обработаны вашим приложением.
Итак, если вы хотите эмулировать проблему tcp_mem , вы можете отбросить случайные сегменты tcp-соединения. Но я не думаю, что это может вам помочь. Лучше постарайтесь устранить источник вашей проблемы. Проверьте вывод nstat , особенно потерянные сегменты tcp и счетчики повторной передачи tcp. Захватите трафик и проанализируйте его в wirehark.