форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Открытые системы на сервере (Система. проблемы, диагностика / Linux)
Изначальное сообщение		[ Отслеживать ]

"lsof (can't identify protocol). Слишком много."	+/–
Сообщение от dxtr (ok) on 12-Июн-10, 19:03
Есть у нас программа, созданная нашими разработчиками на 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)? Что я могу сделать, как системный администратор? Если я ничего не могу с этим сделать, тогда мне нужно как-то умно это передать программистам, указать в каком направлении решать проблему.
Высказать мнение | Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "lsof (can't identify protocol). Слишком много."	+/–
Сообщение от sHaggY_caT (ok) on 12-Июн-10, 23:39
>Что я могу сделать, как системный администратор? Если я ничего не могу >с этим сделать, тогда мне нужно как-то умно это передать программистам, >указать в каком направлении решать проблему. Не могу утверждать определенно (нужно тестить) но, скорее всего, Вам поможет запихнуть этот процесс в OpenVZ/LXC контейнер, если для логики работы программы приемлимо, что бы программа находилась отдельно от рабочей среды сервера. Если программа парсит, например, логи, в тот же OpenVZ контейнер их можно смонтировать с помощью mount --bind По результу вылета контейнера по UBC лимитам (увелечение счетчика failcnt) перезапускать контейнер с приложением. Возможность превышения лимита, наверное, можно объяснить тем, что при Вашем "открытии" файла не создаются дескрипторы, как при "настоящем" открытии
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	2. "lsof (can't identify protocol). Слишком много."	+/–
	Сообщение от Аноним (??) on 13-Июн-10, 02:40
	>[оверквотинг удален] >что бы программа находилась отдельно от рабочей среды сервера. > >Если программа парсит, например, логи, в тот же OpenVZ контейнер их можно >смонтировать с помощью mount --bind > >По результу вылета контейнера по UBC лимитам (увелечение счетчика failcnt) перезапускать контейнер >с приложением. > >Возможность превышения лимита, наверное, можно объяснить тем, что при Вашем "открытии" файла >не создаются дескрипторы, как при "настоящем" открытии Кошка, не давай, плз, таких советов, нефиг строить костыли, если есть возможность исправить. >>Что я могу сделать, как системный администратор? Если я ничего не могу >>с этим сделать, тогда мне нужно как-то умно это передать программистам, >>указать в каком направлении решать проблему. как системный администратор, вы можете пнуть программистов, что бы исправляли. описали вы проблему грамотно и программистам этого должно быть достаточно, если нужно будет что-то еще, они вас попросят.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

