Страница 1 из 1

Странное поведение FreeBSD8.2

Добавлено: 2013-07-08 9:44:52
bRUtality
Всем доброго времени!
Имеется сервер под FreeBSD 8.2 (почти из коробки), установлена на ней только база данных PostgreSQL.
Время от времени сервер падает. Выглядит это так: не отвечает по удаленке по sshd, но пингуется. К базе тоже в этот момент не достучаться.
Самое интересное, что в этот момент идет какая-то активность от сетевой карты, которая фиксируется Циской:

Код: Выделить всё

.Jul  8 08:25:32.774 MSD: %C4K_HWPORTMAN-4-BLOCKEDTXQUEUE: Blocked transmit queue HwTxQId1 on Switch Phyport Gi3/21, count=21224
.Jul  8 08:25:32.774 MSD: %C4K_HWPORTMAN-4-BLOCKEDTXQUEUE: Blocked transmit queue HwTxQId3 on Switch Phyport Gi3/21, count=21226
Админы в этот момент ругаются и грозятся закрыть порт пожизненно.
Приходится спускаться в серверную и делать ему резет.
Подскажите, с чего начать, какие логи смотреть?

Re: Странное поведение FreeBSD8.2

Добавлено: 2013-07-08 10:19:46
bRUtality
В messages нашел такую строчку (много раз):

Код: Выделить всё

Approaching the limit on PV entries, consider increasing either the vm.pmap.shpgperproc or the vm.pmap.pv_entry_max sysctl.
потом (один раз)

Код: Выделить всё

swap zone exhauted, increase kern.maxswzone
после чего тишина вплоть до резета :evil:
Значения упомянутых выше параметров:

Код: Выделить всё

# sysctl vm.pmap.pv_entry_max
vm.pmap.pv_entry_max: 13426443
# sysctl vm.pmap.shpgperproc
vm.pmap.shpgperproc: 200

Re: Странное поведение FreeBSD8.2

Добавлено: 2013-07-09 8:50:49
vadim64
если кроме pgqsl ничего нету, следует задампить базы, поставить по новой всё и залить дамп на новую систему
соотношение времени на локализацию проблемы и её решение против установки и разворачивания одного сервиса, в данном случае, явно не в пользу диагностики проблемы

Re: Странное поведение FreeBSD8.2

Добавлено: 2013-07-09 8:57:41
bRUtality
Рассматриваю такой вариант как крайний, т.к. база масштабирована вертикально по самый не балуй и фряха малость подкручена в соответствии, объем данных не маленький.
А самое главное, база "живая" - ей пользуется наш колл-центр. Не просто будет всех уговорить, что серверу требуется обновление :)

Re: Странное поведение FreeBSD8.2

Добавлено: 2013-07-09 9:31:20
vadim64
ну если бизнес-процесс исключает возможность обновления сервера, тогда даже не знаю, что Вам можно посоветовать

Re: Странное поведение FreeBSD8.2

Добавлено: 2013-07-09 9:45:50
bRUtality
vadim64 писал(а):даже не знаю, что Вам можно посоветовать
Посоветуйте, где посмотреть логи активности сетевой карты :) Интересно, что за пакеты она шлет и почему.

Re: Странное поведение FreeBSD8.2

Добавлено: 2013-07-09 9:57:33
vadim64

Код: Выделить всё

tcpdump -i <iface>

Re: Странное поведение FreeBSD8.2

Добавлено: 2013-07-09 10:33:00
snorlov
Поиск говорит, что надо увеличить

Код: Выделить всё

kern.maxswzone=
По умолчанию наверное стоит в 33554432, наверное надо увеличить вдвое или втрое...

Re: Странное поведение FreeBSD8.2

Добавлено: 2013-07-09 10:43:31
bRUtality
vadim64 писал(а):

Код: Выделить всё

tcpdump -i <iface>
спасибо!

Re: Странное поведение FreeBSD8.2

Добавлено: 2013-07-09 10:47:40
bRUtality
snorlov писал(а):Поиск говорит, что надо увеличить

