В настоящее время у меня утечка сокета в моем приложении Node.js. Эта ошибка также опубликована Вот. Надеюсь скоро это исправить. CLOSE_WAIT и FIN_WAIT2 кажутся основной проблемой.
Connections: 1662
ESTABLISHED: 238
CLOSE_WAIT: 770
FIN_WAIT1: 4
FIN_WAIT2: 632
Следующие данные извлекаются путем ввода (альтернативные варианты):
netstat -anp | grep ${node_pid} | wc -l
Я читал, что вы можете решить эту проблему, настроив эти переменные:
net.ipv4.tcp_fin_timeout ( = 60 )
net.ipv4.tcp_keepalive_time ( = 7200 )
Хотя мой tcp_fin_timeout установлен на 60 секунд, мои сокеты остаются там более 60 секунд. Вот почему я думаю, что мне нужно настроить tcp_keepalive_time.
Он размещен на сервере Linux Centos 5, на котором также работают Apache и MySQL.
Могу ли я легко уменьшить tcp_keepalive_time до 1800, или, например, это окажет негативное влияние на Apache?
Есть несколько вариантов, которые вы можете настроить для экономии ресурсов сервера, связанных с подключением. Видеть эта страница за парочку вариантов и их описание. Также см. Список ссылок в конце этой страницы:
man 7 ip
man 7 tcp
http://www.faqs.org/docs/securing/chap6sec70.html
http://man7.org/linux/man-pages/man7/ip.7.html
http://tldp.org/HOWTO/TCP-Keepalive-HOWTO/usingkeepalive.html
Вы можете уменьшить tcp_fin_timeout до 20, поскольку это решает проблему, которая возникает в конце срока жизни / требования соединения. То же самое и для tcp_keepalive_time, если вы снизите его до разумного и не слишком низкого значения (скажем, 600, при использовании с tcp_keepalive_intvl и tcp_keepalive_probes).
На вашем сервере Apache не должно быть никаких негативных последствий, поскольку типичный веб-трафик HTTP очень прерывистый и недолговечный. Если пользователь не загружает большой файл по ссылке с очень высокой потерей пакетов, в этом случае доступ к вашему сайту будет наименьшей из их забот.
Если вы только что прочитали справочные страницы и эти ссылки, он должен стать красивым (любая путаница, очевидно, задайте здесь вопрос!).