Перейти к содержимому
Калькуляторы

msd Lite - тестируем Замена udpxy если у кого оно ещё осталось

@crank А сервер какой конфигурации у Вас?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

3 часа назад, Sacrament сказал:

@crank А сервер какой конфигурации у Вас?

HP DL160 G6

CPU: 2 x Intel(R)  Xeon(R)  CPU  E5520  @  2.27GHz
RAM: 16GB

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Это больше относится к msd, чем к msd_lite. Демон крашился без корки и воплей в диагностику. Просто молча помирал при достижении некоторой нагрузки в клиентах. Эмпирически выыяснилось, что дело возможно в слишком малом значении backlog. Подняли значение и в настройках msd и системно на порядок, крашиться перестало. По хорошему надо бы этот момент обложить каким-нибудь warning'ом в логи, когда использующиеся ресурсы опасно приближаются к верхнему лимиту.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

И еще фичреквест для msd: возможность ротации логов, чтобы при получении, к примеру, сигнала -HUP происходила реинициализация заданного в log файла. Либо чтобы логи тупо отправлялись в системный syslog.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

4 минуты назад, taf_321 сказал:

И еще фичреквест для msd: возможность ротации логов

Чем logrotate не угодил?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Всем угодил. Только msd про logrotate не рассказали. Он продолжает писать в старый файл с новым именем после переименования.

 

Поясню. Да, можно запилить в postrotate нечто systemctl restart msd. Но это не наш метод, ибо имеет следствием перерыв в вещании. Мысль как раз в том, чтобы сделать это все без перерыва.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

И еще. При разный непредвиденных непредвиденностях в /dev/shm остаются бесхозные файлы кольцевого буфера msd-PID-HASH.tmp и болтаться им там вплоть до рестарта системы. Было бы очень правильным при запуске msd производить проверку на наличие бесхозных файлов и зачищать их. Сейчас это приходится делать по крону внешними скриптами.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

13 часов назад, taf_321 сказал:

И еще. При разный непредвиденных непредвиденностях в /dev/shm остаются бесхозные файлы кольцевого буфера msd-PID-HASH.tmp и болтаться им там вплоть до рестарта системы. Было бы очень правильным при запуске msd производить проверку на наличие бесхозных файлов и зачищать их.

Если некто запустит несколько копий мсд, то вторая при такой логике поломает работу первой.

И это линукс специфично, у фри эти штуки сами удаляются после закрытия последнего дескриптора.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

1 hour ago, Ivan_83 said:

Если некто запустит несколько копий мсд, то вторая при такой логике поломает работу первой.

И это линукс специфично, у фри эти штуки сами удаляются после закрытия последнего дескриптора.

Насколько я понимаю, /dev/shm - это тот  же /tmp. Отличие только в том, что /tmp может быть как tmpfs в памяти, так и смонтированным на физический диск. /dev/shm должен всегда быть tmpfs.

 

Ну и да, файлы сами не бьются, если, конечно, их не открывать с помощью tmpfile().

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

8 часов назад, Ivan_83 сказал:

И это линукс специфично, у фри эти штуки сами удаляются после закрытия последнего дескриптора.

Странно как-то. У того же msd_lite буферы пишутся в /tmp, и там поведение как раз как описано - все удаляется само даже при аварийном завершении процесса. А вот у msd, пишущего в /dev/shm при аварийном закрытии файлы остаются.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Добрый день, коллеги

просим помощи

неведомая фигня

на большей части устройств все отличное работает, рандомно пропадает сигнал. либо полностью (но редко)

 

нагрузка на сервер небольшая 50-100 клиентов

 

приход на сервер мультикаст, уход - юдп

 

лог msd прикладываю в момент пропадания "всех каналов" - в данном случаем помог полный ребут машины

 

сервер hp dl360 g5 2cpu x 4 core + 16 GB оперативы

 

данный msd_lite используем в связке с CAS IPTVPortal

msd.log

msd.conf

sysctl.conf

Изменено пользователем ipci

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Поменял сетевушку с 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

Изменено пользователем passer

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Не должно. По графикам в ЧНН потребление памяти 5.7ГБ в этом самом tmpfs. Больше на этом сервере приложений нет и туда писать некому. Самой системе тоже гига должно быть по самое забалуйся. Ну и падения хоть и ЧНН, но в разное время и с разным потоком и количеством юзверей. Была даже мысль память проверить, но не нашел пока замену.

Изменено пользователем passer

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

ulimit-ты настройте на файловые дескрипторы

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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+.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

20 минут назад, passer сказал:

Max open files: 8192 / 8192

просто смешно

а должно быть 1048576 как минимум

 

и коре дамп должно быть

и билд с отладочной инфой

и стек трейс после падения

но это уже все к автору

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

коллеги, по моей теме подскажите пожалуйста

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

у вас аналогичная ситуация

где увеличено количество хендлов ?

+  видимо еще что то с самой ос, потому что помогло только ребут машины

если бы проблема была в софте то его рестарт помог бы

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вообче-то эти 8 тысяч по дефолту в конфиге. В системе оказалось вообще 4тыс. Поднял предел, наблюдаю.

 

P.S. Честно говоря не представляю, нафига миллион на таком сервере.

Изменено пользователем passer

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

что бы не заниматься поиском проблем там где их быть не должно

у вас там началось с брокен пайп - фигня какая то с дескрипторами, lsof хотя бы надо было изучать

или еще надо смотреть где какие лимиты могут быть

дальше вы рестартонули демон но tmp видимо не почистили

поэтому только ребут который почистил tmp - помог

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В 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к и не парюсь.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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
 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

так же наблюдаем проблему с переодическим отваливанием 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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

3 часа назад, ipci сказал:

root@debian:~# ulimit -n
1024

а должно быть 1048576

что бы не заниматься тратой времени на исследования

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.