Код: Выделить всё

kern.maxswzone=
По умолчанию наверное стоит в 33554432, наверное надо увеличить вдвое или втрое...
Есть ли какие рекомендации по зависимости этого параметра от других? Дело в том, что в sysctl у меня

Код: Выделить всё

kern.ipc.shmall=10485760
kern.ipc.shmmax=42949672961
(увеличены в разы)

Re: Странное поведение FreeBSD8.2

Добавлено: 2013-07-12 9:39:47
bRUtality
Что-то не пойму, куда память утекает. В loader.conf выставил

Код: Выделить всё

kern.ipc.semmns = 32000
kern.ipc.semmni = 128
kern.maxswzone = "5G"
kern.maxdsiz = "16G"
kern.dfldsiz = "16G"
kern.maxssiz = "5G"
Сервер героически выстоял два дня, после чего снова пожаловался на swap и прилег :st:

Re: Странное поведение FreeBSD8.2

Добавлено: 2013-07-17 9:12:30
bRUtality
Приподниму с вашего позволения.
Удалось немного локализовать проблемку.
Сейчас все выглядит так: после ребута сервер работает примерно сутки, после чего:
1) в messages появляется запись

Код: Выделить всё

Approaching the limit on PV entries, consider increasing either the vm.pmap.shpgperproc or the vm.pmap.pv_entry_max sysctl.
2) в БД начинают копиться очереди
3) БД в какой-то момент решает, что ей плохо:

Код: Выделить всё

LOG: database system was interrupted; last known up at ...
LOG: database system was not properly shut down; automatic recovery in progress
Дело в том, что сервер бегал больше года и не жаловался, но после аварийного отключения началась эта беда.
У меня есть предположение, что железо повредилось и проблема в районе свопа.

Коллеги, помогите :sorry:

Re: Странное поведение FreeBSD8.2

Добавлено: 2013-07-17 10:15:29
Bayerische

Re: Странное поведение FreeBSD8.2

Добавлено: 2013-07-17 11:05:19
bRUtality
Да, спасибо, я смотрел эту тему. Там указывались следующие причины:
1) лимиты на память и прочие ресурсы были дефолтные, не хватало ресурсов. Но у меня:

Код: Выделить всё

vm.pmap.shpgperproc = 2048 # это default *10
vm.pmap.pv_entry_max = 24817515
Еще много чего подкручено, т.к. оперативки 48Gb (могу позволить 8) )
2) проблемы с железом
- Хард. Возможно, т.к. слетала файловая система на диске с БД. Запускал

Код: Выделить всё

fsck -y раздел_с_БД
, после чего БД поднялась, но некоторые таблицы оказались нечитаемы. Что делать? Запустить fsck для всех разделов?
- Оперативная память. Как можно проверить плашки на работоспособность?
3) Проблема с непонятным поведением сети устранена (запустил 2 раза sshd, из rc.conf убрал)

Re: Странное поведение FreeBSD8.2

Добавлено: 2013-07-17 11:14:43
Bayerische
Оперативная память. Как можно проверить плашки на работоспособность?
под DOS есть memtest, testmem и т.п.
Оставить одну планку.

Re: Странное поведение FreeBSD8.2

Добавлено: 2013-07-18 10:49:09
bRUtality
Спасибо за совет.
С оперативной памятью и хардами все в порядке, будем дальше копать....

Странное поведение FreeBSD8.2

Добавлено: 2019-07-24 10:19:16
sqripuch
это известный баг cisco серии 4500

Странное поведение FreeBSD8.2

Добавлено: 2019-07-24 10:29:04
bRUtality
sqripuch писал(а):
2019-07-24 10:19:16
это известный баг cisco серии 4500
С тех пор я сменил не только работу, но и специализацию в айти не один раз. Но ночные кошмары с какой-то фигней в логах фряхи преследуют все эти годы. Спасибо тебе, коллега, теперь буду спать спокойно!

Странное поведение FreeBSD8.2

Добавлено: 2019-07-24 11:06:14
WideAreaNetwork
некропостеры)