forum.lissyara.su

Добрый вечер.
Потратил пару дней на решение следующей проблемы.
Пишу на плюсах под фри. Много потоков, синхронизация осуществляется через семафоры.
Дошло до того, что программа перестала работать, по причине too many open files
почитал хэнд бук, амеровские форумы, все сходятся во мнение kern.maxfiles, kern.maxfilespreproc
переменные для этих параметров ставлю на горячую через sysctl по 65536, или через /boot/loader.conf
не помогает.
так же есть kern.openfiles который в read only, и не ставится не в loader.conf не в sysctl.conf вероятно потому что
она отображает количество открытых файлов, но не устанавливает лимиты.
..ну вот. нужна помощь. спасибо.

http://forum.lissyara.su/viewtopic.php?f=3&t=5280
курить всю тему

/etc/login.conf
man login.conf

Alex Keda писал(а):http://forum.lissyara.su/viewtopic.php?f=3&t=5280
курить всю тему

аха, Лис, спасиб за отзывчивость.
я по errno уже понял что дескрипторы)) и могу добавить ко вчерашнему кроме maxfiles и т.п. есть семафорные переменные...
вот они:

kern.ipc.semmni=10
kern.ipc.semmns=60
kern.ipc.semmnu=30
kern.ipc.semmap=30

kern.ipc.semaem=16384
kern.ipc.semvmx=32767
kern.ipc.semusz=136
kern.ipc.semume=10
kern.ipc.semopm=100
kern.ipc.semmsl=60

и методом тыка буду пробовать. дебагер говорит мне что на процесс больше 26 семафором не получается, но нативные семафоры инкапсулированы в мои классы-обертки.. т.ч. не больше 26 экземпляров моих_семафоров..
если процесс ещё 4ре где-то себе забирает, ну т.е. не моим кодом, а уровнем ядра, тогда всё сходиться(но не слышал что такое бывает). хз, надо тестить.

