Есть у нас программа, созданная нашими разработчиками на c++. При выводе lsof видно, что она открывает ненормально огромное количество файлов,TS2111 553 vadim 1408u sock 0,5 7571967 can't identify protocol
TS2111 553 vadim 1409u sock 0,5 7572028 can't identify protocol
TS2111 553 vadim 1410u sock 0,5 7572113 can't identify protocol
TS2111 553 vadim 1411u sock 0,5 7572164 can't identify protocol
TS2111 553 vadim 1412u sock 0,5 7572364 can't identify protocol
TS2111 553 vadim 1413u sock 0,5 7572553 can't identify protocol
TS2111 553 vadim 1414u sock 0,5 7572557 can't identify protocol
TS2111 553 vadim 1415u sock 0,5 7572757 can't identify protocol
TS2111 553 vadim 1416u sock 0,5 7572974 can't identify protocol
TS2111 553 vadim 1417u sock 0,5 7583708 can't identify protocol
TS2111 553 vadim 1418u sock 0,5 7583935 can't identify protocol
TS2111 553 vadim 1419u sock 0,5 7584001 can't identify protocol
TS2111 553 vadim 1420u sock 0,5 7584131 can't identify protocolЗа день их количество вырастает до 400 000, не смотря на:
ts:~/ # cat /proc/sys/fs/file-max
131072То есть, судя по всему это все открытые файлы без дескрипторов, раз система все при этом продолжает дышать. Но до того, как я устроился в эту компанию, говорят, что таблица уже пару раз была переполнена и приводила боевой сервер к тому, что он переставал работать.
Скажите, в каких случаях возникают подобные случаи (can't identify protocol)?
Что я могу сделать, как системный администратор? Если я ничего не могу с этим сделать, тогда мне нужно как-то умно это передать программистам, указать в каком направлении решать проблему.
>Что я могу сделать, как системный администратор? Если я ничего не могу
>с этим сделать, тогда мне нужно как-то умно это передать программистам,
>указать в каком направлении решать проблему.Не могу утверждать определенно (нужно тестить) но, скорее всего, Вам поможет запихнуть этот процесс в OpenVZ/LXC контейнер, если для логики работы программы приемлимо, что бы программа находилась отдельно от рабочей среды сервера.
Если программа парсит, например, логи, в тот же OpenVZ контейнер их можно смонтировать с помощью mount --bind
По результу вылета контейнера по UBC лимитам (увелечение счетчика failcnt) перезапускать контейнер с приложением.
Возможность превышения лимита, наверное, можно объяснить тем, что при Вашем "открытии" файла не создаются дескрипторы, как при "настоящем" открытии
>[оверквотинг удален]
>что бы программа находилась отдельно от рабочей среды сервера.
>
>Если программа парсит, например, логи, в тот же OpenVZ контейнер их можно
>смонтировать с помощью mount --bind
>
>По результу вылета контейнера по UBC лимитам (увелечение счетчика failcnt) перезапускать контейнер
>с приложением.
>
>Возможность превышения лимита, наверное, можно объяснить тем, что при Вашем "открытии" файла
>не создаются дескрипторы, как при "настоящем" открытииКошка, не давай, плз, таких советов, нефиг строить костыли, если есть возможность исправить.
>>Что я могу сделать, как системный администратор? Если я ничего не могу
>>с этим сделать, тогда мне нужно как-то умно это передать программистам,
>>указать в каком направлении решать проблему.как системный администратор, вы можете пнуть программистов, что бы исправляли.
описали вы проблему грамотно и программистам этого должно быть достаточно, если нужно будет что-то еще, они вас попросят.
>Скажите, в каких случаях возникают подобные случаи (can't identify protocol)?Это описано в lsof FAQ пункт 10.2.2
не буду цитировать сюда, но вообщем-то это ничего не значит [в смысле не говорит о какой либо ошибке] кроме того, что написано)Любопытно, а что показывает netstat про эти сокеты?
Почему то мне кажется что они просто висят в TIME_WAIT и потихоньку закрываются системой, иначе бы ваше приложение давно бы получило E[M]FILE.
>>Скажите, в каких случаях возникают подобные случаи (can't identify protocol)?
>
>Это описано в lsof FAQ пункт 10.2.2
>не буду цитировать сюда, но вообщем-то это ничего не значит [в смысле
>не говорит о какой либо ошибке] кроме того, что написано)
>
>Любопытно, а что показывает netstat про эти сокеты?
>Почему то мне кажется что они просто висят в TIME_WAIT и потихоньку
>закрываются системой, иначе бы ваше приложение давно бы получило E[M]FILE.Спасибо за ответы!
netstat показывает разные соединения на этом процессе. Как я могу определить состояние определенного сокета, зная его FD?
И можно ли как-то уменьшить значение TIME_WAIT, чтобы система чаще их закрывала? Потому что действительно, в какой-то момент времени (несколько раз в день), количество файлов уменьшается.
>netstat показывает разные соединения на этом процессе. Как я могу определить состояние
>определенного сокета, зная его FD?Откуда вам известен fd???
Если я угадал с TIME_WAIT/FIN_WAIT, то ваше приложение уже сделало close() на этих сокетах
и fd не существует. Есть inode которые показывает lsof, но netstat к сожалению их не показывает. Можно пытаться искать руками [grep INODE /proc/net], но скорее всего оно ничего не найдет.
Попробовал воспроизвести такую ситуацию:
TCP сервер отсылает 10k мусора и закрывает сокет. Клиент 100 потоков в цикле (jakarta-jmeter).
Картина похожа на вашу: lsof дико тормозит и показывает кучу строк
testd 2082 guest 15u sock 0,4 1376395 can't identify protocol>И можно ли как-то уменьшить значение TIME_WAIT, чтобы система чаще их закрывала?
глобально /proc/sys/net/ipv4/tcp_fin_timeout , на уровне приложения может помочь SO_LINGER, но сначало наверное лучше разобраться, так ли все на самом деле происходит.
>Потому что действительно, в какой-то момент времени (несколько раз в день),
>количество файлов уменьшается.Это не то, "полузакрытые" сокеты живут минуты, а никак не часы. Вам виднее что же имено делает это приложение, скорее всего просто падает нагрузка - соотвественно и соединений меньше.
Раскажите пожалуйста побольше про это приложение, что оно делает?
>Откуда вам известен fd???Например, небольшой кусок:
$ ls -la /proc/PID/fd/
lrwx------ 1 vadim users 64 2010-06-14 14:05 60 -> socket:[12835000]
lrwx------ 1 vadim users 64 2010-06-14 14:05 600 -> socket:[12932508]
lrwx------ 1 vadim users 64 2010-06-14 14:05 601 -> socket:[12932605]
lrwx------ 1 vadim users 64 2010-06-14 14:05 602 -> socket:[12932697]
lrwx------ 1 vadim users 64 2010-06-14 14:05 603 -> socket:[12932734]
lrwx------ 1 vadim users 64 2010-06-14 14:05 604 -> socket:[12932932]
lrwx------ 1 vadim users 64 2010-06-14 14:05 605 -> socket:[12932956]
lrwx------ 1 vadim users 64 2010-06-14 14:05 606 -> socket:[12933047]
lrwx------ 1 vadim users 64 2010-06-14 14:05 607 -> socket:[12933081]
lrwx------ 1 vadim users 64 2010-06-14 14:05 608 -> socket:[12933103]
lrwx------ 1 vadim users 64 2010-06-14 14:05 609 -> socket:[12933136]>Если я угадал с TIME_WAIT/FIN_WAIT, то ваше приложение уже сделало close() на
>этих сокетах
>и fd не существует. Есть inode которые показывает lsof, но netstat к
>сожалению их не показывает. Можно пытаться искать руками [grep INODE /proc/net],
>но скорее всего оно ничего не найдет.Так и есть.
>Попробовал воспроизвести такую ситуацию:
>TCP сервер отсылает 10k мусора и закрывает сокет. Клиент 100 потоков в
>цикле (jakarta-jmeter).
>Картина похожа на вашу: lsof дико тормозит и показывает кучу строк
>testd 2082 guest 15u
>sock 0,4
> 1376395 can't identify protocolТо есть, можно воспринять, что программа в общем и не делает ошибок? Хотя я ни разу с таким не сталкивался.
>>И можно ли как-то уменьшить значение TIME_WAIT, чтобы система чаще их закрывала?
>
>глобально /proc/sys/net/ipv4/tcp_fin_timeout , на уровне приложения может помочь SO_LINGER, но сначало наверное
>лучше разобраться, так ли все на самом деле происходит.Да, хочется выяснить проблему сначала.
>>Потому что действительно, в какой-то момент времени (несколько раз в день),
>>количество файлов уменьшается.
>
>Это не то, "полузакрытые" сокеты живут минуты, а никак не часы. Вам
>виднее что же имено делает это приложение, скорее всего просто падает
>нагрузка - соотвественно и соединений меньше.Еще у меня есть такое подозрение: в качестве сервера -- sles 10 SP1(на всякий случай), lsof тормозит, и пока он тормозит программа успевает открывать и закрывать файлы, отсюда и такое количество.
>Раскажите пожалуйста побольше про это приложение, что оно делает?
Сложно рассказать, так как сам обладаю не большой информацией, кроме как той, что это такая финансовая система, принимающая подключения клиентов, от которых приходят некие заявки. Клиентов не много. Ну, где-то около 70, вообще, подключаются не каждый день. Я попробую выудить это у программистов, хотя они явно не скоро дадут такую инфу.
>То есть, можно воспринять, что программа в общем и не делает ошибок?
>Хотя я ни разу с таким не сталкивался.Я склонен считать, что программ без ошибок не бывает)))
>Еще у меня есть такое подозрение: в качестве сервера -- sles 10
>SP1(на всякий случай), lsof тормозит, и пока он тормозит программа успевает
>открывать и закрывать файлы, отсюда и такое количество.
>Сложно рассказать, так как сам обладаю не большой информацией, кроме как той,
>что это такая финансовая система, принимающая подключения клиентов, от которых приходят
>некие заявки. Клиентов не много. Ну, где-то около 70, вообще, подключаются
>не каждый день. Я попробую выудить это у программистов, хотя они
>явно не скоро дадут такую инфу.Как то горстка вялых клиентов (в программном смысле) и куча висящих сокетов между собой не вяжется)
Что скажет netstat -anp|grep pid_прогаммы ?
>[оверквотинг удален]
>>открывать и закрывать файлы, отсюда и такое количество.
>>Сложно рассказать, так как сам обладаю не большой информацией, кроме как той,
>>что это такая финансовая система, принимающая подключения клиентов, от которых приходят
>>некие заявки. Клиентов не много. Ну, где-то около 70, вообще, подключаются
>>не каждый день. Я попробую выудить это у программистов, хотя они
>>явно не скоро дадут такую инфу.
>
>Как то горстка вялых клиентов (в программном смысле) и куча висящих сокетов
>между собой не вяжется)
>Что скажет netstat -anp|grep pid_прогаммы ?А тут все хорошо:
tcp 0 0 192.168.111.2:1530 192.168.5.70:1099 ESTABLISHED 3322/TS2111
>А тут все хорошо:
>tcp 0
> 0 192.168.111.2:1530 192.168.5.70:1099
> ESTABLISHED 3322/TS2111Если это весь вывод, то это клиентская часть (нет LISTEN сокета).
Вообщем тред превращается в гадание на кофейной гуще.
Я бы для спокойствия зарезал приложению лимит на число открытых файлов и не дергался.
>>А тут все хорошо:
>>tcp 0
>> 0 192.168.111.2:1530 192.168.5.70:1099
>> ESTABLISHED 3322/TS2111
>
>Если это весь вывод, то это клиентская часть (нет LISTEN сокета).
>Вообщем тред превращается в гадание на кофейной гуще.
>Я бы для спокойствия зарезал приложению лимит на число открытых файлов и
>не дергался.Хм, вот такая вот вещь еще:
tcp 0 0 0.0.0.0:1530 0.0.0.0:* LISTEN 21517/TS2111Короче, каждый отдельный коннект от клиента -- создается новый процесс, с коротым и открывается эта куча мусора. Это я сейчас нашел один LISTEN, остальные ESTABLISHED.
Поэтому я не правильно изначально считал. Я считал на один процес fd, которых оказывалось около 1500 файлов на один процесс. На данный момент подключено 250 пользователей. Отсюда огромное количество этих дескрипторов -- 300 000 примерно.
Подозреваю почему система не дает сбой. Эти файлы открываются программой не всегда, а при определенных действиях пользователей (клиентов).
>Короче, каждый отдельный коннект от клиента -- создается новый процесс, с коротым
>и открывается эта куча мусора. Это я сейчас нашел один LISTEN,
>остальные ESTABLISHED.
>
>Поэтому я не правильно изначально считал. Я считал на один процес fd,
>которых оказывалось около 1500 файлов на один процесс. На данный момент
>подключено 250 пользователей. Отсюда огромное количество этих дескрипторов -- 300 000
>примерно.Не ни так, форкнутый процесс наследует все открытые fd родителя + может открывать что-то свое (врядли много) т.е. реально открытых сокетов так и есть около 1500.
Раз того требует логика программы бороться с этим бесполезно и не нужно.Можно поставить ulimit -n 3000 для спокойствия и поиграть с tcp_fin_timeout в разумных приделах.
>[оверквотинг удален]
>>примерно.
>
>Не ни так, форкнутый процесс наследует все открытые fd родителя + может
>открывать что-то свое (врядли много) т.е. реально открытых сокетов так и
>есть около 1500.
>Раз того требует логика программы бороться с этим бесполезно и не нужно.
>
>
>Можно поставить ulimit -n 3000 для спокойствия и поиграть с tcp_fin_timeout в
>разумных приделах.Был ulimit меньше, чем сейчас (65000), программа висла.
И еще:
ts:/proc/7129/fd # lsof | grep vadim | wc -l
239481lsof думал около 40 секунд.
>Был ulimit меньше, чем сейчас (65000), программа висла.Тогда я чего-то не понимаю. При форке для ребенка используемые ресурсы ставятся в 0 (т.е. открытые родителем и доступные ребенку fd не учитываются). Конечно возможно что ваша программа форкнувшись открывает еще вагон файлов, но врядли...
В конце концов есть поле FDSize в proc/pid/stats там должна быть правда о fd.>И еще:
>ts:/proc/7129/fd # lsof | grep vadim | wc -l
>239481это одни и теже объекты, я уже писал - при форке ребенок получает полную копию таблицы открытых дескрипторов родителя. Смотрите конкретный pid.
>[оверквотинг удален]
>врядли...
>В конце концов есть поле FDSize в proc/pid/stats там должна быть правда
>о fd.
>
>>И еще:
>>ts:/proc/7129/fd # lsof | grep vadim | wc -l
>>239481
>
>это одни и теже объекты, я уже писал - при форке ребенок
>получает полную копию таблицы открытых дескрипторов родителя. Смотрите конкретный pid.Да, вы правы. У процессах одни фд.
Спасибо большое за ответы!
Сейчас работаем с программистами, попробуем проследить отчего открывается столько файлов.
>Сейчас работаем с программистами, попробуем проследить отчего открывается столько файлов.так 1500 это не много.
Что бы не пугать вас выводом lsof им придется уйти от модели один процесс на клиента.
Вряд ли вам удасться их уговорить сделать этот шаг.Для меня остался совершенно не понятным вопрос почему приложение падает при ulimit 3000 (что как я понял есть среднее за день число открытых fd per process * 2)
>[оверквотинг удален]
>То есть, судя по всему это все открытые файлы без дескрипторов, раз
>система все при этом продолжает дышать. Но до того, как я
>устроился в эту компанию, говорят, что таблица уже пару раз была
>переполнена и приводила боевой сервер к тому, что он переставал работать.
>
>
>Скажите, в каких случаях возникают подобные случаи (can't identify protocol)?
>Что я могу сделать, как системный администратор? Если я ничего не могу
>с этим сделать, тогда мне нужно как-то умно это передать программистам,
>указать в каком направлении решать проблему.буду спорить, что это 'забытые' tcp сокеты, по которым ядро уже получило time wait,
а ваша программа их не закрыла.
Довайте спорить)
>буду спорить, что это 'забытые' tcp сокеты, по которым ядро уже получило
>time wait,согласен.
>а ваша программа их не закрыла.
не согласен. если бы был fd leak, то под нагрузкой программа довольно быстро выжрет все fd и наткнется на EFILE/EMFILE. Т.е. программа как раз fd закрывает, но система не закроет сокет пока peer не скажет, что все получил.