Помогите определить кто валит систему и как это побороть - «too many open files in system»

под OpenVZ

cat /proc/user_beancounters

Спасибо! Пока читаю, разбираюсь...

Ну там особо нечего разбираться. Лимиты задаёт владелец хостинга, а владелец VPS может только контролировать упор в лимит и периодичность. Если колонка failcnt содержит что-то, отличное от нуля, значит были упоры в лимиты.

У оracle есть поддержка/сертификация работы на OpenVZ?

Зачем покупать лицензию на Oracle, чтобы искать помощь на ЛОР?

Зачем покупать лицензию на оракл если можно спросить на ЛОРе?

Понял, спасибо. Пока что там сплошные нули. В строке numfile значение held стабильно держится в районе половины от limit. Подожду пока упадет.

У оracle есть поддержка/сертификация работы на OpenVZ?

Не знаю. Быстрый поиск сходу ничего не дал. Нашел только для VMWare.С другой стороны явного запрета тоже не обнаружил.

Пока буду долбить в эту сторону, тем более что других вариантов у меня пока нет. Хостинг оплачен на год вперед. (((

Зачем покупать лицензию на Oracle, чтобы искать помощь на ЛОР?

Oracle Database 11g Express Edition Free to develop, deploy, and distribute.

Зачем покупать лицензию на оракл

Чтобы бизнес мог работать без потерь. Для поиграться можно поставить пострес, шанс получить ответ на ЛОР, для него существенно выше.

Ситуация немного прояснилась. Выяснилось что на порт 1521 (Oracle TNSListener) упорно кто-то ломится, в отдельные моменты времени до 10 раз в секунду. В результате этого Oracle создает кучу процессов xe_Snnn_XE (Shared Server process), вот они и сжирают весь лимит по открытым файлам. Всвязи с этим пришлось дополнительно подкрутить файервол в том плане чтобы подключаться могли только определенные пулы IP. Проблема вроде бы решилась, левых подключений нет, лишние процессы не создаются, но вместо нее появилась другая, связанная с настройкой iptables. Сейчас, упрощенно, там прописано такое:

iptables -A INPUT -d tcp -s (my_ip) --dport 1521 -j ACCEPT
iptables -A INPUT -d tcp --dport 1521 -j DROP

вроде бы все работает, но через определенное время, примерно 2 часа, новые соединения уже не устанавливаются (старые продолжают работать). Опытным путем установлено что, настройка:

iptables -I INPUT 1 -s (my_ip) -j ACCEPT

iptables -D INPUT 1
iptables -I INPUT 2 -d tcp --dport 1521 -j ACCEPT

Немного лирики

iptables -A INPUT -d tcp -s (my_ip) --dport 1521 -j ACCEPT

-A добавляет правило в конец цепочки, что перед ним мы не знаем

iptables -I INPUT 1 -s (my_ip) -j ACCEPT

тут верно, будет первым правилом

iptables -D INPUT 1
iptables -I INPUT 2 -d tcp --dport 1521 -j ACCEPT

Тут наверное неверно, удалили первое правило, т.е. первым стало то которое было за ним, а добавили на место второго правила.

По существу:

Можно ли как-то узнать с какого IP прошли эти загадочные 3 пакета?

-j LOG и потом смотрим в syslog
Например так:

iptables -A INPUT -s (my_ip) -j LOG --log-prefix="la-la-la"
iptables -A INPUT -s (my_ip) -j ACCEPT

Сделал как Вы сказали, но в логах почему-то ничего нет. journalctl -k ничего не показывает.

Вот мой iptables-save

]# iptables-save
# Generated by iptables-save v1.4.21 on Sat Mar 10 07:30:27 2018
*raw
:PREROUTING ACCEPT [179815:27252369]
:OUTPUT ACCEPT [173369:37817699]
COMMIT
# Completed on Sat Mar 10 07:30:27 2018
# Generated by iptables-save v1.4.21 on Sat Mar 10 07:30:27 2018
*mangle
:PREROUTING ACCEPT [179815:27252369]
:INPUT ACCEPT [179815:27252369]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [173370:37817803]
:POSTROUTING ACCEPT [173370:37817803]
COMMIT
# Completed on Sat Mar 10 07:30:27 2018
# Generated by iptables-save v1.4.21 on Sat Mar 10 07:30:27 2018
*filter
:INPUT ACCEPT [804:47900]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [4911:4233442]
-A INPUT -s *.*.*.*/32 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -s *.*.0.0/16 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -s *.*.*.*/32 -p tcp -m tcp --dport 1521 -j ACCEPT
-A INPUT -s *.*.0.0/16 -p tcp -m tcp --dport 1521 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 1521 -j LOG --log-prefix "- - - - iptables 1521"
-A INPUT -p tcp -m tcp --dport 1521 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j DROP
-A INPUT -p tcp -m tcp --dport 1521 -j REJECT --reject-with icmp-port-unreachable
-A INPUT -p icmp -j DROP
COMMIT
# Completed on Sat Mar 10 07:30:27 2018

Сделал как Вы сказали, но в логах почему-то ничего нет. journalctl -k ничего не показывает.

А пакетики в цепочке -A INPUT -p tcp -m tcp --dport 1521 -j LOG --log-prefix "- - - - iptables 1521" были? iptables -L INPUT -nv что показывает?

PS 1. На всякий случай обращаю внимание, что на текущий момент у вас 1521/tcp открыт для всех.
2. Не мое дело, знаю что существуют адепты подхода «если у меня ничего не слушает на портах то и нечего закрываться», но все-таки, у вас закрыт только ssh и icmp. Кстати, за что icmp порезали?

PS 1. На всякий случай обращаю внимание, что на текущий момент у вас 1521/tcp открыт для всех.
2. Не мое дело, знаю что существуют адепты подхода «если у меня ничего не слушает на портах то и нечего >закрываться», но все-таки, у вас закрыт только ssh и icmp. Кстати, за что icmp порезали?

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

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

1. Так пакеты по правилу пролетают?
2. Запрещено все что не разрешено.
в правила -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
А дальше как нравиться
Или полиси iptables -P INPUT DROP
Или последним правилом iptables -A INPUT -j DROP
У варианта с полиси есть один минус, если наберете команду iptables -F, то потеряете соединение :) Что без доступа к консоли может оказаться печалькой :)

