LINUX.ORG.RU
ФорумAdmin

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

 ,


0

1

Небольшая предистория. У меня есть несколько серверов на платном хостинге под OpenVZ. Один из них CentOS, два Ubuntu. На каждом из них крутится Oracle 11g XE. Каждый из них стабильно падает по несколько раз в неделю без какой либо закономерности с ошибкой «too many open files in system». Т.е. они как бы работают, но в консоли нельзя выполнить практически ни одной команды. Мои познания в Linux очень скудные, потому самостоятельно разобраться с проблемой не удается. Первое, с чего начал: ulimit -n 65535, не помогло, результат тот же. К тому же рядом на столе стоит несколько десктопных серверов с такими же ОС, ПО, настройкой ulimit -n 1024 и стабильно работают несколько лет. Помогите разобраться с ситуацией.

Ответ на: комментарий от Sawradym

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

AS ★★★★★ ()

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

anonymous ()

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

Bobby_ ()
Ответ на: комментарий от Bobby_

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

Revent ()
Ответ на: комментарий от AS

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

Sawradym ()
Ответ на: комментарий от anonymous

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

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

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

Sawradym ()
Ответ на: комментарий от Bobby_

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

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

Sawradym ()
Ответ на: комментарий от Revent

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

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

Bobby_ ()

Ситуация немного прояснилась. Выяснилось что на порт 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
при этом не пытаюсь подключаться. В течении 5-10 сек. вижу что по этому правилу проходит 3 пакета. После этого удаляю это правило и на ближайшие ~2 часа снова все работает. Можно ли как-то узнать с какого IP прошли эти загадочные 3 пакета? Или возможно я вообще не туда копаю? Уже голова кругом, чувствую себя обезьяной с гранатой.

Sawradym ()
Ответ на: комментарий от Sawradym

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

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
Общий смысл такой, сначала должно быть правило с теме же условиями но запись в лог -j LOG, следующим после него теже условия, но -j что-хотим например ACCEPT
--log-prefix удобен что бы грепать по нему логи

А вообще лучше бы показали iptables-save

anc ★★★★★ ()
Ответ на: комментарий от anc

Сделал как Вы сказали, но в логах почему-то ничего нет. 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

Sawradym ()
Ответ на: комментарий от Sawradym

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

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

anc ★★★★★ ()
Ответ на: комментарий от anc

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

anc ★★★★★ ()
Ответ на: комментарий от anc

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

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

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

Sawradym ()
Ответ на: комментарий от Sawradym

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

anc ★★★★★ ()
Ответ на: комментарий от anc

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

пролетают!

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

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

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

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

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

Sawradym ()
Ответ на: комментарий от Sawradym

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

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

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

anc ★★★★★ ()
Ответ на: комментарий от anc

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

anc ★★★★★ ()
Ответ на: комментарий от anc

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

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

Sawradym ()
Ответ на: комментарий от Sawradym

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

anc ★★★★★ ()
Последнее исправление: anc (всего исправлений: 1)
Ответ на: комментарий от anc

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

-A INPUT -p tcp -m tcp --dport 1521 -j LOG --log-prefix "- - - - iptables 1521"
то фильтр нужно дописать ! src net *.*.*.*/32 and ! src net *.*.0.0/16 and dst port 1521

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

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

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

vel ★★★★★ ()
Последнее исправление: vel (всего исправлений: 1)
Ответ на: комментарий от anc

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

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

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

Sawradym ()
Ответ на: комментарий от vel

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

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

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

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

Sawradym ()
Ответ на: комментарий от vel

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

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

anc ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.