Данность такая - сервер на линуксе. Fedora 3. ядро 2.6.16.29.
В принципе это роутер между сетью и инетом. Поднят mysql 3.23.58,
апач -2, quagga, счетчик трафика на ipfm.
Файрвол реализован на ipset и iptables. трафик порядка нескольких сотен гигов в сутки.После перезагрузки сервера первые пару дней загрузка системы не превышает в час пик значения 4.
Но постепенно загрузка растет и на 5-6 день может достигать 50.Такое ощущение, что забивается до отказа какая-то таблица..Будто бы что-то накапливается и отбирает все ресурсы процессора. Сервер начинает жутко тормозить. После перезагрузки опять пару дней нормально.
Что это может быть? Никто не сталкивался с таким?
В каком смысле "загрузка системы"?
Если речь о load average, то надо смотреть сколько и каких процессов запущено. Вероятно, какая-то программа постепенно плодит процессы, каждый из которых требует процессорного времени и никогда не заверщается. Я почему-то думаю, что это скорее всего апач.
>В каком смысле "загрузка системы"?
>Если речь о load average, то надо смотреть сколько и каких процессов
>запущено. Вероятно, какая-то программа постепенно плодит процессы, каждый из которых требует
>процессорного времени и никогда не заверщается. Я почему-то думаю, что это
>скорее всего апач.с таким объемом трафика вообще не следовалобы чтото вешать на сервак
Линукс может переварить и терабайты.В дополнение к теме..Открылась еще одна подробность, что почему-то сбрасывается значение
ip_conntrack_max
Вначале ему задается значение 600000. Через какое-то время в логах появляется сообщение
ip_conntrack: table full, dropping packetа значение ip_conntrack_max само сбрасывается в 32768..Почему?
Важно не количество байт, а количество соединений/пакетов.
Посмотрите внимательно правила и постарайтесь максимально ограничить использование conntrack при помощи таблицы raw, лучше всего вообще оставить conntrack только для явных NAT. Это может существенно снизить нагрузку.
Вписал в стенку в FORWARD дропанье пакетов в состоянии INVALID.
Load average стал не более 3. Либо атаки и сканировние, либо в сети полно вирусованых клиентов и доморощенных хакеров? Или и того и другого?
Молодца, но про табличку raw таки почитайте :)
>Молодца, но про табличку raw таки почитайте :)я вот тоже почитал про табличку эту, кинул все соединения на NOTRACK в PREROUTING, но так и не заметил уменьшения цифирок:
# cat /proc/net/ip_conntrack |wc
13400 267960 2918533
1. Это нормально ?
2. При каком числе соединений имеет смысл использовать NOTRACK, и имеет ли смысл использовать вообще, при условии что машинка - веб-сервер и файрволл на ней почти не используется?
Дык, разумеется что зависит от задач. На веб-сервере в первую очередь упрется в производительность приложений, а не ip-фильтра и заморачиваться с raw не стоит, а вот на шлюзах это вполне может иметь смысл(cам видел когда забывание про эту таблицу приводило к разрастанию conntrack до нескольких гигов, а так как физической памяти на машине было значительно меньше, то в ход пошел своп, догадайтесь как приятно было пытаться на эту машину зайти и найти источник проблемы). Опять таки, если основная задача шлюза NAT, то raw использовать не получится.
А у меня таблицу raw использовать не получается..
>iptables -t raw -I PREROUTING -d XXX.XXX.XXX.XXX -j NOTRACKОтвет iptables: No chain/target/match by that name
Хотя сама таблица есть, и в нее можно чтоПрихожу к выводу, что как ни играйся с этими цифирьками, а решить проблему можно только увеличением оперативной памяти, не свопа.
Как по мне лучше исходить из противоположного принципа, то есть последние действия в raw это безусловный NOTRACK для PREROUTING и OUTPUT цепочек, а для нужных ip прописываем перед этим правила с -j RETURN. Опять таки польза будет зависеть от того, чем занят шлюз, если большая часть соединений нуждается в слежении, то ничего кроме наращивания памяти не поделать.