Sacrament Опубликовано 31 октября, 2019 · Жалоба @crank А сервер какой конфигурации у Вас? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
crank Опубликовано 31 октября, 2019 · Жалоба 3 часа назад, Sacrament сказал: @crank А сервер какой конфигурации у Вас? HP DL160 G6 CPU: 2 x Intel(R) Xeon(R) CPU E5520 @ 2.27GHz RAM: 16GB Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
taf_321 Опубликовано 5 декабря, 2019 · Жалоба Это больше относится к msd, чем к msd_lite. Демон крашился без корки и воплей в диагностику. Просто молча помирал при достижении некоторой нагрузки в клиентах. Эмпирически выыяснилось, что дело возможно в слишком малом значении backlog. Подняли значение и в настройках msd и системно на порядок, крашиться перестало. По хорошему надо бы этот момент обложить каким-нибудь warning'ом в логи, когда использующиеся ресурсы опасно приближаются к верхнему лимиту. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
taf_321 Опубликовано 6 декабря, 2019 · Жалоба И еще фичреквест для msd: возможность ротации логов, чтобы при получении, к примеру, сигнала -HUP происходила реинициализация заданного в log файла. Либо чтобы логи тупо отправлялись в системный syslog. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
pppoetest Опубликовано 6 декабря, 2019 · Жалоба 4 минуты назад, taf_321 сказал: И еще фичреквест для msd: возможность ротации логов Чем logrotate не угодил? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
taf_321 Опубликовано 6 декабря, 2019 · Жалоба Всем угодил. Только msd про logrotate не рассказали. Он продолжает писать в старый файл с новым именем после переименования. Поясню. Да, можно запилить в postrotate нечто systemctl restart msd. Но это не наш метод, ибо имеет следствием перерыв в вещании. Мысль как раз в том, чтобы сделать это все без перерыва. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
taf_321 Опубликовано 6 декабря, 2019 · Жалоба И еще. При разный непредвиденных непредвиденностях в /dev/shm остаются бесхозные файлы кольцевого буфера msd-PID-HASH.tmp и болтаться им там вплоть до рестарта системы. Было бы очень правильным при запуске msd производить проверку на наличие бесхозных файлов и зачищать их. Сейчас это приходится делать по крону внешними скриптами. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 6 декабря, 2019 · Жалоба 13 часов назад, taf_321 сказал: И еще. При разный непредвиденных непредвиденностях в /dev/shm остаются бесхозные файлы кольцевого буфера msd-PID-HASH.tmp и болтаться им там вплоть до рестарта системы. Было бы очень правильным при запуске msd производить проверку на наличие бесхозных файлов и зачищать их. Если некто запустит несколько копий мсд, то вторая при такой логике поломает работу первой. И это линукс специфично, у фри эти штуки сами удаляются после закрытия последнего дескриптора. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
vop Опубликовано 6 декабря, 2019 · Жалоба 1 hour ago, Ivan_83 said: Если некто запустит несколько копий мсд, то вторая при такой логике поломает работу первой. И это линукс специфично, у фри эти штуки сами удаляются после закрытия последнего дескриптора. Насколько я понимаю, /dev/shm - это тот же /tmp. Отличие только в том, что /tmp может быть как tmpfs в памяти, так и смонтированным на физический диск. /dev/shm должен всегда быть tmpfs. Ну и да, файлы сами не бьются, если, конечно, их не открывать с помощью tmpfile(). Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
taf_321 Опубликовано 7 декабря, 2019 · Жалоба 8 часов назад, Ivan_83 сказал: И это линукс специфично, у фри эти штуки сами удаляются после закрытия последнего дескриптора. Странно как-то. У того же msd_lite буферы пишутся в /tmp, и там поведение как раз как описано - все удаляется само даже при аварийном завершении процесса. А вот у msd, пишущего в /dev/shm при аварийном закрытии файлы остаются. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ipci Опубликовано 4 января, 2020 (изменено) · Жалоба Добрый день, коллеги просим помощи неведомая фигня на большей части устройств все отличное работает, рандомно пропадает сигнал. либо полностью (но редко) нагрузка на сервер небольшая 50-100 клиентов приход на сервер мультикаст, уход - юдп лог msd прикладываю в момент пропадания "всех каналов" - в данном случаем помог полный ребут машины сервер hp dl360 g5 2cpu x 4 core + 16 GB оперативы данный msd_lite используем в связке с CAS IPTVPortal msd.log msd.conf sysctl.conf Изменено 5 января, 2020 пользователем ipci Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
passer Опубликовано 5 января, 2020 (изменено) · Жалоба Поменял сетевушку с Intel 82576 на 82599. После этого отвалы в ЧНН msd_lite несколько участились. В логах есть только: Dec 30 20:05:27 iptv kernel: [451690.364000] msd_lite[3360]: segfault at 0 ip 000000000040784f sp 00007fb6a94c7cf0 error 6 in msd_lite[400000+1f000] Dec 31 18:21:23 iptv kernel: [531846.406000] msd_lite[24949]: segfault at 0 ip 000000000040784f sp 00007fc663554cf0 error 6 in msd_lite[400000+1f000] Dec 31 20:00:39 iptv kernel: [537801.853000] msd_lite[28727]: segfault at 0 ip 000000000040784f sp 00007f3df0725cf0 error 6 in msd_lite[400000+1f000] Dec 31 22:35:36 iptv kernel: [547099.131000] msd_lite[28984]: segfault at 0 ip 000000000040784f sp 00007f57ef957cf0 error 6 in msd_lite[400000+1f000] Jan 2 18:51:20 iptv kernel: [706443.584000] msd_lite[29361]: segfault at 0 ip 000000000040784f sp 00007f48e8697cf0 error 6 in msd_lite[400000+1f000] Jan 3 19:35:24 iptv kernel: [795487.066000] msd_lite[5695]: segfault at 0 ip 000000000040784f sp 00007f8ab7ff8cf0 error 6 in msd_lite[400000+1f000] Jan 4 21:16:17 iptv kernel: [887940.527000] msd_lite[9852]: segfault at 0 ip 000000000040784f sp 00007f7343ccbcf0 error 6 in msd_lite[400000+1f000] Сервер SuperServer 5016I-MTF c X3430 и 8ГБ ОЗУ. Под tmpfs отведено 7ГБ, из них используется 5.5-6 максимум, если верить статистике снятой со stat. В логе msd_lite перед самым отвалом: [2020-01-03 19:35:24] str_hub_create_int, line 510: io_task_notify_create() error 9: Bad file descriptor Что это может быть? msd_lite.conf Изменено 5 января, 2020 пользователем passer Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
taf_321 Опубликовано 5 января, 2020 · Жалоба место на /tmp (именно с msd_lite) случайно не кончилось? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
passer Опубликовано 5 января, 2020 (изменено) · Жалоба Не должно. По графикам в ЧНН потребление памяти 5.7ГБ в этом самом tmpfs. Больше на этом сервере приложений нет и туда писать некому. Самой системе тоже гига должно быть по самое забалуйся. Ну и падения хоть и ЧНН, но в разное время и с разным потоком и количеством юзверей. Была даже мысль память проверить, но не нашел пока замену. Изменено 5 января, 2020 пользователем passer Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
paradox_ Опубликовано 5 января, 2020 · Жалоба ulimit-ты настройте на файловые дескрипторы Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
passer Опубликовано 5 января, 2020 · Жалоба Limits CPU count: 4 IOV maximum: 1024 Max open files: 8192 / 8192 Virtual memory max map: infinity / infinity mlock max size: 65536 / 65536 Data segment max size: infinity / infinity Resident set max size: infinity / infinity Stack segment max size: 8388608 / infinity CPU time max: infinity / infinity File size max: infinity / infinity Core file max size: infinity / infinity Processes max count: 31833 / 31833 Этого мало? Каналов на момент отвала 160+ и зрителей 650+. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
paradox_ Опубликовано 5 января, 2020 · Жалоба 20 минут назад, passer сказал: Max open files: 8192 / 8192 просто смешно а должно быть 1048576 как минимум и коре дамп должно быть и билд с отладочной инфой и стек трейс после падения но это уже все к автору Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ipci Опубликовано 6 января, 2020 · Жалоба On 1/5/2020 at 1:05 AM, ipci said: Добрый день, коллеги просим помощи неведомая фигня на большей части устройств все отличное работает, рандомно пропадает сигнал. либо полностью (но редко) нагрузка на сервер небольшая 50-100 клиентов приход на сервер мультикаст, уход - юдп лог msd прикладываю в момент пропадания "всех каналов" - в данном случаем помог полный ребут машины сервер hp dl360 g5 2cpu x 4 core + 16 GB оперативы данный msd_lite используем в связке с CAS IPTVPortal msd.log msd.conf sysctl.conf коллеги, по моей теме подскажите пожалуйста Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
paradox_ Опубликовано 6 января, 2020 · Жалоба у вас аналогичная ситуация где увеличено количество хендлов ? + видимо еще что то с самой ос, потому что помогло только ребут машины если бы проблема была в софте то его рестарт помог бы Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
passer Опубликовано 6 января, 2020 (изменено) · Жалоба Вообче-то эти 8 тысяч по дефолту в конфиге. В системе оказалось вообще 4тыс. Поднял предел, наблюдаю. P.S. Честно говоря не представляю, нафига миллион на таком сервере. Изменено 6 января, 2020 пользователем passer Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
paradox_ Опубликовано 6 января, 2020 · Жалоба что бы не заниматься поиском проблем там где их быть не должно у вас там началось с брокен пайп - фигня какая то с дескрипторами, lsof хотя бы надо было изучать или еще надо смотреть где какие лимиты могут быть дальше вы рестартонули демон но tmp видимо не почистили поэтому только ребут который почистил tmp - помог Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 11 января, 2020 · Жалоба В 05.01.2020 в 01:05, ipci сказал: приход на сервер мультикаст, уход - юдп Может всё же тцп+хттп на выходе то?) [2020-01-05 00:46:01]: descriptor table size: 1024 (max files) - маловато! В 06.01.2020 в 21:02, passer сказал: Вообче-то эти 8 тысяч по дефолту в конфиге. В системе оказалось вообще 4тыс. Поднял предел, наблюдаю. Я во время разработки не оттестил всё это на предмет нехватки дескрипторов, обычно ставлю 256к и не парюсь. Падения из за этого стал замечать в жалобах тут уже сильно после, сейчас нет времени копаться и фиксить. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ipci Опубликовано 11 января, 2020 · Жалоба 6 hours ago, Ivan_83 said: Может всё же тцп+хттп на выходе то?) [2020-01-05 00:46:01]: descriptor table size: 1024 (max files) - маловато! root@debian:~# cat /proc/sys/fs/file-max 1637394 root@debian:~# ulimit -Hn 1048576 root@debian:~# ulimit -Sn 1024 root@debian:~# ulimit -n 1024 какой параметр поменять? и на какую величину? а так выдает root@debian:~# ulimit -H -a core file size (blocks, -c) unlimited data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 64110 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1048576 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) unlimited cpu time (seconds, -t) unlimited max user processes (-u) 64110 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
ipci Опубликовано 11 января, 2020 · Жалоба так же наблюдаем проблему с переодическим отваливанием 1 клиента, просто прекращает идти поток, клиент 10.200.7.140. лечится пингом с сервера до клиента [2020-01-11 10:26:22]: /udp/224.0.90.248:1234@ens2f1: Destroyed. [2020-01-11 10:26:28] http_srv_recv_done_cb, line 924: error 110: Connection timed out client ip: 10.200.7.140:41443 [2020-01-11 10:26:38] http_srv_recv_done_cb, line 924: error 110: Connection timed out client ip: 10.200.7.140:41458 [2020-01-11 10:28:41] str_hub_send_to_clients, line 845: error 110: Connection timed out /udp/224.0.20.12:1234@ens2f1 - 10.200.1.111:35307: disconnected. [2020-01-11 10:28:41]: /udp/224.0.20.12:1234@ens2f1 - 10.200.1.111:35307: deattached, cli_count = 1 [2020-01-11 10:29:28]: /udp/224.0.90.210:1234@ens2f1: Created. (fd: 75) [2020-01-11 10:29:28]: /udp/224.0.90.210:1234@ens2f1 - 10.200.6.166:53820: attached, cli_count = 1 [2020-01-11 10:29:46]: /udp/224.0.20.11:1234@ens2f1 - 10.200.7.140:41882: attached, cli_count = 4 [2020-01-11 10:30:00] str_hub_send_to_clients, line 845: error 32: Broken pipe /udp/224.0.20.11:1234@ens2f1 - 10.200.7.140:41882: disconnected. [2020-01-11 10:30:00]: /udp/224.0.20.11:1234@ens2f1 - 10.200.7.140:41882: deattached, cli_count = 3 [2020-01-11 10:30:00]: /udp/224.0.20.12:1234@ens2f1 - 10.200.7.140:41905: attached, cli_count = 2 [2020-01-11 10:30:07]: /udp/224.0.20.11:1234@ens2f1 - 10.200.7.140:41919: attached, cli_count = 4 [2020-01-11 10:30:07] str_hub_send_to_clients, line 845: error 32: Broken pipe /udp/224.0.20.12:1234@ens2f1 - 10.200.7.140:41905: disconnected. [2020-01-11 10:30:07]: /udp/224.0.20.12:1234@ens2f1 - 10.200.7.140:41905: deattached, cli_count = 1 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
paradox_ Опубликовано 11 января, 2020 · Жалоба 3 часа назад, ipci сказал: root@debian:~# ulimit -n 1024 а должно быть 1048576 что бы не заниматься тратой времени на исследования Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...