3. "lsof (can't identify protocol). Слишком много."	+/–
Сообщение от guest (??) on 13-Июн-10, 10:48
>Скажите, в каких случаях возникают подобные случаи (can't identify protocol)? Это описано в lsof FAQ пункт 10.2.2 не буду цитировать сюда, но вообщем-то это ничего не значит [в смысле не говорит о какой либо ошибке] кроме того, что написано) Любопытно, а что показывает netstat про эти сокеты? Почему то мне кажется что они просто висят в TIME_WAIT и потихоньку закрываются системой, иначе бы ваше приложение давно бы получило E[M]FILE.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	4. "lsof (can't identify protocol). Слишком много."	+/–
	Сообщение от dxtr (ok) on 14-Июн-10, 08:38
	>>Скажите, в каких случаях возникают подобные случаи (can't identify protocol)? > >Это описано в lsof FAQ пункт 10.2.2 >не буду цитировать сюда, но вообщем-то это ничего не значит [в смысле >не говорит о какой либо ошибке] кроме того, что написано) > >Любопытно, а что показывает netstat про эти сокеты? >Почему то мне кажется что они просто висят в TIME_WAIT и потихоньку >закрываются системой, иначе бы ваше приложение давно бы получило E[M]FILE. Спасибо за ответы! netstat показывает разные соединения на этом процессе. Как я могу определить состояние определенного сокета, зная его FD?   И можно ли как-то уменьшить значение TIME_WAIT, чтобы система чаще их закрывала? Потому что действительно, в какой-то момент времени (несколько раз в день), количество файлов уменьшается.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	6. "lsof (can't identify protocol). Слишком много."	+/–
	Сообщение от guest (??) on 14-Июн-10, 11:55
	>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, но сначало наверное лучше разобраться, так ли все на самом деле происходит. >Потому что действительно, в какой-то момент времени (несколько раз в день), >количество файлов уменьшается. Это не то, "полузакрытые" сокеты живут минуты, а никак не часы. Вам виднее что же имено делает это приложение, скорее всего просто падает нагрузка - соотвественно и соединений меньше. Раскажите пожалуйста побольше про это приложение, что оно делает?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	8. "lsof (can't identify protocol). Слишком много."	+/–
	Сообщение от dxtr (ok) on 14-Июн-10, 12:34
	>Откуда вам известен 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, вообще, подключаются не каждый день. Я попробую выудить это у программистов, хотя они явно не скоро дадут такую инфу.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	9. "lsof (can't identify protocol). Слишком много."	+/–
	Сообщение от guest (??) on 14-Июн-10, 12:54
	>То есть, можно воспринять, что программа в общем и не делает ошибок? >Хотя я ни разу с таким не сталкивался. Я склонен считать, что программ без ошибок не бывает))) >Еще у меня есть такое подозрение: в качестве сервера -- sles 10 >SP1(на всякий случай), lsof тормозит, и пока он тормозит программа успевает >открывать и закрывать файлы, отсюда и такое количество. >Сложно рассказать, так как сам обладаю не большой информацией, кроме как той, >что это такая финансовая система, принимающая подключения клиентов, от которых приходят >некие заявки. Клиентов не много. Ну, где-то около 70, вообще, подключаются >не каждый день. Я попробую выудить это у программистов, хотя они >явно не скоро дадут такую инфу. Как то горстка вялых клиентов (в программном смысле) и куча висящих сокетов между собой не вяжется) Что скажет netstat -anp|grep pid_прогаммы ?
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	10. "lsof (can't identify protocol). Слишком много."	+/–
	Сообщение от dxtr (ok) on 14-Июн-10, 13:10
	>[оверквотинг удален] >>открывать и закрывать файлы, отсюда и такое количество. >>Сложно рассказать, так как сам обладаю не большой информацией, кроме как той, >>что это такая финансовая система, принимающая подключения клиентов, от которых приходят >>некие заявки. Клиентов не много. Ну, где-то около 70, вообще, подключаются >>не каждый день. Я попробую выудить это у программистов, хотя они >>явно не скоро дадут такую инфу. > >Как то горстка вялых клиентов (в программном смысле) и куча висящих сокетов >между собой не вяжется) >Что скажет netstat -anp|grep pid_прогаммы ? А тут все хорошо: tcp        0      0 192.168.111.2:1530      192.168.5.70:1099       ESTABLISHED 3322/TS2111
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	11. "lsof (can't identify protocol). Слишком много."	+/–
	Сообщение от guest (??) on 14-Июн-10, 13:28
	>А тут все хорошо: >tcp        0     >  0 192.168.111.2:1530      192.168.5.70:1099   >     ESTABLISHED 3322/TS2111 Если это весь вывод, то это клиентская часть (нет LISTEN сокета). Вообщем тред превращается в гадание на кофейной гуще. Я бы для спокойствия зарезал приложению лимит на число открытых файлов и не дергался.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	12. "lsof (can't identify protocol). Слишком много."	+/–
	Сообщение от dxtr (ok) on 14-Июн-10, 13:36
	>>А тут все хорошо: >>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 примерно. Подозреваю почему система не дает сбой. Эти файлы открываются программой не всегда, а при определенных действиях пользователей (клиентов).
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	13. "lsof (can't identify protocol). Слишком много."	+/–
	Сообщение от guest (??) on 14-Июн-10, 14:37
	>Короче, каждый отдельный коннект от клиента -- создается новый процесс, с коротым >и открывается эта куча мусора. Это я сейчас нашел один LISTEN, >остальные ESTABLISHED. > >Поэтому я не правильно изначально считал. Я считал на один процес fd, >которых оказывалось около 1500 файлов на один процесс. На данный момент >подключено 250 пользователей. Отсюда огромное количество этих дескрипторов -- 300 000 >примерно. Не ни так, форкнутый процесс наследует все открытые fd родителя + может открывать что-то свое (врядли много) т.е. реально открытых сокетов так и есть около 1500. Раз того требует логика программы бороться с этим бесполезно и не нужно. Можно поставить ulimit -n 3000 для спокойствия и поиграть с tcp_fin_timeout в разумных приделах.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	14. "lsof (can't identify protocol). Слишком много."	+/–
	Сообщение от dxtr (ok) on 14-Июн-10, 14:49
	>[оверквотинг удален] >>примерно. > >Не ни так, форкнутый процесс наследует все открытые fd родителя + может >открывать что-то свое (врядли много) т.е. реально открытых сокетов так и >есть около 1500. >Раз того требует логика программы бороться с этим бесполезно и не нужно. > > >Можно поставить ulimit -n 3000 для спокойствия и поиграть с tcp_fin_timeout в >разумных приделах. Был ulimit меньше, чем сейчас (65000), программа висла. И еще: ts:/proc/7129/fd # lsof | grep vadim | wc -l 239481 lsof думал около 40 секунд.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	15. "lsof (can't identify protocol). Слишком много."	+/–
	Сообщение от guest (??) on 14-Июн-10, 15:43
	>Был ulimit меньше, чем сейчас (65000), программа висла. Тогда я чего-то не понимаю. При форке для ребенка используемые ресурсы ставятся в 0 (т.е. открытые родителем и доступные ребенку fd не учитываются). Конечно возможно что ваша программа форкнувшись открывает еще вагон файлов, но врядли... В конце концов есть поле FDSize в proc/pid/stats там должна быть правда о fd. >И еще: >ts:/proc/7129/fd # lsof | grep vadim | wc -l >239481 это одни и теже объекты, я уже писал - при форке ребенок получает полную копию таблицы открытых дескрипторов родителя. Смотрите конкретный pid.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	16. "lsof (can't identify protocol). Слишком много."	+/–
	Сообщение от dxtr (ok) on 14-Июн-10, 15:59
	>[оверквотинг удален] >врядли... >В конце концов есть поле FDSize в proc/pid/stats там должна быть правда >о fd. > >>И еще: >>ts:/proc/7129/fd # lsof | grep vadim | wc -l >>239481 > >это одни и теже объекты, я уже писал - при форке ребенок >получает полную копию таблицы открытых дескрипторов родителя. Смотрите конкретный pid. Да, вы правы. У процессах одни фд. Спасибо большое за ответы! Сейчас работаем с программистами, попробуем проследить отчего открывается столько файлов.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	17. "lsof (can't identify protocol). Слишком много."	+/–
	Сообщение от guest (??) on 14-Июн-10, 16:16
	>Сейчас работаем с программистами, попробуем проследить отчего открывается столько файлов. так 1500 это не много. Что бы не пугать вас выводом lsof им придется уйти от модели один процесс на клиента. Вряд ли вам удасться их уговорить сделать этот шаг. Для меня остался совершенно не понятным вопрос почему приложение падает при ulimit 3000 (что как я понял есть среднее за день число открытых fd per process * 2)
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

