почему соединений много 8000 TIME_WAIT и больше по порту 3306 а самих процессов в mysql несколько всего

Большое количество соединений в состоянии

TIME_WAIT при малом числе активных процессов в MySQL — это классическая ситуация, связанная с тем, как работает протокол TCP.

Вот основные причины:

Короткие соединения: Ваше приложение открывает соединение, выполняет быстрый запрос и тут же его закрывает. В MySQL процесс (thread) исчезает сразу, но на уровне операционной системы соединение переходит в статус TIME_WAIT.
Механизм TCP: После закрытия сессии ОС обязана удерживать соединение в TIME_WAIT (обычно 60–120 секунд), чтобы убедиться, что все «заблудившиеся» пакеты данных дошли и не перемешались с новым соединением на тех же портах.
Отсутствие Connection Pooling: Если приложение не использует «пул соединений», оно создает новый TCP-хендшейк для каждого чиха. При высоком трафике эти «хвосты» копятся быстрее, чем ОС успевает их вычищать.

Что с этим делать:

На стороне приложения: Включите Persistent Connections (постоянные соединения) или настройте Connection Pool. Это позволит переиспользовать уже открытые каналы.
На стороне ОС (Linux): Можно ускорить переиспользование портов, подправив параметры ядра в /etc/sysctl.conf:
- net.ipv4.tcp_tw_reuse = 1 — разрешает использовать TIME_WAIT сокеты повторно.
Проверьте код: Убедитесь, что вы не закрываете соединение с базой внутри циклов.

Хотите посмотреть настройки sysctl для оптимизации или подсказать, на каком языке программирования написано ваше приложение?

Копировать

Создание общедоступной ссылки…

Хороший ответ

Плохой ответ

Показать все

windows server и mysql

Ситуация, когда в Windows Server висит 8000 и более соединений в

TIME_WAIT при малом числе процессов MySQL, объясняется тем, что ОС по умолчанию держит закрытые порты «занятыми» очень долго (до 4 минут), в то время как MySQL завершает поток (thread) мгновенно.

В Windows Server это лечится через реестр или командную строку netsh.

1. Ускорение освобождения портов (TcpTimedWaitDelay)

По умолчанию Windows держит порт в состоянии TIME_WAIT 240 секунд (4 минуты). Это можно сократить до 30 секунд.

Путь в реестре: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Параметр (DWORD): TcpTimedWaitDelay
Значение: 30 (десятичное)
Требуется перезагрузка для вступления в силу.

2. Увеличение диапазона доступных портов (MaxUserPort)

Если соединений слишком много, Windows может просто исчерпать свободные порты для новых подключений.

Через реестр:
- В том же разделе создайте/измените параметр MaxUserPort (DWORD).
- Установите значение до 65534 (десятичное).
Через командную строку (без перезагрузки):
cmd
netsh int ipv4 set dynamicport tcp start=1025 num=60000
Используйте код с осторожностью.
null
Скопировано в буфер обмена
Это расширит диапазон динамических портов, позволяя ОС «переварить» большее количество одновременных TIME_WAIT соединений.

3. Проверка настроек MySQL (wait_timeout)

Если соединения копятся из-за «зависших» сессий, которые приложение забыло закрыть, можно заставить MySQL закрывать их быстрее:

В файле my.ini (обычно в C:\ProgramData\MySQL\...) установите:
wait_timeout = 300 (5 минут вместо стандартных 8 часов).

Почему это происходит именно на Windows?
Windows по умолчанию настроена на консервативную работу с сетью. Приложение на PHP/Python/.NET открывает TCP-порт к MySQL (порт 3306), делает запрос и закрывает сокет. Для MySQL работа окончена, процесс убит. Но стек TCP/IP в Windows обязан ждать 2MSL (максимальное время жизни сегмента), чтобы не возникло путаницы с данными, если новый клиент сразу займет тот же порт.

Вам помочь составить PowerShell-скрипт для автоматической настройки этих параметров?

Копировать

Создание общедоступной ссылки…

Хороший ответ

Плохой ответ

Chapter 3 Connection to MySQL Server Failing on Windows
Contact MySQL | * Installing MySQL on Microsoft Windows. MySQL Installation Layout on Microsoft Windows. Choosing an Installation ...
MySQL :: Developer Zone
Windows - Diffusion Documentation Hub - DiffusionData
Setting TCP timed wait. This parameter determines the length of time that a connection stays in the TIME_WAIT state when it is clo...
DiffusionData
Windows Excessive Time_Wait causes Internet access failure
* NeuHub. Intelligent Design. * Cloud Essentials. Elastic Compute. * Enterprise Applications. Video Service. * Developer Services.
京东云

Показать все

если поставить 30 то не закроет ли раньше если соединение еще выполняется ?

Нет,

соединение не разорвется, если оно еще активно.

Параметр TcpTimedWaitDelay начинает отсчет времени только после того, как соединение уже было закрыто обеими сторонами (приложением и базой данных).

Вот как это работает:

