firebird-classic.socket: Too many incoming connections (64).Firebird-classic-2.5.2.26539 fedora 19.

[Никита Фоминский]

Помогите!!!

Firebird-classic-2.5.2.26539  fedora 19.

 systemd[1]: firebird-classic.socket: Too many incoming connections (64)

Установлен сервер firebird, который используется приложением. Не получается сделать больше 64 коннектов и при достижении такого лимита systemd выдает соотв. сообщение. Куда копать? Где изменить количество коннектов? Это ограничение подключений на порт 3050 или дело в настройках firebird? Может дело в ядре?

Заранее спасибо!

[Sergey Mereutsa]

Привет!

У себя супердемон (xinetd или inetd) по умолчанию не позволяет
открывать больше 60 с хвостиком подключений. К Птицу это отношения не
имеет.

Вот конфиг моего супердемона для одного из сайтов:

cat /etc/xinetd.d/firebird25
# default: off
# description: FirebirdSQL classic server, v2.5
#
# firebird2.5-classic uses /etc/inetd.conf by default
# If you choose to enable this service, remember to disable the one provided by
# inetd. The easiest way for this is:
# update-inetd --disable gds_db
#
service gds_db
{
disable = no
flags = REUSE NODELAY
socket_type = stream
wait = no
user = firebird
# These lines cause problems with Windows XP SP2 clients
# using default firewall configuration (SF#1065511)
# log_on_success += USERID
# log_on_failure += USERID
server = /usr/sbin/fb_inet_server
instances = 120
cps = 3000 60
}

Тебе интересны
instances = 120
cps = 3000 60
- т.е. количество активных процессов и количество запросов в секунду.

Имей ввиду - процессов/ядер и памяти для классика требуется много.

--
Best regards,
Sergey mailto:gebe...@gmail.com

[Никита Фоминский]

А может быть такое, что сейчас fb запускается через systemd. Почему задаю такой вопрос, потому что при изменении конфига в /etc/xinetd/firebird и перезапуске xinetd всё остаётся так же. Куда дальше копать?

[Sergey Mereutsa]

Привет!

Значит, надо смотреть настройки этого systemd - сам-по себе классик ни при
чём, он открывает по сокету (или два) на процесс. А вот тот, кто его
порождает и имеет какие-то ограничения на порождение процессов, по-видимому
- это надо логи системные смотреть, по фотографии диагноз поставить трудно.
Ещё может быть система аудита какая-нибудь, которая по умолчанию не
позволяет процессам жрать много ресурсов - проблем может быть куча и с
вероятностью 99.999% они к Птицу отношения не имеют.

Ку 2 раза.

[Никита Фоминский]

Спасибо за помощь. Разобрался во всём. Проблема решена.

[Sergey Mereutsa]

Привет!

Ну так напиши, где собака порылась - пусть ляжет в копилку знаний,
авось кому и пригодится :)

Wednesday, December 4, 2013, 11:05:46 AM, you wrote:

> Спасибо за помощь. Разобрался во всём. Проблема решена.

[Никита Фоминский]

Да особо ничего нового я никому не расскажу. В общем:

Т.к. я использую classic, то запускался он у меня как сокет, т.е. firebird-classic.socket. Прописан был в systemd. Системный демон ограничивал кол-во подключений в 64.

Я сделал systemctl disable firebird-classic.socket. Отключил запуск Птица через systemd.
И сделал настройки через xinetd.

В /etc/xinetd/firebird прописаны настройки запуска Птица.
Далее systemctl start xinetd.service
          systemctl enable xinetd.service

И всё.


среда, 4 декабря 2013 г., 13:26:32 UTC+4 пользователь Sergey Mereutsa написал:

[NikolayV81]

в общем можно было по другому, т.к. всё равно используется systemd:

из мануала systemd.socket

"MaxConnections=

The maximum number of connections to simultaneously run services instances for, when Accept=true is set. If more concurrent connections are coming in, they will be refused until at least one existing connection is terminated. This setting has no effect on sockets configured with Accept=false or datagram sockets. Defaults to 64."

http://www.freedesktop.org/software/systemd/man/systemd.socket.html

т.е. нужно было установить нужное количество в  firebird-classic.socket. в принципе возможности xnetd firebird-у не особо нужны.

среда, 4 декабря 2013 г., 16:47:30 UTC+4 пользователь Никита Фоминский написал:

[Никита Фоминский]

 То есть в данном случае быстрее и лучше будет использовать systemd напрямую? Минуя xinetd?

[Sergey Mereutsa]

Привет!

Не знаю, быстрее и лучше ли будет. Скорее всего - вопрос удобства.

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

В тройке уже маячит нормальный паралеллящийся суперсервер, так что
классик со временем, по-моему, перестанет быть востребованным. Хотя в
той же тройке сервер умеет прикидываться кем угодно.

Wednesday, December 4, 2013, 3:57:11 PM, you wrote:

> То есть в данном случае быстрее и лучше будет использовать systemd
> напрямую? Минуя xinetd?

[Николай Теселько]

xinetd имеет кучу дополнительного функционала, там вроде даже что-то похожее на firewall встроено ( но есть вероятность что вы даже не замените той возможной разницы), просто у меня есть мнение, что если что-то реализовано в базовой поставке системы, и эта реализация не намного хуже, то лучше пользоваться ей.

4 декабря 2013 г., 17:57 пользователь Никита Фоминский <nikse...@gmail.com> написал:

 То есть в данном случае быстрее и лучше будет использовать systemd напрямую? Минуя xinetd?

--
 
---
Вы получили это сообщение, поскольку подписаны на группу gmane.comp.db.firebird.russian.
 
Чтобы отказаться от подписки на эту группу и перестать получать из нее сообщения, отправьте электронное письмо на адрес ru-firebird...@googlegroups.com.
Настройки подписки и доставки писем: https://groups.google.com/groups/opt_out.

[Николай Теселько]

У нас работает 2.5 super-classic вроде как именно то что нужно.

4 декабря 2013 г., 18:14 пользователь Sergey Mereutsa <gebe...@gmail.com> написал:

[Никита Фоминский]

Ну что касается удобства...потестил подключение через systemd и xinetd. При использовании xinetd начались жалобы о скорости подключения к базе. Коннект затягивался от минуты и больше...Поэтому поправил MaxConnections в systemd и сейчас наслаждаюсь процессом. По логике, возможно есть какие то преимущества в использовании xinetd, но стоит задуматься о том, что его же запускает systemd, то есть цепочка чуть длиннее systemd-xinetd-firebird вместо systemd-firebird.