кроме того, код залип, смотрю kern.openfiles ну например 156, выключаю свой код, выключаю БД, ещё всякую ерунду, смотрю kern.openfiles 102, запускаю свой код, опять залипалово c семафорами "too many open files", errno=23, но! kern.openfiles=128
т.е. семафоры косячат =(

з.ы. семафоры буста совсем косяк. ну и я даже не знаю, во фри очереди сообщений ещё есть, через них мне кажется можно диспетчеризацию сделать, но это ваще бль, мясо(((

Проходил мимо писал(а):/etc/login.conf
man login.conf

аха, спасибо. нашел) попробую тоже.

kT___ писал(а):

Alex Keda писал(а):http://forum.lissyara.su/viewtopic.php?f=3&t=5280
курить всю тему

аха, Лис, спасиб за отзывчивость.
я по errno уже понял что дескрипторы)) и могу добавить ко вчерашнему кроме maxfiles и т.п. есть семафорные переменные...
вот они:

kern.ipc.semmni=10
kern.ipc.semmns=60
kern.ipc.semmnu=30
kern.ipc.semmap=30

kern.ipc.semaem=16384
kern.ipc.semvmx=32767
kern.ipc.semusz=136
kern.ipc.semume=10
kern.ipc.semopm=100
kern.ipc.semmsl=60

и методом тыка буду пробовать. дебагер говорит мне что на процесс больше 26 семафором не получается, но нативные семафоры инкапсулированы в мои классы-обертки.. т.ч. не больше 26 экземпляров моих_семафоров..
если процесс ещё 4ре где-то себе забирает, ну т.е. не моим кодом, а уровнем ядра, тогда всё сходиться(но не слышал что такое бывает). хз, надо тестить.

кроме того, код залип, смотрю kern.openfiles ну например 156, выключаю свой код, выключаю БД, ещё всякую ерунду, смотрю kern.openfiles 102, запускаю свой код, опять залипалово c семафорами "too many open files", errno=23, но! kern.openfiles=128
т.е. семафоры косячат =(

з.ы. семафоры буста совсем косяк. ну и я даже не знаю, во фри очереди сообщений ещё есть, через них мне кажется можно диспетчеризацию сделать, но это ваще бль, мясо(((

так.. 26 семафоров.. +ввод, вывод, err, сокет телнета.. и того 30

kT___ писал(а):

Проходил мимо писал(а):/etc/login.conf
man login.conf

аха, спасибо. нашел) попробую тоже.

default:\
:openfiles=unlimited:\

прекрасно бль...
делаю тогда так:
sysctl -a | grep 30

kern.ipc.semmnu
kern.ipc.semmap
kern.ipc.numopensockets
p1003_1b.sem_nsems_max
p1003_1b.nsems

дооооо... тут есть что методом тыка зачекать, учитывая что они все реад-онли, и на горячую не поменять((

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

теперь нормально до 30

а кто нить знает как раскачать, то что возвращает sysctl c ключом p1003_1b.sem_nsems_max, который = 30

т.к. этот ключик лишь возвращает значение переменной, но не задаёт лимит

очередной раз sysctl -a | grep 30

и кроме
p1003_1b.sem_nsems_max=30
p1003_1b.nsems=30
которые, повторюсь, отображаю лимит, но не устанавливают его
есть вот такие..

kern.sched.interact=30
kern.filedelay=30
vfs.nfs.downdelayinterval=30
net.inet.ip.gitttl=30
ещё пять ключей
net.inet.************=30
hw.ath.calibrate=30

ничего =(

а.. ну ещё
p1003_1b.sem_nsems_max=0
до запуска программы. и модуль ядра, который про семафоры, я подгружаю в run-time, как думаете, это критично, если параметры для семафоров задаю в /boot/loader.conf?
думаю нет.. т.к. параметры всё равно остаются неизменными после загрузки модуля, но это наводит на мысль что
p1003_1b.sem_nsems_max становится равен 30 после загрузки модуля, и вероятно именно модуль тянет этот лимит

kT___ писал(а):а.. ну ещё
p1003_1b.sem_nsems_max=0
до запуска программы. и модуль ядра, который про семафоры, я подгружаю в run-time, как думаете, это критично, если параметры для семафоров задаю в /boot/loader.conf?
думаю нет.. т.к. параметры всё равно остаются неизменными после загрузки модуля, но это наводит на мысль что
p1003_1b.sem_nsems_max становится равен 30 после загрузки модуля, и вероятно именно модуль тянет этот лимит

ещё интересней, бль..

"sysctl p1003_1b.sem_nsems_max" gives the maximum number of POSIX semaphores (per process? system wide?).

Since FreeBSD 8.1, "sudo sysctl -w p1003_1b.sem_nsems_max=256" can be used to change this limit at runtime.

Before FreeBSD 8.1, SEM_MAX constant should be changed in the kernel source code, and the kernel have to be recompiled. (p1003_1b.sem_nsems_max is not configurable in /etc/sysctl.conf, it is an hardcoded limit).

Before FreeBSD 8.0, the POSIX semaphores are disabled by default: the kernel have to be compiled using P1003_1B_SEMAPHORES option. Extract of sys/conf/NOTES:

#####################################################################
# POSIX P1003.1B

# Real time extensions added in the 1993 POSIX
# _KPOSIX_PRIORITY_SCHEDULING: Build in _POSIX_PRIORITY_SCHEDULING

options _KPOSIX_PRIORITY_SCHEDULING
# p1003_1b_semaphores are very experimental,
# user should be ready to assist in debugging if problems arise.
options P1003_1B_SEMAPHORES

# POSIX message queue
options P1003_1B_MQUEUE

#####################################################################

всё понятно бль. закрывайте тред. я в печали.

тем временем, пока качается релиз 9й фряхи.. продолжаю раскачивать количество семафоров.
добавил пару выше указанных опций в ядро, пересобрал, и не понимаю зачем..
что бы в ран-тайме не писать kldload sem ..супер.

код ядра.

uipc_sem.c
#define SEM_MAX 30
переопределил 30000

а вот интересно, они от куда лимит в 30 взяли??
про дарвин пишут что там 100 000.. яблочные мажоры

ща, ещё разочек перекомпилю ядро.. или успеет 9ка закачаться.


..и у меня теперь новый вопрос. а скажите плиз.. этот тред висит в ветке Фри для начинающих, это я так понимаю ещё мелочи?
и в перспективе писать код ядра оптом?
вох*ение \мрачно

какбе проблема описанная в начале треда - она в форуме прожёвана не раз.
поэтому и сюда попало.

ну а раз оно у вас глубже оказалось - щас передвину куданить )

вы отпишитесь чем оно кончится.
полезные треды такие, монологовые
частенько поиском на такое набредаешь, и ответы находишь.
если автор отписался,а не забил )

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

курите маны

manefesto# sysctl -a | grep maxfiles
kern.maxfiles: 12328
kern.maxfilesperproc: 11095

У автора топика кончались семафоры.

SEM_MAX в коде ядра привязан должен рулится через