1. Так пакеты по правилу пролетают?

пролетают!

2. Запрещено все что не разрешено.
в правила -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

Напоминаю это хостинг на openvz. Данное правило не проходит (((

А дальше как нравиться
Или полиси iptables -P INPUT DROP
Или последним правилом iptables -A INPUT -j DROP
У варианта с полиси есть один минус, если наберете команду iptables -F, то потеряете соединение :) Что без доступа к >консоли может оказаться печалькой :)

Это все понятно и уже опробовано.

Все-таки хотелось бы добить вопрос с логированием.

Напоминаю это хостинг на openvz. Данное правило не проходит (((

Ох. Простите. ( Зацепился только за последнюю задачу, упустив про контейнер и на хостинге.

ЗЫ не по теме логирования
Я написал по «старинке» с модулем state, может iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT будет работать.

Забыл в тему логирования. Старый дедовский способ это tcpdump.
Что-то типа tcpdump -n -l ! net *.*.*.*/32 and ! net *.*.0.0/16 and port 1521 звездочки из сетей я скопипастил из ваших правил в сообщении выше, так что подправьте на ваши реальные.

Спасибо, получилось, но легче не стало. iptables показывает что прошло 6 пакетов, tcpdump - 0. Как такое может быть?

Убираю условие по ip, через tcpdump вижу что пакеты сыпятся, но они все с моего ip. Почему тогда 6 пакетов идут по другому правилу в iptables?

Кроме варианта что tcpdump и счетчик iptables были запущены в разное время, другого на ум не приходит. OpenVZ глубоко не копал, и в наличии нет что бы проверить, на варианте lxc все отрабатывает как надо.
К сожалению моего конгфу на большее не хватает. vel может что-то подскажете ?
PS у tcpdump убрать ключ -l ведь действительно может и пропустить.

Если посмотреть на правило

-A INPUT -p tcp -m tcp --dport 1521 -j LOG --log-prefix "- - - - iptables 1521"

Я об openvz почти ничего не знаю.

Если там работает хотя бы «conntrack -L», я бы понаблюдал за этой таблицей. Не исключаю, что диагностика «Too many open file» это оповещение о том, что закончился conntrack или ограничение на число открытых сокетов https://openvz.org/UBC_primary_parameters про numtcpsock

netstat/ss не смотрели во время наступления проблем ?

Кроме варианта что tcpdump и счетчик iptables были запущены в разное время, другого на ум не приходит. OpenVZ глубоко не >копал, и в наличии нет что бы проверить, на варианте lxc все отрабатывает как надо.
К сожалению моего конгфу на большее не хватает. vel может что-то подскажете ?
PS у tcpdump убрать ключ -l ведь действительно может и пропустить.

Попробовал без -l, результат тот же.

В любом случае, огромное спасибо за помощь. Узнал много интересного. Благо известен рецепт дающий гарантированный результат работоспособности. Самое время научиться писать скрипты работающие по расписанию. Впринципе такой костыль меня бы устроил.

Если там работает хотя бы «conntrack -L», я бы понаблюдал за этой таблицей. Не исключаю, что диагностика «Too many open >file» это оповещение о том, что закончился conntrack или ограничение на число открытых сокетов >https://openvz.org/UBC_primary_parameters про numtcpsock

conntrack тоже не работает. С «Too many open >file», мне кажется, я уже разобрался. Теперь пытаюсь разобраться с последствиями «лечения».

netstat/ss не смотрели во время наступления проблем ?

нет, не смотрел. пошел смотреть.

netstat/ss не смотрели во время наступления проблем ?

А вот это действительно хорошая идея. Я знал что Вы подкините что-то еще :)
ТС записать в скрипт с беконечным циклом, и с sleep сколько-понравиться.