Active: Выполняется запрос (процесс виден в MySQL).
Closing: Приложение или сервер говорит «все, закончили» (процесс в MySQL исчезает).
TIME_WAIT: Соединение фактически мертво, но ОС «бронирует» этот номер порта на всякий случай (защита от дубликатов пакетов из старой сессии).

Установка значения в 30 секунд сокращает именно этот «период ожидания призраков», а не время жизни живого запроса.

На что это может повлиять (редкие случаи):
Единственный риск — если сеть крайне медленная или нестабильная, и какой-то пакет данных «заблудился» в интернете/маршрутизаторах более чем на 30 секунд. Но в рамках локальной сети или одного сервера Windows это абсолютно безопасно.

Что действительно ограничивает активные соединения:
За время жизни живого соединения отвечает параметр в MySQL:

wait_timeout (для спящих соединений);
max_execution_time (для слишком долгих запросов).

Хотите проверить текущие значения тайм-аутов в самом MySQL, чтобы понять, почему их так много копится?

Копировать

Создание общедоступной ссылки…

Хороший ответ

Плохой ответ

Показать все

А из за чего TIME_WAIT изначально такой большой и какие варианты сбоев если 39 секунд поставить

Значение по умолчанию в

240 секунд (4 минуты) пришло из стандартов интернета 80-х годов (RFC 793). Тогда узлы сети были медленными, а пакеты могли «гулять» по планете минутами.

Почему 240 секунд — это «заводская» настройка:

Это защита от ситуации, когда старый пакет данных (который задержался где-то в маршрутизаторе) внезапно доходит до сервера уже после того, как старое соединение закрылось, а новое (с тем же номером порта) открылось. Если бы защиты не было, старый пакет «вклинился» бы в новые данные и вызвал ошибку или порчу информации.

Что будет, если поставить 30-60 секунд (риски):

На практике в 2024 году на Windows Server, работающем с MySQL в локальной сети или одном дата-центре, сбоев практически не бывает. Но теоретически возможны:

Нарушение целостности (крайне редко): Если сеть катастрофически тормозит, старый дубликат пакета может попасть в новую сессию. Современные протоколы (Sequence Numbers в TCP) это отсекают, так что приложение просто получит ошибку и переподключится.
Ошибки подключения (Address already in use): Если вы ставите слишком маленькое время (например, 5-10 секунд) и при этом у вас бешеный поток запросов, порты могут не успевать очищаться. Но 30 секунд — это «золотой стандарт» для высоконагруженных систем.
Ложные срабатывания фаерволов: Некоторые старые или параноидальные железные фаерволы могут решить, что вы пытаетесь манипулировать сессиями, если видите быстрое переиспользование портов.

Итог:

Если ваш сервер и клиент (приложение) находятся в одной сети, 30 секунд — это безопасно. Проблемы начинаются только при плохом Wi-Fi или передаче данных через спутник.

Самый правильный путь при 8000+ соединениях — это не только снижать таймер, но и проверить, почему приложение открывает/закрывает их так часто.

Подсказать, как проверить, какое именно приложение (процесс) «мусорит» этими соединениями в Windows?

Копировать

Создание общедоступной ссылки…

Хороший ответ

Плохой ответ

Показать все

как проверить сколько сейчас TcpTimedWaitDelay

В Windows этот параметр по умолчанию

отсутствует в реестре. Это означает, что система использует стандартное значение — 240 секунд (4 минуты).

Проверить его наличие и текущее состояние можно тремя способами:

1. Самый быстрый (PowerShell)

Запустите PowerShell от имени администратора и выполните команду:

powershell

Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters" -Name "TcpTimedWaitDelay" -ErrorAction SilentlyContinue

Используйте код с осторожностью.

Если пусто (ошибка или пустая строка) — значит, параметр не задан и действует стандарт (240 сек).
Если число есть — это ваше текущее значение в секундах.

2. Через Редактор реестра (Визуально)

Нажмите Win + R, введите regedit.
Перейдите по пути:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Ищите в списке справа TcpTimedWaitDelay.
- Если его нет — у вас 240 секунд.

3. Как проверить "эффект" (через netstat)

Если вы хотите увидеть, сколько времени реально висят соединения, выполните в командной строке:

cmd

netstat -no | findstr TIME_WAIT

Используйте код с осторожностью.

Засеките время для одного конкретного порта (последняя колонка — PID, но у TIME_WAIT его часто нет, смотрите на локальный адрес с портом). Если через минуту он всё ещё в списке — значит, лимит больше 60 секунд.

Как установить 30 секунд (если параметра нет):
Если вы решили его добавить, выполните эту команду в PowerShell (от админа):

powershell

New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters" -Name "TcpTimedWaitDelay" -Value 30 -PropertyType DWORD -Force

Используйте код с осторожностью.

После этого нужно перезагрузить сервер, чтобы Windows начала применять новый таймер.

Хотите, я помогу составить команду для проверки общего количества всех TIME_WAIT соединений прямо сейчас, чтобы сравнить "до" и "после"?

