Как ловить причину зависания сервера?

← →
kaif (2003-06-10 18:38) [0]

Сервер Yaffil ss 821.
Пользователей 3-4 человек. База с сотней таблиц и полутора сотнями процедур. Ничего особенного не происходит. Никаких кошмарных запросов на десятки минут, ничего такого. Количество записей в таблицах ограничивается тысячами.
Иногда сервер зависает (виснут все клиенты, IBX).
Такое было раза три месяц назад. Теперь опять началось со страшной силой. Сегодня сервер вис минимум 8 раз за рабочий день. Сервис не стопится. Только перезагрузка сервака. База как правило не рушится (рухнула 1 раз вчера - появились страницы "неверного формата").
Максимум в чем меня можно упрекнуть - в использовании каскадных выборок из ХП, иногда в объединениях участвуют и таблицы вперемешку с ХП.
Дома (в однопользовательском режиме) никогда тот же сервер не виснет. Хотя гоняю программу по-черному (генерю тысячи документов, тестирую, в общем).
Как ловить причину?
Может ли быть виновна сеть? Сеть в принципе хорошая (100Mbit). Сервак тоже (2ГГц с какой-то особой памятью, работающей на двойной частоте шины).

← →
Zacho (2003-06-10 21:55) [1]

> kaif © (10.06.03 18:38)

Черт знает. У меня такого не было. Попробуй спросить в news://forums.demo.ru/epsylon.public.interbase А лучше - непосредственно у Олега Иванова ("Oleg LOA" <loa@mail.ru>).
А нет ли чего-нибудь интересного в yaffil.log ? И почему бы не поставить последнюю сборку Yaffil ?

← →
kaif (2003-06-10 23:50) [2]

2 Zacho © (10.06.03 21:55)
Насчет Yaffil.log интересно.
Я сам хочу причину найти. И прошу лишь советов, какими путями идти в самостоятельном поиске этой причины. Наверняка кто-то уже этим занимался.

← →
Alexandr (2003-06-11 06:19) [3]

надо в первую очередь посмотреть, почему виснет:
проц, память, сеть, диск.
Т.е. посмотреть загрузку процессора
посмотреть сколько памяти занимает
посмотреть много ли обращается к диску
посмотреть загрузку сети.

Т.е. нейти узкое место.

Типичная проблема: внезапноотвалившийся клиент, после которого делается RollBack и сболка мусора. Особенно если в одной транзакции много работы было, или эта транзакция версии удерживала от других обновлений...
А вот кстати AutoSweep надеюсь в 0 установлен?

← →
Polevi (2003-06-11 10:12) [4]

переставь сервер на другое железо, пусть пару дней на нем поработает, сделаешь выводы

← →
DrPass (2003-06-11 11:40) [5]

А еще лучше подождать финального релиза.

← →
kaif (2003-06-11 13:53) [6]

Всем спасибо.
2 Polevi © (11.06.03 10:12)
>переставь сервер на другое железо, пусть пару
>дней на нем поработает, сделаешь выводы

Такая идея у меня была.

2 Alexandr © (11.06.03 06:19)
Насчет sweep я опять проглядел. Просто по умолчанию он по-моему на 20тыс. rollback записей стоит. Я подумал, что вряд ли это когда-то сработает... Сегодня посмотрю.
Насчет загрузки ресурсов хорошая мысль. Мне даже в голову не пришла... совсем заработался.

Да, такой вопрос. А транзакции на чтение ReadCommitted, удерживая для себя ситуацию, аллокируют страницы или нет? То есть верно я понимаю, что лишь транзакции, в которых происходят модификации, что-то аллокируют для удержания старых версий записей и создания новых?
Наконец, размер страницы может влиять? Например, у меня стоит
1 Kbyte. И при Restore я не оставляю лишнего места в базе (максимально компактный файл). Это может влиять? Может, сделать Restore с запасом аллокированных страниц. Кто-нибудь такие эксперименты ставил? Или кол-во аллокированных страниц вообще не причем и дело вероятно в тразакциях и сборке мусора?

← →
Zacho (2003-06-11 14:42) [7]

> kaif © (11.06.03 13:53)
>
> Насчет sweep я опять проглядел. Просто по умолчанию он по-моему
> на 20тыс. rollback записей стоит. Я подумал, что вряд ли
> это когда-то сработает... Сегодня посмотрю.

На самом деле, это разница в 20000 между старейшей активной и старейшей заинтересованной. Подробнее - http://www.ibase.ru/devinfo/oitoat.htm

> Да, такой вопрос. А транзакции на чтение ReadCommitted,
> удерживая для себя ситуацию, аллокируют страницы или нет?

В смысле, "удерживая" ?

> То есть верно я понимаю, что лишь транзакции, в которых
> происходят модификации, что-то аллокируют для удержания
> старых версий записей и создания новых?

Насколько я понимаю, версии создаются только теми транзакциями, в которых происходят какие-либо модификации. Если в контексте транзакции были только чтения - никаких версий именно эта транзакция не создаст.

> Наконец, размер страницы может влиять?

На что ? На быстродействие ? Естественно, может. В статьях на www.ibase.ru кое-что было на эту тему.

← →
kaif (2003-06-11 15:12) [8]

2 Zacho © (11.06.03 14:42)
Нет, меня интересовало влияние размера страницы на вероятность зависания.

Насколько я понимаю, версии создаются только теми транзакциями, в которых происходят какие-либо модификации. Если в контексте транзакции были только чтения - никаких версий именно эта транзакция не создаст.

Я тоже так себе представляю.

Хорошо. Я сейчас попробую отключить sweep. Правда сегодня зависаний пока не было :((
Статистика пока такая:
Flags 0
Checksum 12345
Generation 5970
Page size 1024
ODS version 10.0
Oldest transaction 406
Oldest active 5454
Oldest snapshot 5448
Next transaction 5960
Bumped transaction 1
Sequence number 0
Next attachment ID 0
Implementation ID 16
Shadow count 0
Page buffers 3000
Next header page 0
Database dialect 3
Creation date Jun 9, 2003 16:58:45
Attributes force write, no reserve

Я не вижу, какая здесь старейшая заинтересованная транзакция, но, мне кажется, разница пока меньше 20000.

← →
kaif (2003-06-11 15:16) [9]

Что-то с клиентского компьютера не удается поменять sweep interval с помощью IBConsole (Unavailable database). Как это сделать иначе?

← →
kaif (2003-06-11 16:12) [10]

Вот, наконец!
Висит!
Смотрю через Remote Administrator - на сервере процессор целиком загружен процессом ibserver.exe. Что тот делает?
Память сильно не занята. (18М)
Такое впечатление, что ibserver.exe или зациклился или занят какой-то хренью. Неужели это sweep?
И сколько тогда ждать?

← →
kaif (2003-06-11 16:52) [11]

Сервер "очумело работает" уже 40 мин на машине 2ГГц. Диагностика соединений IBConsole (порт 3050 и NetBeui) говорят OK. С сервером, тем не менее, вступить в контакт невозможно.

← →
Zacho (2003-06-11 20:29) [12]

> kaif © (11.06.03 16:52)

Похоже или на SWEEP или на зверскую сборку мусора.
А вообще, что-то такое я слышал и не связанное со сборкой мусора. Попробуй спросить на news://forums.demo.ru/epsylon.public.interbase

← →
kaif (2003-06-12 17:47) [13]

Я только что руками запустил sweep. Сервер сделал sweep за одно мгновение (даже пол-секунды не прошло).

Database header page information:
Flags 0
Checksum 12345
Generation 8485
Page size 1024
ODS version 10.0
Oldest transaction 8263
Oldest active 8264
Oldest snapshot 8193
Next transaction 8474
Bumped transaction 1
Sequence number 0
Next attachment ID 0
Implementation ID 16
Shadow count 0
Page buffers 3000
Next header page 0
Database dialect 3
Creation date Jun 9, 2003 16:58:45
Attributes force write, no reserve

Как я вижу Oldest transaction подтянулась куда надо с 406.

Но sweeping времени не занял вообще.

← →
MXA (2003-06-12 23:25) [14]

>Но sweeping времени не занял вообще.
значит, поидее, это он и выполнялся

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

разбираться руки не дошли, т.к. небыло времени и кроме того
это не вызывало проблем - сервер не вис, ошыбок в базе небыло.

но сдается мне, что проблемы похожие, и не особо зависят от
версии сервера - я это наблюдал на FBv1.0 CS и на SS.

← →
Alexandr (2003-06-13 09:36) [15]

Мож кто сервер запросом таким загрузил? на 40минут?

← →
kaif (2003-06-13 17:53) [16]

2 Alexandr © (13.06.03 09:36)
В моей системе нет ни одного запроса дольше, чем на 1 сек.

2 MXA (12.06.03 23:25)
Нет, это не так. Ни разу в результате зависания работа не завершалась нормальным образом. Я бывал вынужден физически выключить железку сервера (IB не стопился). Так что sweep (если это был sweep) ни разу не завершился успешно. Я вручную стартовал sweep с разницы
Oldest transaction 406
Next transaction 8300
И за мгновение произошел sweeping.

===============
СЕГОДНЯ ПОКА ЗАВИСАНИЙ НЕТ.
Я интуитивно исправил одну вещь (!!!). Во всех местах конфигурации, где происходит Commit (CommitRetaining) или Rollback, я сделал явный старт соответствующей транзакции. Я вспомнил, что где-то писалось о том, что IBX-компоненты при обычных IBQuery.Open активизируют какую-то левую тразакцию (неявную), которую нельзя откатить. Чисто эмпирически все работало и транзакции ("неявные") прекрасно откатывались. Бывали лишь глюки (зависания) при RollbackRetaining, из-за чего я никогда не использую этот режим отката.
Если моя гипотеза подтвердится (зависаний больше не будет), сообщу в этой ветке. Это будет ракомендацией всем разработчикам:
"никогда не использовать неявный старт транзакций IBX, например, не оставлять активным запрос на форме в процессе дизайна".
Но пока я не уверен...
Может это просто везение... Что пока ничего не висит. А работа сегодня идет активно. До того изменения, что я внес, висло каждые полчаса в среднем.
Правда я и sweep сделал. Но sweep интервал мне так и не удалось установить в 0, ни с IBConsole (глюкс), ни gfix -h 0 (пароль спрашивает, синтаксис ввода его не могу подобрать, в описании ничего на этот счет не сказано вразумительного)

Как ловить причину зависания сервера? Найти похожие ветки