Ну а кто сказал, что кодирование видео это быстро? тем более у вас изменение размера, а значит последующее сжатие снова. На хороших ксеонах еле-еле 1.5 раза от реальной скорости видео получается, а вас то наверняка vps.
В наше время давно пора кодировать в x264. По умолчанию с такими опциями должен получиться обычный vp6. Самое оптимальное - это двухпроходное в x264, но это еще дольше.
ладно, методика замера глазами не слишком чистая. TIME_WAIT-ы в линуксе таки есть, но чтобы их заметить мне пришлось запустить watch c интервалом 0.1 с и записывать. За пять минут всего два раза.
netwind добавил 03.12.2009 в 23:55
Пакеты между nginx и apache, но не на 127.0.0.1.
ну, конечно, одинаковые
Так я и держал и на лупбеке и на локальном IP, но на лупбеке без "ручек" TIME_WAIT все равно были и много.
Более того, если сделать tcpdump не на лупбеке, эти пакеты вообще не видно. Пакеты даже виртуально никуда не отсылаются. Может быть разницы между лупбеком и локальным IP нет совсем в смысле расхода сокетов в состоянии TIME_WAIT.
Outsourcenow, тогда почему на bsd их нет ? правильный процесс завершения вообще ведь не имеет смысла при локальных соединениях. и еще номера портов там продолжают расти, но на другом сервере повторно используются и я вижу только ESTABLISHED.
ну вот что-то не работает это на другом сайте, где соединений побольше. Стало меньше,но не пропали совсем. Так что настройка не аналогичная как в bsd net.inet.tcp.nolocaltimewait (соврал, по другому она называется на самом деле )
Там правда апач привязан НЕ на 127.0.0.1. Это так принципиально?
Outsourcenow, факт в том, что на bsd после такой настройки вообще пропадают из netstat локальные соединения в состоянии TIME_WAIT.
ну, я попробовал в линуксе и смотрю
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 1
тоже помогают. Раньше никогда не беспокоило. Для обычного "тяжелого" сайта разбираться с сокетами - это экономия на спичках. Может какие-нибудь баннерные системы с объемом кода 1 мб так загоняются.
Кстати, как я понимаю, у ТС зачем то ipv6-сокеты. для них настройки с таким же названием не видно.
Никуда они не исчезнут. Можно время сократить через sysctl net.ipv4.tcp_fin_timeout
Вот во freebsd есть sysctl net.inet.tcp.fast_finwait2_recycle, это поинтересней.
а ТС просто адаптирует функцию разбора лога. Все остальное уже написано. В этом сила самодельного велосипеда.
в документации на nginx написано что используется leaky bucket.
netwind добавил 02.12.2009 в 23:29
то есть, писать скрипт все равно придется? вы ничего про скрипт не сказали изначально.
ну а что будем делать с ддосом на shoutcast/red5/smtp/какой-нибудь_еще_странный_но_нужный_сервис ?
myhand, запуска iptables/ipset. Ведь если программа нашла бота, его имеет смысл заблокировать,засунуть в TARPIT, а не ждать пока он будет долбить в пределах установленных модулем limit_zone по тяжелому скрипту.
Ну и nginx никогда не сможет определить ddos на dns, а в программе это легко.