5. "lsof (can't identify protocol). Слишком много."	+/–
Сообщение от gluk__ on 14-Июн-10, 10:33
>[оверквотинг удален] >То есть, судя по всему это все открытые файлы без дескрипторов, раз >система все при этом продолжает дышать. Но до того, как я >устроился в эту компанию, говорят, что таблица уже пару раз была >переполнена и приводила боевой сервер к тому, что он переставал работать. > > >Скажите, в каких случаях возникают подобные случаи (can't identify protocol)? >Что я могу сделать, как системный администратор? Если я ничего не могу >с этим сделать, тогда мне нужно как-то умно это передать программистам, >указать в каком направлении решать проблему. буду спорить, что это 'забытые' tcp сокеты, по которым ядро уже получило time wait, а ваша программа их не закрыла.
Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

	7. "lsof (can't identify protocol). Слишком много."	+/–
	Сообщение от guest (??) on 14-Июн-10, 12:11
	Довайте спорить) >буду спорить, что это 'забытые' tcp сокеты, по которым ядро уже получило >time wait, согласен. >а ваша программа их не закрыла. не согласен. если бы был fd leak, то под нагрузкой программа довольно быстро выжрет все fd и наткнется на EFILE/EMFILE. Т.е. программа как раз fd закрывает, но система не закроет сокет пока peer не скажет, что все получил.
	Высказать мнение | Ответить | Правка | ^ | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема