Jump to content
Калькуляторы

FreeBSD 10.0 MPD5.7 umtxn Клинит...

FreeBSD gw01.comteks.biz 10.0-STABLE FreeBSD 10.0-STABLE #0 r264634: Fri Apr 18 05:54:56 MSK 2014     hawk@gw01.comteks.biz:/usr/obj/usr/src/sys/GENERIC  amd64

 

Замена - в смысле железо, свежий как раз пришел, туда и переполз.

Share this post


Link to post
Share on other sites

К сожалению, проблема ни куда не делась.

Просто при смене сервера немного отползла...

Итого, опять МПД впадает точно так же в ступор. Вроде при уничтожении очередного ngX интерфейса после отключения пользователя.

 

Есть подозрения, что плохо дружат с BGP FV. Колбасят друг друга.

Пока что вынес только МПД и ОСПФ на отдельную машину, пока что работает.

 

Клиентов крохи, менее 200 подключений.

 

Есть у кого-нибудь идеи?

Share this post


Link to post
Share on other sites

Есть у кого-нибудь идеи?

Что только не пробовал, но овер 250 соединений связь с мпд пропадала, так как решить надо было быстро вопрос, то откатился на 9.

А по теме вот:

http://sourceforge.net/p/mpd/discussion/44692/thread/e446b64d/'>http://sourceforge.net/p/mpd/discussion/44692/thread/e446b64d/

сам не пробовал ибо уже откатился, но попробовать стоит, что-то там связанное с логами.

 

И по проблеме советую написать пост тут всё же: http://sourceforge.net/p/mpd/discussion/44692/

Это проблема mpd всё же.

Edited by polmax

Share this post


Link to post
Share on other sites

Не мой случай, т.к. радиус нормально и всегда отвечает.

 

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

Edited by Hawk128

Share this post


Link to post
Share on other sites

Я откатился на 9,2 проблема решилась. Видимо не все гладко у десятки с нетграфом.

Share this post


Link to post
Share on other sites

В 10-ке изменили работу в интерфейсами внутри как-то.

Теперь при создании и удалении идет информация дополнительная в сислог.

Вот на удалении проблема и вылезает в каких-то случаях неясных...

Share this post


Link to post
Share on other sites

В 10-ке devd запускает скрипты при up/down. Пробовали его вообще отключать?

Share this post


Link to post
Share on other sites

Нет, не пробовал.

Просто отключить? Не на что не влияет он?

Share this post


Link to post
Share on other sites

Просто отключить? Не на что не влияет он?

 

Да он особо на роутере ничем не нужен. Вряд ли вы постоянно вставляете pccard-девайсы да усб-свистки. Список правил в /etc/devd.conf гляньте, решите нужно оно вам вообще на роутере или нет. Многие отключают, потому что он околобесполезен.

Share this post


Link to post
Share on other sites

Пробуйте как временную меру в loader.conf:

net.graph.maxdata=2048

Share this post


Link to post
Share on other sites

Пробовал. И больше вроде ставил.

 

Сейчас проверить не могу, вынес МПД на отдельный сервак, на 10-ке - глюков нет.

Как появятся - буду пробовать.

Share this post


Link to post
Share on other sites

Собственно, что помогло в решении проблемы и помогло ли?

Share this post


Link to post
Share on other sites

MPD сейчас крутиться на отдельном серваке и пока проблем нет. Скорее всего просто отсрочка, т.к. сервак много мощнее чем надо.

 

Надеюсь к моменту возникновения проблем уже подправят систему...

Share this post


Link to post
Share on other sites

А систему туда эту же перенесли, или заново ставили\собирали? Патчили ли ng_pptpgre на предмет решения вопроса переупорядочивания пакетов? Можете показать netstat -LAan с этой машины? Интересуют очереди у мпд.

Share this post


Link to post
Share on other sites

Систему просто клонировал, без изменений.

 

Сейчас уже смысла нагрузку показывать нет, там значительная часть абонентов на еще один сервер перебралась по другим причинам. Т.е. сейчас там смех, а не нагрузка.

 

ng_pptpgre не патчил.

Share this post


Link to post
Share on other sites

..Просто интересно, что после старта 5.7 на 10-stable у меня на ip.5006 1024 очереди, когда на ip.5006 8.4-stable\5.6 128. Да и с нагрузкой не очень-то коррелирует

Edited by Sincha

Share this post


Link to post
Share on other sites

