Привет
Есть Классик. Можно как-то прибить зависшее подключение через системные
таблицы?
fb 2.1
Дмитрий
Селектом вытаскиваются значения 0, 1, 2, но в документации описаны
только 0 и 1. Что означают эти значения? В релиз ноутах идет ссылка
на
http://tracker.firebirdsql.org/browse/CORE-1583
но, там обсудается проблема и нет расшифровки конкретных значений.
Dmitry Lendel wrote:
Есть Классик. Можно как-то прибить зависшее подключение через системные
таблицы?
Нет, только в 2.5.
--
Дмитрий Еманов
других ЭВМ локальной сети.
Получаем запись в MON$ATTACHMENTS о коннекте: все правильно в записи.
Валим клиентское приложение через диспетчер задач.
Запись "висит". После backup-restore - никуда не девается.
Вопрос: такова сокральная задумка ?
"Andrei" wrote in message ...
ок. тогда между 0 и 2, между IDLE и STALLED какая разница?
IDLE - нет вообще никакой активности.
STALLED - есть живой запрос и\или курсор, но в данный момент
он не выполняется (клиент задумался).
--
Хорсун Влад
и конкретных значений.
SELECT T.RDB$TYPE, T.RDB$TYPE_NAME
FROM RDB$TYPES T
WHERE (T.RDB$FIELD_NAME = 'MON$STATE')
ок. тогда между 0 и 2, между IDLE и STALLED какая разница?
01.10.2010 10:42, Khorsun Vlad пишет:
"Andrei" wrote in message ...
ок. тогда между 0 и 2, между IDLE и STALLED какая разница?
IDLE - нет вообще никакой активности.
STALLED - есть живой запрос и\или курсор, но в данный момент
он не выполняется (клиент задумался).
Уточню: stalled - это перер
Тогда еще вопросы:
1) какой статус имеет запрос после выполнения операции Prepare?
2) статус Idle выставляется сразу по достижении Fetch-em состояния
Eof?
3) для не селектов (например, EXECUTE PROCEDURE или INSERT) какие
статусы возможны? Только Active?
02.10.2010 13:19, Andrei пишет:
1) какой статус имеет запрос после выполнения операции Prepare?
Idle
2) статус Idle выставляется сразу по достижении Fetch-em состояния
Eof?
Насколько я помню, лишь когда курсор будет закрыт.
3) для не селектов (например, EXECUTE PROCEDURE или INSERT) каки
Установлена ОС Mandriva 2009 x64, 9Гб оперативки, винты 160Гб.
До этого стоял *FirebirdSS-2.5.0.25946-ReleaseCandidate3.amd64* конструкция
отваливает все залипшие коннекты из текущей БД, а далее и в цикле из всех
архивов. Работало безупречно:
>>>
in AUTONOMOUS TRANSACTION
do delete
"Dmitry Lendel" ...
Привет
Что означает MON$REMOTE_PID в MON$ATTACHMENTS?
ID клиентского процесса.
--
Хорсун Влад
Dmitry Lendel wrote:
Что означает MON$REMOTE_PID в MON$ATTACHMENTS?
Доку уже отменили?
/docs/README.monitoring_tables.txt
--
Дмитрий Еманов
Привет
FB 2.5
FB работает как приложение
Запустил два Эксперта
В первом выполняю запрос select uuid_to_char(gen_uuid()) from rdb$database;
SELECT MON$USER, MON$REMOTE_ADDRESS,
MON$REMOTE_PID,
MON$TIMESTAMP
FROM MON$ATTACHMENTS
Показывает два соединения. Все понятно.
А вот это
SELECT
Dmitry Lendel wrote:
А если вот так?
> and STMT.MON$STATE > 0
--
Дмитрий Еманов
Доку уже отменили?
/docs/README.monitoring_tables.txt
Да нет. Меня просто интересовал контекст. Что вкладывается в это значение.
А если вот так?
> and STMT.MON$STATE > 0
Если оставить ATT.MON$ATTACHMENT_ID <> CURRENT_CONNECTION AND
то пусто
Если убрать --ATT.MON$ATTACHMENT_ID <> CURRENT_CONNECTION AND
Видит только себя
Если убрать
STMT.MON$STATE > 0
Выдает
MON$USER MON$REMOTE_ADDRESS MON$SQL_T
Привет
Я в соседнем окне запустил запрос
Select cast(?idkey as integer) from rdb$database
Выполнил
SELECT ATT.MON$USER,
ATT.MON$REMOTE_ADDRESS,
STMT.MON$SQL_TEXT,
STMT.MON$TIMESTAMP,
STMT.MON$STATE
FROM MON$ATTACHMENTS ATT
JOIN MON$STATEMENTS STMT
ON ATT.MON$ATTACHMENT_ID = STMT.MON
Dmitry Lendel wrote:
Если оставить ATT.MON$ATTACHMENT_ID <> CURRENT_CONNECTION AND
то пусто
Если убрать --ATT.MON$ATTACHMENT_ID <> CURRENT_CONNECTION AND
Видит только себя
Если убрать
STMT.MON$STATE > 0
Выдает
MON$USER MON$REMOTE_ADDRESS MON$SQL_TEXT MON$TIMESTAMP MON$STATE
S
Dmitry Lendel wrote:
Появилось
Select cast(? as integer) from rdb$database
два раза с признаком STMT.MON$STATE = 0
так должно быть?
"два раза" - зависит от приложения. В IBE какой-то чудной пул запросов.
"с признаком STMT.MON$STATE = 0" - если приложение закрыло курсор, но не
освободило
"с признаком STMT.MON$STATE = 0" - если приложение закрыло курсор, но не
освободило хендл запроса, то так и должно быть
Что означает "закрыло"?
Dmitry Lendel wrote:
Что означает "закрыло"?
isc_dsql_free_statement(handle, DSQL_close);
--
Дмитрий Еманов
Да и в догонку:
Тут в голову пришла еще одна мысль, решил протестировать с клиентом
fbclient.dll от 2.0.1.12855.
(ну, чтобы, домены MON$REMOTE_PID, MON$REMOTE_PROCESS были NULL).
Клиентское приложение "отваливается" от базы нормально, если его
"прибивать" через диспетчере
PEAKTOP wrote:
Валим клиентское приложение через диспетчер задач.
Серверный процесс остается висеть или завершается?
Вопрос: такова сокральная задумка ?
Если серверный процесс тоже завершился, то запись из мониторинга должна
исчезнуть.
ЗЫ. версия fbclient тут никакой рояли не играет...
вот и не заметил :)
Конечно серверный процесс "висит" ... Убийство соответствующего
процесса сервера (по MON$ATTACHMENTS.MON$SERVER_PID) удаляет
соответствующую запись в таблице.
Тогда другой вопрос: классик что, никак не ловит "отвалившихся"
клиентов ? Просто в тестов
PEAKTOP wrote:
Тогда другой вопрос: классик что, никак не ловит "отвалившихся"
клиентов ?
Нет. Он архитектурно однопоточный и проверить состояние сетевого
соединения нельзя вплоть до необходимости передачи очередного пакета.
ЗЫ. но картина мира уже изменяется :-)
--
Дмитрий Еманов
закономерность.
Т.е. это выполнялось всего дважды и оба раза висло или же выполнялось
многократно, но висло всего дважды?
Какие права даны на каталог /tmp/firebird?
Вопрос к разработчикам что происходит. Если конструкция с
"MON$ATTACHMENTS.MON$ATTACHMENT_ID" больше не работает, то подс
разными базами. Может отчленять по кускам.
--
View this message in context:
http://firebird.1100200.n4.nabble.com/delete-from-MON-ATTACHMENTS-where-MON-ATTACHMENTS-MON-ATTACHMENT-ID-CURRENT-CONNECTION-tp4145993p4146299.html
Sent from the firebird-russian mailing list archive at Nabble.com.
. гасить
только коннекты к своей базе?
Если будет работать, то проблема не в MON$, а в коннектах к другим
базам, см. ниже.
Вот еще - на клиенте установлен снэпшот FB2.5.1.26353-0_win32.
Причем тут клиент? Версия клиентской библиотеки на это никак не влияет.
Суммарный объем файлов баз к
"reshetnyakvkt" ...
Сама ось не висит, выполняет команды и т.д. А к серверу firebird не
присоединится, все соединения уходят в никуда, т.е. висят без ответа на
ошибку коннекта или другое.
Бектрейс висячего процесса и копия лок-таблицы могут пролить свет
на эту тайну
--
Хорсун Влад
Пытаюсь отменить долгоиграющий запрос.
delete from mon$statements where mon$statement_id=... не срабатывает,
а
delete from mon$statements where mon$attachment_id=... срабатывает
Это так задумано?
Yurij wrote:
delete from mon$statements where mon$statement_id=... не срабатывает,
а
delete from mon$statements where mon$attachment_id=... срабатывает
Это так задумано?
Скорее да, чем нет :-) mon$statement_id стабилен только в рамках
транзакции. Т.е. если ты отселектил ID и тут же
On Jan 24, 6:48 pm, Dmitry Yemanov <[EMAIL PROTECTED]> wrote:
> Скорее да, чем нет :-) mon$statement_id стабилен только в рамках
> транзакции. Т.е. если ты отселектил ID и тут же удаляешь, тогда все
> должно работать. А если селект закоммитил и удаляешь в другой
> транзакци
посмотреть mon$attachments на рабочей базе
несколько запросов вчера было на ура,
потом следующая последовательность действий, которая повторилась и сегодня
1. select count(*) from mon$attachments
2. служба fb_inet_server.exe встаёт в ступор, не отвечает и процессоры не
кушает. помогает только
Если это актуально разработчикам... В логе:
"Firebird::status_exception". SuperServer, ALT Linux до Sysiphus
поднятый, 2.6.18 ядро, fb собирался из исходника. Решил попробывать
новые функции мониторинга, на любом селекте из таблиц мониторинга
выдает заголовок и вылетает. И еще, прерывание запроса
в течение рабочего дня 200-350 одновременных пишуше-читающих коннектов
постоянно подключаются-отключаются через 4 клиента (сервера приложений)
т.е. коннектов в FB - 4шт? или возможно вплоть до 350 ?
поставили заказчику в декабре 2010
WI-V2.5.0.26074
x32 SuperClassic
памяти fb_inet_server
Hello, Oleg Matveyev!
You wrote on Wed, 12 Jan 2011 14:21:51 +0300:
>> в течение рабочего дня 200-350 одновременных пишуше-читающих
>> коннектов постоянно подключаются-отключаются через 4 клиента (сервера
>> приложений)
OM> т.е. коннектов в FB - 4шт? или возможно вплоть до 350 ?
серверов прил
Hello, Dmitry Yemanov!
You wrote on Wed, 12 Jan 2011 14:20:06 +0300:
DY> Вот за это можно сразу бить ногами.
спасибо, Дим! :)
DY> В 32-битном адресном пространстве работают 350 коннектов, каждый со своим
DY> кешем!?
кэш потока маленький 64*8к ... всё уменьшаем, а быстродействие не изменяется
dimon wrote:
Если это актуально разработчикам...
Еще бы.
"Firebird::status_exception". SuperServer, ALT Linux до Sysiphus
поднятый, 2.6.18 ядро, fb собирался из исходника. Решил попробывать
новые функции мониторинга, на любом селекте из таблиц мониторинга
выдает заголовок и вылетает.
База
Восстановил из бэкапа. 2.0.1.что_у_нас_там_последний_релиз. Кстати,
это конечно мои проблемы, но... Вообщем с этим восстановлением были
проблемы. Сразу не удалось восстановить, потому как в полях timestamp
значения выходили за допустимые пределы, там действительно был мусор
база девелоперовская бы
dimon wrote:
В логе:
"Firebird::status_exception"
И все?
--
Дмитрий Еманов
Чего то я тут кучу мусора написал без ответа на конкретный вопрос. Да
создавалась этой же сборкой сервера.
Ну вообщем да... Вот подробнее:
#.com.ua (Server)Mon Jul 9 10:26:30 2007
Firebird::status_exception
#.com.ua (Client)Mon Jul 9 10:26:30 2007
/opt/firebird/bin/fbguard: /opt/firebird/bin/fbserver
terminated abnormally (-1)
#.com.ua (Client)Mon Jul 9
Напиши мне на [EMAIL PROTECTED] - обсудим как потрассировать
детальнее...
--
Дмитрий Еманов
Dmitry Yemanov wrote:
Напиши мне
Чорт, имелся ввиду dimitr собака firebirdsql точка org :-)
--
Дмитрий Еманов
Dmitry Yemanov пишет:
Dmitry Yemanov wrote:
Напиши мне
Чорт, имелся ввиду dimitr собака firebirdsql точка org :-)
вообще-то они говорят, что если по тому кривому адресу отправить, то
тоже дойдет. Вроде.
--
Кочмин Александр
Привет, Kochmin!
Вы пишешь 09 июля 2007:
>> Чорт, имелся ввиду dimitr собака firebirdsql точка org :-)
KA> вообще-то они говорят, что если по тому кривому адресу отправить, то
KA> тоже дойдет. Вроде.
Хм...
Интересно, в чем же тогда кроется "защита" от спамеров?..
--
With best regards, Al
Я читаю через groups.google.com. Там если жмёшь на этот "кривой"
адрес, появляется форма ввода кода, после этого показывает нормальный
адрес.
On 9 июл, 12:28, "Alex Cherednichenko" <[EMAIL PROTECTED]> wrote:
> Привет, Kochmin!
> Вы пишешь 09 июля 2007:
>
> >> Чорт, имелся ввиду dimitr собака fi
"Alex Cherednichenko" <[EMAIL PROTECTED]>
сообщил/сообщила в новостях следующее: news:[EMAIL PROTECTED]
> Хм...
> Интересно, в чем же тогда кроется "защита" от спамеров?.
В том, наверное, что адрес каждый раз генерится новый:
Счас проверим...
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTE
Интересно, в чем же тогда кроется "защита" от спамеров?.
В том, наверное, что адрес каждый раз генерится новый:
Нет, не в том. На адрес могут безпроблемно отправить письмо только
зарегестрированые пользователи этой newsgroup, остальным придет email от
gmane с просьбой ответить на него.
Р
12.01.2011 13:45, Gene Feudorov пишет:
поставили заказчику в декабре 2010
WI-V2.5.0.26074
x32 SuperClassic
Вот за это можно сразу бить ногами. В 32-битном адресном пространстве
работают 350 коннектов, каждый со своим кешем!?
1. select count(*) from mon$attachments
2. служба
12.01.2011 14:51, Gene Feudorov пишет:
DY> Вот за это можно сразу бить ногами.
спасибо, Дим! :)
Всегда пожалуйста :-)
кэш потока маленький 64*8к ...
Вот только добавь еще 2-4МБ на стек каждого активного коннекта, кеш
метаданных и прочие буферы сортировки. Вы и так на грани балансируете,
äÃÃÃÃà ÃÃ
ÃÃ.
ðÃà backup ÃÃ
ÃÃ
à srvice api à MON$ATTACHMENTS Ãà ÃÃÃ
ÃÃÃÃ
ÃÃÃ Ã ÃÃÃÃÃ
MON$REMOTE_PROCESS Ã MON$REMOTE_PID null.
C ÃÃÃÃÃ
ÃÃÃÃ ÃÃÃÃ ÃÃ ÃÃÃÃ
ÃÃÃ ÃÃÃÃÃ, ÃÃÃ ÃÃÃ gbak ÃÃÃÃÃÃ
ÃÃÃ, Ã ÃÃ
ÃÃ
ÃÃÃÃÃÃÃÃÃÃÃ
Andrew Kipcharsky пиÑеÑ:
ÐÑи backup ÑеÑез srvice api в MON$ATTACHMENTS по ÑÐ¾ÐµÐ´Ð¸Ð½ÐµÐ½Ð¸Ñ Ð² полÑÑ
MON$REMOTE_PROCESS и MON$REMOTE_PID null.
C пÑоÑеÑÑом бÑло Ð±Ñ Ð¿Ð¾Ð»ÐµÐ·Ð½Ð¾ знаÑÑ, ÑÑо Ñам gbak болÑаеÑÑÑ
ÐÑк не болÑаеÑ
12.09.2010 11:08, Andrew Kipcharsky пиÑеÑ:
Флага да/Ð½ÐµÑ Ð±ÑÐ´ÐµÑ Ð´Ð¾ÑÑаÑоÑно Ð´Ð»Ñ gbak Ñ.к. gfix и nbackup не ÑабоÑаÑÑ
ÑеÑез service API и опознаÑÑÑÑ Ð² MON$ATTACHMENTS (одеÑниÑе менÑ, еÑли Ñ Ð½Ðµ
пÑав).
ÐÑе
12.09.2010 18:17, Andrew Kipcharsky пиÑеÑ:
Ðменно Ñакое Ñ Ð¸ пÑедлагаÑ.
ÐÑло Ð±Ñ Ð·Ñко...
Ð ÑÑÐµÐºÐµÑ Ð·Ð°Ð½ÐµÑеÑÑ?
--
ÐмиÑÑий Ðманов
ÃÃÃÃÃÃÃÃà ÃÃà gbak Ã.Ã. gfix à nbackup ÃÃ
ÃÃÃÃÃÃÃÃ
ÃÃ
ÃÃ
à service API à ÃÃÃÃÃÃÃÃÃà à MON$ATTACHMENTS (ÃÃÃ
ÃÃÃÃÃ
ÃÃ
ÃÃ, Ã
ÃÃÃ Ã ÃÃ
ÃÃÃÃ).
ëÃà ÃÃÃÃÃÃà ÃÃ
ÃÃÃ
ÃÃÃÃ
ÃÃÃ ÃÃÃÃÃÃÃÃÃÃ: ÃÃÃÃ
ÃÃÃÃÃ
ðÃ
"Dmitry Yemanov" ÃÃÃÃ
Ã:
>> ëÃà ÃÃÃÃÃÃà ÃÃ
ÃÃÃ
ÃÃÃÃ
ÃÃÃ ÃÃÃÃÃÃÃÃÃÃ: ÃÃÃÃ
ÃÃÃÃÃ
ðï,gbak,nbackup,gfix,
>> g-Ã
ÃÃ
-ÃÃÃ-ÃÃÃÃÃÃ-Ã-ÃÃÃÃÃÃ
Ã...
>
> éÃÃ
ÃÃÃ ÃÃÃÃÃ
à à ÃÃÃ
ÃÃÃÃÃÃ.
âÃÃà Ãà ÃÃÃÃ...
ó ÃÃÃÃÃ
Dmitry Yemanov ÃÃÃÃ
Ã:
>
> ÷ ÃÃÃ
ÃÃ
à ÃÃÃÃ
ÃÃ
ÃÃ?
ïÃÃ
ÃÃÃ, ÃÃÃÃÃÃ Ã ÃÃÃÃÃ
ÃÃÃÃ ÃÃÃ ÃÃÃ ÃÃ
ÃÃÃÃ...
ó ÃÃÃÃÃ
ÃÃÃ
Ã,
ëÃÃÃÃÃÃÃÃà áÃÃÃÃ
Ã
59 matches
Mail list logo
