У нас есть производственная проблема только с одним из наших серверов, и мы связали низкую производительность с обилием сокетов в TIME_WAIT штат. Не вдавая этот вопрос в обширную предысторию, мы в основном знаем, что каждый раз, когда сервер работает медленно, около 80% сокетов сервера находятся в этом TIME_WAIT состояние, которое, конечно, мы видим, запустив netstat). В частности, потому что TIME_WAIT время истекает и исчезает, когда наш сервер работает медленно, мы видим эти TIME_WAITs возникают очень часто (примерно каждые 5-10 минут).
Я немного покопался и увидел, что TIME_WAITs возникают, когда сервер закрывает активное соединение, но сохраняет его на случай прохождения задержанных пакетов. В конце концов TIME_WAIT время вышло.
В любом случае, чтобы понять, почему отдельная розетка попала в TIME_WAIT состояние для начала? Это CentOS 5 - регистрирует ли Linux эту информацию? var/logs где угодно, или есть ли способ выполнить tcpdump и найти конкретный шаблон, который приводит к TIME_WAIT? Заранее спасибо.
Он устанавливает свойства для сокета, затем они разрешаются / применяются ядром.
http://pubs.opengroup.org/onlinepubs/009695399/functions/setsockopt.html
Короткий ответ - да и да. Поэтому, если вы устанавливаете очень медленное соединение с одиноким удаленным офисом по медленному DSL, может возникнуть проблема с «запоздалыми» пакетами. Но если это соединения в вашей локальной сети, вероятно, нет.
Одно из ваших приложений должно открывать сокеты оптом, а затем закрывать их. lsof покажет, какой pid имеет открытый сокет. Оттуда вы можете получить пользователя и то, что запускается. Это может быть что-то простое, например, сценарий оболочки bash, злоупотребляющий netcat.
Итог: это либо злоупотребление сетевыми средствами, либо проблема кода. И у вас есть сетевое приложение - оно съедает вашу систему. Мое определение сетевого приложения означает «использование сокетов TCP / UDP». Не обязательно веб-сервер.
Короткий ответ - это из-за приложения. Приложение на короткое время создает сокеты, закрывает их, после чего ему немедленно требуется открыть другой сокет. Медлительность связана с тем, что у процесса (ов) не хватает сокетов для использования.
При создании сокета есть варианты - SO_REUSEADDR abnd SO_REUSEPORT. У них есть несколько схожие функции, но я подозреваю, что в Centos 5 SO_REUSEPORT недоступен. В любом случае необязательная настройка вызова сокета позволяет немедленно повторно использовать порт.
Итак, обычно используемое исправление - перекодирование. Вероятно, это сетевое приложение, которое подключается на несколько секунд, а затем завершает сеанс.