А пробовал кто в src.conf писать:

WITHOUT_UTMPX

Set to not build user accounting tools such as last(1), users(1),

who(1), ac(8), lastlogin(8) and utx(8).

и пересобирать систему и порты?

Share this post


Link to post
Share on other sites

Не пробовал. Расскажите, почему Вы считаете, что это может помочь?

Share this post


Link to post
Share on other sites

Возможно это вообще выпилит utmpx из системы и устранит проблему.

Share this post


Link to post
Share on other sites

Пересобрал\стартанул\впустил клиентов. Посмотрим.

Share this post


Link to post
Share on other sites

что-то поламали в 10.1-beta2 или что-то у меня с машиной: постоянные ребуты, не крэша, не логов, ничего. На консоль нечего подключить, что бы увидеть. Корреляции с нагрузкой нет вообще.

Share this post


Link to post
Share on other sites

Собственно: kern.ipc.somaxconn переименовали в kern.ipc.soacceptqueue.

 

grep -R "UTMPX" /usr/src/

показывает не так уж много где оно используется

/usr/src/lib/libpam/modules/pam_lastlog/pam_lastlog.c

/usr/src/usr.bin/getent/getent.c

/usr/src/kerberos5/

/usr/src/crypto/heimdal/

/usr/src/contrib/opie/libopie/

/usr/src/contrib/ntp/libntp/

 

 

"Listen queue overflow" - неминуемый при продолжительном времени может означать только одно: неправильный алгоритм приёма соединений.

Кажется я тоже наступал на эти грабли.

Обычно:

пришло соединение - сгенерировали эвент - приняли соединение

Иногда:

прошло несколько соединений - сгенерировали эвент - приняли ОДНО соединение.

 

Можно попробовать проптчить файл pptp_ctrl.c

функция PptpCtrlListenEvent

превращается в

static void
PptpCtrlListenEvent(int type, void *cookie)
{
PptpLis const		l = (PptpLis)cookie;
 struct sockaddr_storage	peerst, selfst;
 struct u_addr			peer_addr, self_addr;
 in_port_t			peer_port, self_port;
 char				ebuf[64];
 PptpCtrl			c;
 int				sock;
 char				buf[48], buf2[48];
 socklen_t			addrLen;

/* Accept connection */
while ((sock = TcpAcceptConnection(l->sock, &peerst, FALSE)) >= 0) {
	sockaddrtou_addr(&peerst,&peer_addr,&peer_port);

	/* Get local IP address */
	addrLen = sizeof(selfst);
	if (getsockname(sock, (struct sockaddr *) &selfst, &addrLen) < 0) {
	Perror("PPTP: %s getsockname()", __func__);
	u_addrclear(&self_addr);
	self_port = 0;
	} else {
	sockaddrtou_addr(&selfst, &self_addr, &self_port);
	}
	Log(LG_PHYS2, ("PPTP: Incoming control connection from %s %u to %s %u",
	u_addrtoa(&peer_addr, buf, sizeof(buf)), peer_port,
	u_addrtoa(&self_addr, buf2, sizeof(buf2)), self_port));

	/* Initialize a new control block */
	if ((c = PptpCtrlGetCtrl(FALSE, &self_addr, &peer_addr, peer_port,
		ebuf, sizeof(ebuf))) == NULL) {
	Log(LG_PHYS2, ("PPTP: Control connection failed: %s", ebuf));
	close(sock);
	continue;
	}
	c->csock = sock;

	/* Initialize the session */
	PptpCtrlInitCtrl(c, FALSE);
}
}

 

Аналогично и pppoe.c

PppoeListenEvent

 

switch (sz = NgRecvData(PIf->dsock, response, sizeof(response), rhook)) {

case -1:

Log(LG_ERR, ("NgRecvData: %d", sz));

return;

case 0:

Log(LG_ERR, ("NgRecvData: socket closed"));

return;

}

 

Превращается в

while (0 != (sz = NgRecvData(PIf->dsock, response, sizeof(response), rhook))) {

if (-1 == sz) {

Log(LG_ERR, ("NgRecvData: %d", sz));

return;

}

... (не забываем } снизу добавить и заменить return на continue)

 

Ещё вариантом сделать глюк реже будет задрать приоритет mpd5 до -20.

Share this post


Link to post
Share on other sites

Кстати, Listen queue overflow только сейчас попадает в месаджи, раньше он просто не попадал, но был виден в нетстате

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this