Копировать

Создание общедоступной ссылки…

Хороший ответ

Плохой ответ

Показать все

TCP 192.168.0.10:53553 192.168.0.9:3306 TIME_WAIT 0 TCP 192.168.0.10:53554 192.168.0.9:3306 TIME_WAIT 0 TCP 192.168.0.10:53555 192.168.0.9:3306 TIME_WAIT 0 TCP 192.168.0.10:53556 192.168.0.9:3306 TIME_WAIT 0 TCP 192.168.0.10:53558 192.168.0.9:3306 TIME_WAIT 0 TCP 192.168.0.10:53559 192.168.0.9:3306 TIME_WAIT 0 TCP 192.168.0.10:53560 192.168.0.9:3306 TIME_WAIT 0 TCP 192.168.0.10:53561 192.168.0.9:3306 TIME_WAIT 0 TCP 192.168.0.10:53562 192.168.0.9:3306 TIME_WAIT 0 TCP 192.168.0.10:53563 192.168.0.9:3306 TIME_WAIT 0 TCP 192.168.0.10:53565 192.168.0.9:3306 TIME_WAIT 0 TCP 192.168.0.10:53567 192.168.0.9:3306 TIME_WAIT 0 TCP 192.168.0.10:53568 192.168.0.9:3306 TIME_WAIT 0 TCP 192.168.0.10:53569 192.168.0.9:3306 TIME_WAIT 0 TCP 192.168.0.10:53570 192.168.0.9:3306 TIME_WAIT 0 TCP 192.168.0.10:53571 192.168.0.9:3306 TIME_WAIT 0

Судя по логу, у вас

классическая проблема отсутствия пула соединений (Connection Pooling).

Ваше приложение на 192.168.0.10 открывает новый порт (53553, 53554, 53555...) для каждого мелкого чиха к базе на 192.168.0.9. Поскольку порты идут подряд, это происходит очень быстро — буквально десятки или сотни раз в секунду.

Что это значит для вас:

Нагрузка на CPU: Windows тратит ресурсы на постоянное создание и закрытие TCP-сокетов.
Риск отказа: Если порты закончатся (дойдут до 65535), приложение получит ошибку «Не удалось открыть сокет» (Socket Error), хотя база MySQL будет абсолютно свободна.
Лишний трафик: Каждое соединение — это «тройное рукопожатие» TCP (SYN, SYN-ACK, ACK), что добавляет задержку к каждому запросу.

Как это исправить правильно:
Изменение TcpTimedWaitDelay до 30 секунд поможет серверу быстрее «выбрасывать мусор», но не решит причину.

Чтобы реально убрать TIME_WAIT, нужно:

В коде приложения включить Persistent Connections (постоянные соединения).
Вместо mysql_connect использовать аналоги с поддержкой пула (например, в PHP это p:localhost, в .NET/Java/Python это встроенные объекты Pool).

Подсказать, как включить пул соединений именно в вашем стеке (PHP, Python, C#, Java)?

Копировать

Создание общедоступной ссылки…

Хороший ответ

Плохой ответ

Показать все

как понимаю это нужно и на машине где mysql

На самом деле,

больше всего это нужно на машине, которая выступает инициатором соединения (где работает само приложение).

Вот почему:

Кто «забивает» порты? Статус TIME_WAIT появляется на той стороне, которая первой инициировала закрытие TCP-сессии. Обычно это делает приложение после получения данных от базы.
Где дефицит портов? В вашем логе видно: 192.168.0.10:53553 стучится на 192.168.0.9:3306. Порт базы (3306) всегда один, а вот «исходящие» порты на машине приложения (53553, 53554...) уникальны. Именно они закончатся первыми, и приложение не сможет открыть новое соединение.

Где и что настраивать:

На сервере приложения (192.168.0.10):
- Обязательно установите TcpTimedWaitDelay = 30 и MaxUserPort = 65534. Это позволит приложению быстрее переиспользовать свои исходящие порты.
- Настройте Connection Pool в коде. Это сделает так, что вместо 8000 кратковременных соединений у вас будет, например, 50 «вечно живых». TIME_WAIT исчезнет сам собой.
На сервере MySQL (192.168.0.9):
- Здесь тоже полезно поставить TcpTimedWaitDelay = 30, чтобы стек TCP/IP сервера базы не «раздувался» от тысяч записей о закрытых сессиях в оперативной памяти.
- Проверьте в my.ini параметр max_connections. Если приложение начнет использовать пул, это значение должно быть чуть выше, чем размер пула.

Итог: Если вы настроите только сторону базы, приложение всё равно может «упереться» в лимит портов на своей стороне. Делайте правку реестра на обоих серверах.

На каком языке программирования написано ваше приложение? Я подскажу, как там включить пул.

Копировать

Создание общедоступной ссылки…

Хороший ответ

Плохой ответ

Показать все

Специальные ссылки

Фильтры и темы

Результаты поиска