powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
135 сообщений из 135, показаны все 6 страниц
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38450928
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hi all. Сабж.

Встречается эта "комета" чрезвычайно редко (я видел последний раз несколько лет взад, хотя изгаляюсь над ФБ чуть ли не каждый день).
Все транзакции стартуют как read committed record_version no wait, число isql'ей = 350.

Молотьба шла с 31-10-2013 15:53, остановлена только что. За эти 50 ч в двух error-логах окошек вылезло:
Код: plaintext
1.
2.
3.
4.
5.
-- log #1
02:19:56.700 Statement failed, SQLSTATE = 40001
02:19:56.700 lock conflict on no wait transaction
02:19:56.700 After line 0 in file t004-ins-log.sql
02:19:56.715 Cannot get server version without database connection
02:19:56.715 Command error: show database

Код: plaintext
1.
2.
3.
4.
5.
6.
-- log #2
22:17:22.257 Statement failed, SQLSTATE = 40001
22:17:22.289 lock conflict on no wait transaction
22:17:22.289 After line 0 in file t004-ins-log.sql
22:17:22.304 Cannot get server version without database connection
22:17:22.304 Command error: show database
(увы, в логах есть только время, без даты; причина - тумблер "тупизьм" был в положении ON: я просто забыл добавить ключ /d в mtee )

Видно, что каждый из этих isql'ей в соотв-щий ошибке момент времени не мог достучаться до сервака ("Cannot get server version without database connection"). Но в firebird.log'е НИЧЕГО нету! И крашей тоже не было.

И чего тогда это могло быть ?

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
ISQL Version: WI-V2.5.3.26682 Firebird 2.5
Server version:
Firebird/linux AMD64 (access method), version "LI-T3.0.0.30695 Firebird 3.0 Alpha 1"
Firebird/linux AMD64 (remote server), version "LI-T3.0.0.30695 Firebird 3.0 Alpha 1/tcp (oel64)/P12"
Firebird/x86/Windows NT (remote interface), version "WI-V2.5.3.26682 Firebird 2.5/tcp (CSMIRROR)/P12"
on disk structure version 12.0
Database: 192.168.0.220/3330:idx_test

PS. Вопрос ДСа от 2009 на эту же тему читал, но так и не понял, где собака порылась.
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38450959
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидPS. Вопрос ДСа от 2009 на эту же тему читал
Тот мой вопрос был совсем на другую тему.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38450962
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry Sibiryakov,

а, точно. Тогда всё еще загадочнее.
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38451009
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид> Видно, что каждый из этих isql'ей в соотв-щий ошибке
Таблоид> момент времени не мог достучаться до сервака

Вроде бы это может не иметь никакого отношения к самим insert-ам,
т.е. если какая-то бага и проблем действительно есть, то где-нибудь
в другом месте. Иначе старый рецепт бесконфликтности insert-ов
придётся пересматривать, чего лично мне очень бы не хотелось.

Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38451027
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Гаджимурадов РустамВроде бы это может не иметь никакого отношения к самим insert-ам, т.е. если какая-то бага и проблем действительно есть, то где-нибудь в другом месте.Вероятнее всего - именно так. Ибо "встреча" с этим сообщением для инсертов происходит ЧРЕЗВЫЧАЙНО редко.
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38451030
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Так хочешь поймать - избавься от всех реконнектов и пр.
Оставь только 1 коннект в самом начале и запусти тест.
Заодно ещё и нагрузку можно будет увеличть.

Более того, в идеале - ещё и сначала 350 коннектов и
только потом 350 молотилок insert-а.

Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38451035
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ну так попробуй не использовать no wait. Ибо что бы там ни говорил kdv, no wait это не
единственный правильный вариант.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38451037
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А как wait вместо no wait должен помочь в данном случае?

Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38451038
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Гаджимурадов РустамА как wait вместо no wait должен помочь в данном случае?

Заставит транзакцию подождать освобождения ресурса за который она конфликтует.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38451051
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ГРТак хочешь поймать - избавься от всех реконнектов и пр.
Оставь только 1 коннект в самом начале и запусти тест .Т.е. создать огромный скрипт не с 30 (как сейчас), а с 3000 execute_block'ами + коммитами и молотили чтобы без передыхов (типа shell ping -n 30 localhost>nul) - так ?

ГРЗаодно ещё и нагрузку можно будет увеличть.Нагрузку могу увеличить раза в полтора-два, не более.
Как-то делал 700-800 аттачей, ~полтора года взад, когда с missing entries воевал, - сервер начинает загибаться.
Ошибка (на имеющемся у мну железе) появляется не чаще, чем орбитальные сближения Марса с Землёй.

ГРБолее того, в идеале - ещё и сначала 350 коннектов и только потом 350 молотилок insert-а. Сделать что-то типа барьера (термин из java), когда 100 задач подходят к стартовой точке, НЕ начиная выполнения до тех пор, пока не откроется барьер, а затем после открытия этого шлагбаума сразу все вместе ломятся со своими 100500 insert'ами - я правильно понял твою мысль ?
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38451052
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovГаджимурадов РустамА как wait вместо no wait должен помочь в данном случае?Заставит транзакцию подождать освобождения ресурса за который она конфликтует.Она дождётся этот ресурс и... чего дальше ? insert не может вызвать конфликт потерянного обновления, а в условиях юзания генератора для ПК - не может также вызвать нарушание этого ПК.
Будет ли вообще сабжевая ошибка при таких условиях ?
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38451054
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидОна дождётся этот ресурс и... чего дальше ?
Скорее всего сделает что хочет и пойдёт дальше работать.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38451059
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovТаблоидОна дождётся этот ресурс и... чего дальше ?
Скорее всего сделает что хочет и пойдёт дальше работать.ну, и как зарегистрировать тот факт, что перед этим моментом она некоторое время не могла делать insert ?
т.е. вот упёрлась она wait-лбом во что-то - и как залогировать это её "затруднение" ?
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38451072
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоидкак залогировать это её "затруднение" ?
Никак, это рабочая ситуация.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38451075
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovТаблоидкак залогировать это её "затруднение" ?Никак, это рабочая ситуация.ну, и в чём профит ? с no_wait хотя бы видно, что проблема существует, а так и не увидим ничего...
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38451076
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоидс no_wait хотя бы видно, что проблема существует
Какая проблема?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38451096
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovТаблоидс no_wait хотя бы видно, что проблема существуетКакая проблема?Проблема непонятности, см. стартовый вопрос топега... :-)
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38451104
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидПроблема непонятности, см. стартовый вопрос топега... :-)
Проблема малоинформативности сообщений об ошибках в Firebird видна в любом случае. Но вот
отсутствие в твоих логах собственно того statement, который failed, это уже проблема твоих
логов, с Firebird не связанная.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38451115
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Нашёл я, где это происходит: к этому приводит во всех имеющихся случаях... запрос show version!
Этот запрос сидит в самом начале .sql-скрипта, выполняемого каждой молотилкой. Вот как он выглядит:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
set warnings off; set sql dialect 3; 
 show version;  
show database; 

set heading off; set list off;  
select '-- PACKET # 1:' BEGIN_SECTION from rdb$database; commit;  
COMMIT;
SET TRANSACTION READ WRITE READ COMMITTED RECORD_VERSION NO WAIT;
set heading off;
set list off;
set term ^;

execute block returns(msg varchar(200)) as
   <. . . тут идут insert'ы (в других двух скриптах - update & delete) . . .>
end
^set term ;^
commit;

select 'Take some pause at '||cast('now' as timestamp) msg from rdb$database;
-- тут ему даётся передых, примерно 30 сек:
shell rndpause.bat;
select 'Pause is over   at '||cast('now' as timestamp) msg from rdb$database;

----------------------------------------------------------------------------------
-- а теперь всё повторяем заново,  ЗА ИСКЛЮЧЕНИЕМ  show version & show database:
set heading off; set list off;  
select '-- PACKET # 2:' BEGIN_SECTION from rdb$database; commit;  
COMMIT;
SET TRANSACTION READ WRITE READ COMMITTED RECORD_VERSION NO WAIT;
set heading off;
set list off;
set term ^;

<. . . далее всё повторяется . . . >
Перед вызовом isql с вышепоказанным скриптом и сразу после возврата из isql в батнике в тот же лог пишется "Start iter #..." и "Finish iter #..." соотв-но.
Вызов isql идёт с ключиком `-b` (bail on error), поэтому при обломе ЛЮБОЙ из команд скрипта (в т.ч. show-) будет немедленный возврат из скрипта.

В итоге, вместо вот такого лога:
типичный лог, когда нет ошибок
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
-- INSERTING, window # 247.  Start  iter # 1  at 19:23:18,00 
ISQL Version: WI-V2.5.3.26682 Firebird 2.5
Server version:
Firebird/linux AMD64 (access method), version "LI-T3.0.0.30695 Firebird 3.0 Alpha 1"
Firebird/linux AMD64 (remote server), version "LI-T3.0.0.30695 Firebird 3.0 Alpha 1/tcp (oel64)/P12"
Firebird/x86/Windows NT (remote interface), version "WI-V2.5.3.26682 Firebird 2.5/tcp (CSMIRROR)/P12"
on disk structure version 12.0
Database: 192.168.0.220/3330:idx_test
        Owner: SYSDBA                         
PAGE_SIZE 4096
Number of DB pages allocated = 32220
Sweep interval = 0
Forced Writes are OFF
Transaction - oldest = 739
Transaction - oldest active = 740
Transaction - oldest snapshot = 179
Transaction - Next = 2480
ODS = 12.0
Default Character set: WIN1251

-- PACKET  # 1 : 


-- attach_id=285, intro .sql at 2013-11-02 19:23:07.8550, init gen_test=1312440                                                                                                                          
-- adding 147 rows, v_rnd4err=0.69, LOWER_THRESHOLD_FOR_ERR=0.00, v_last_gen=1312440                                                                                                                     
insert into tmp(. . .) values(. . .); -- i=0                                 
insert into tmp(. . .) values(. . .); -- i=1                                  
<...>
insert into tmp(. . .) values(. . .); -- i=146                              
commit; -- finish adding 147 rows at 2013-11-02 19:23:07.8670, i=147, curr gen_test=1312637                                                                                                              


Take some pause at 2013-11-02 19:23:07.8720  


Pause is over   at 2013-11-02 19:23:35.7900  


-- PACKET  # 2 : 

<... далее всё, как в пакете # 1: несколько сотен аналогичных строк. . .>

-- INSERTING, window # 247.  Finish iter # 1  at 19:28:26,98 

-- в каждом "странном" случае получаю вот такую пустышку:

Код: plaintext
1.
2.
3.
4.
-- INSERTING, window # 91.  Start  iter # 19  at 20:53:22,22 
ISQL Version: WI-V2.5.3.26682 Firebird 2.5
Server version:
-- INSERTING, window # 91.  Finish iter # 19  at 20:53:28,92 

И сопоставляя выведенный текст (в этой пустышке) с временем возникновения ошибки:
Код: plaintext
1.
2.
3.
4.
2013-11-02  20:53:26 .206 Statement failed, SQLSTATE = 40001
2013-11-02 20:53:26.721 lock conflict on no wait transaction
2013-11-02 20:53:26.721 After line 0 in file t004-ins-log.sql
2013-11-02 20:53:28.721 Cannot get server version without database connection
2013-11-02 20:53:28.721 Command error: show database
-- вижу, что спотыкач случился именно на show version .
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38451122
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоидвижу, что спотыкач случился именно на show version.
Правильно. Потому что CONNECT обломился с приведённой ошибкой.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38451128
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovТаблоидвижу, что спотыкач случился именно на show version.
Правильно. Потому что CONNECT обломился с приведённой ошибкой.А не обломился ли он именно от того, что первая команда в скрипте есть show version ?
PS. Вызов isql'я (на всякий):
Код: plaintext
%fb_isql% %fb_testdb%  -b -n -now -q  -user %fb_usr% -pas %fb_psw% -i t004-%mode%-log.sql 2>&1 1>>%fb_log% | mtee /d/t/+ %fb_err% > nul
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38451130
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид> Нашёл я, где это происходит: к этому приводит во всех имеющихся случаях... запрос show version!

Начал было отвечать на твоё сообщение выше, но вовремя увидел это.
Так вот - так тебе и надо! :)

Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38451134
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Гаджимурадов РустамТаблоид> Нашёл я, где это происходит: к этому приводит во всех имеющихся случаях... запрос show version!

Начал было отвечать на твоё сообщение выше, но вовремя увидел это.
Так вот - так тебе и надо! :)а чё не так ? нельзя версию спросить, что ле ?!.. :-)
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38451148
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид> а чё не так ?

Подход к тестированию:

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

> нельзя версию спросить, что ле ?!.. :-)

Да хоть обспрашивайся, мне не жалко. :)
Но посягать на святое - бесконфликтность
инсертов - не нааадо!...

Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38451182
Гхостик
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Гаджимурадов РустамИначе старый рецепт бесконфликтности insert-ов
придётся пересматривать, чего лично мне очень бы не хотелось. Я в оракле недавно наткнулся на блокировку при вставке из-за наличия bitmap индекса. Было больно.
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38451231
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Гаджимурадов Рустама) тест синтетически не чистый (у тебя всегда так)я уже столько раз слышал от тебя упрёки в "синтетической нечистоте", что теперь точно знаю: ты когда-нибудь ОБЯЗАТЕЛЬНО приведёшь здесь, на скл.ру, абсолютно чистый несинтетический тест. Своего изготовления.

Гаджимурадов Рустамб) тест плохо реализован (выводить кривой оператор нужно было сразу, а не с подсказки ДСа).Чем он (show version) кривой, откуда это известно ? И что значит "выводить нужно было СРАЗУ " ? (не понял я тут, объясни еще раз)

Гаджимурадов РустамНо посягать на святое - бесконфликтность
инсертов - не нааадо!... я и не думкал посягать на них. Сейчас запустил этот же тест, 450 молотилок, все делают инсерты. Но убрал из скрипта show version. Оставляю на N часов, по окончании его и посчитаем цыплят посмотрим в логи.
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38451232
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ГхостикЯ в оракле недавно наткнулся на блокировку при вставке из-за наличия bitmap индекса. Было больно.OLTP ? ( ибо... )
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38451235
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

я посмотрел твой тест. Честно говоря причину конфликта в конкретном скрипте не вижу. Скорее всего эта ошибка прилетела ещё откуда нибудь. Вообще тест конечно запутанный. Вот если бы ты сделал что-то более простое на чём можно было заметить эти конфликты тогда было бы проще.

Сам тест конечно прикольный эмулирует высокую нагрузку по DML.
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38451242
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидА не обломился ли он именно от того, что первая команда в скрипте есть show
version ?
Нет. В нём нет телепатии чтобы предвидеть команды, а ошибка у тебя выводится ещё до начала
выполнения скрипта.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38451302
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов ДенисВообще тест конечно запутанный. Вот если бы ты сделал что-то более простое на чём можно было заметить эти конфликты тогда было бы проще.Он предназначался для других целей: в 2010 была наивная надежда стабильно воспроизвести с его помощью страшную гадость - missing entries в индексах. Стабильно воспроизвести не получалось, но Влад тогда всё-таки убил эту нечисть. Надеюсь, что навсегда.
Затем этот тест юзался для проверки устойчивости работы ФБ под сильной DML-нагрузкой. Было выявлено несколько траблов А в прошлом году неожиданно вылезла проблема долгой установки коннектов к 2.5, в итоге в этот тест была добавлена "калибрация" скорости коннекта.
Увы, но проблема неожиданных затыков при установке коннектов (доходить может аж до... 600 сек!!) пока не решена, хотя именно её исследование сейчас и ведётся.
Сабж обнаружился вообще случайно: несколько .err-логов имели ненулевой размер. Это я потом уже вспомнил, что видел его раньше.

Ну так вот, докладываю: странное сообщение о конфликте блокировки при insert'ах НЕ связано с наличием оператора show version . Ибо сейчас этот оператор в скрипте закомментарен. А сообщение снова получено. Те же самые 450 молотилок всё-таки мистическим образом "сталкиваются" в каком-то астрале своими инсертами...

Симонов ДенисСам тест конечно прикольный эмулирует высокую нагрузку по DML.У мну в планах есть сбацать настоящий тест, где будет много таблиц, отражающих реальные сущности (изделия, контрагенты, остатки и балансы етц). В него же хочу вкрячить бесконфликтное обновление балансов по "схеме ДСа" (она вроде не им придумана, но ДС её тут показывал), ну и еще несколько фишек, в т.ч. новшеств из ФБ-3.
Но это попозжее.
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38451306
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovНет. В нём нет телепатии чтобы предвидеть команды, а ошибка у тебя выводится ещё до начала выполнения скрипта.Если ошибка лезет в ответ на isc_attach_database(), то... откуда ФБ "знает", что скрипт собирается insert'ы делать ?!
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38451308
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидТе же самые 450 молотилок всё-таки мистическим образом "сталкиваются" в
каком-то астрале своими инсертами...
Сними fb_lock_print -a и посмотри длины очередей локов к разным страницам. Вполне
возможно, что они сталкиваются не "в астрале", а на header page или TIP.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38451310
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоидоткуда ФБ "знает", что скрипт собирается insert'ы делать ?!
Он и не знает. С чего ты это взял?..
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38451324
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид> А сообщение снова получено.

То же самое сообщене (lock conflict on no wait tx) ?
И на каком операторе? И приведи текст своего
скрипта без закомментированного show version.

Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38451395
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

меня настораживает кэш
DefaultDbCachePages = 65000 чего так много

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
Database header page information:
        Flags                   0
        Generation              104
        System Change Number    0
        Page size               4096
        ODS version             12.0
        Oldest transaction      94
        Oldest active           95
        Oldest snapshot         95
        Next transaction        96
        Sequence number         0
        Next attachment ID      12
        Implementation          HW=AMD/Intel/x64 little-endian OS=Linux CC=gcc
        Shadow count            0
        Page buffers            0
        Next header page        0
        Database dialect        3
        Creation date           Sep 20, 2013 19:45:47
        Attributes

    Variable header data:
        Sweep interval:         0
        *END*

Page size = 4096 чего так мало
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38451439
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovТаблоидТе же самые 450 молотилок всё-таки мистическим образом "сталкиваются" в
каком-то астрале своими инсертами...Сними fb_lock_print -a и посмотри длины очередей локов к разным страницам. Вполне
возможно, что они сталкиваются не "в астрале", а на header page или TIP.Снимок лок-таблицы надо делать именно в тот момент, когда возникает это "нечто", выдающее себя за lock conflict. Предсказать сиё нельзя. Что тогда, снимать каждую секунду ? Всё равно слишком грубая точность. Надо чтобы ФБ сам создавал в таких ситуациях снимок ЛТ и стек-трейс. То есть, нужна какая-то аналогия триггера на это событие и чтобы этот триггер создал нужный лог.
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38451440
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovТаблоидоткуда ФБ "знает", что скрипт собирается insert'ы делать ?!
Он и не знает. С чего ты это взял?..ну откудова он тогда берёт текст 'lock conflict on no wait tx' ? какой еще оператор может вызвать его, кроме инсерта ?
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38451451
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Гаджимурадов Рустамприведи текст своего скрипта без закомментированного show version.в аттаче.
Это большой скрипт, в котором:
1) сначала задаются команды:
Код: plaintext
1.
2.
3.
set warnings off; set sql dialect 3; 
-- temply commented 03-11-2013 12:03 -- show version; 
show database; 
- а затем
2) 30 раз повторяется вот этот фрагмент:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
117.
118.
119.
120.
121.
122.
123.
124.
125.
126.
127.
128.
129.
130.
131.
132.
133.
134.
135.
136.
137.
138.
139.
140.
141.
142.
143.
144.
145.
146.
147.
148.
149.
150.
151.
152.
153.
154.
155.
156.
157.
158.
159.
160.
161.
162.
163.
164.
165.
166.
167.
168.
169.
170.
171.
172.
173.
174.
set heading off; set list off;  
select '-- PACKET # 1:' BEGIN_SECTION from rdb$database; commit;  
--/*
COMMIT;
SET TRANSACTION READ WRITE READ COMMITTED RECORD_VERSION NO WAIT;
set heading off;
set list off;
set term ^;
--*/

execute block returns(msg varchar(200)) as

declare MIN_ROWS_FOR_INSERTING INT =  50;
declare MAX_ROWS_FOR_INSERTING int = 200;

declare MAX_FLD_VALUE int = 100;
declare v_inserted_cnt int;
declare i int=0;
declare v_result int;
declare v_last_gen type of column tmp.id;
declare v_rnd4err double precision;
declare v_rndval double precision;
declare v_stt varchar(2048);
declare v_log varchar(2048);
declare v_id type of column tmp.id;
declare v_f00 type of column tmp.f00;
declare v_f01 type of column tmp.f01;
declare v_f02 type of column tmp.f02;
declare v_f03 type of column tmp.f03;
declare v_f04 type of column tmp.f04;
declare v_f05 type of column tmp.f05;
declare v_f06 type of column tmp.f06;
declare v_f07 type of column tmp.f07;
declare v_f08 type of column tmp.f08;
declare v_f09 type of column tmp.f09;
declare v_f10 type of column tmp.f10;
declare v_f11 type of column tmp.f11;
declare v_dt1 type of column tmp.dt1;
declare v_act_id type of column log_activity.id = -2147483648;
declare v_dts_beg type of column log_activity.dts_beg;
declare v_dts_end type of column log_activity.dts_end;

declare MIN_TIME_FOR_LOGGING int = 2000;
declare LOWER_THRESHOLD_FOR_ERR double precision = 0; -- 0=no errors, 1=max errors

-- ######################################################################
--  INSERT INSERT INSERT INSERT INSERT INSERT INSERT INSERT INSERT INSERT
-- ######################################################################
begin
 
  msg=
    '-- attach_id='||current_connection||', intro .sql at '
    ||(select cast('now' as timestamp) from rdb$database)
    ||', init gen_test='||gen_id(gen_test,0);
  suspend;

  v_rndval=rand();
  v_rnd4err=rand(); -- error probability
  v_inserted_cnt=MIN_ROWS_FOR_INSERTING + v_rndval * (MAX_ROWS_FOR_INSERTING-MIN_ROWS_FOR_INSERTING);
  v_last_gen=gen_id(gen_test,0);
  msg='-- adding '||v_inserted_cnt||' rows'
      ||', v_rnd4err='||cast(:v_rnd4err as numeric(6,2))
      ||', LOWER_THRESHOLD_FOR_ERR='||cast(LOWER_THRESHOLD_FOR_ERR as numeric(6,2))
      ||', v_last_gen='||v_last_gen
  ;
  suspend;
  v_result=0;
  i=0;
  while (i < v_inserted_cnt and v_result=0) do begin

    if (exists( select * from ext_stoptest )) then -- 20.10.2012
    begin
      msg='test cancelled: external file stoptest has a non-zero size!';
      suspend;
      leave;
    end 
    v_act_id = -2147483648;

    v_id=gen_id(gen_test,1);
    v_f00=rand()*:MAX_FLD_VALUE;
    v_f01=rand()*:MAX_FLD_VALUE;
    v_f02=rand()*:MAX_FLD_VALUE;
    v_f03=rand()*:MAX_FLD_VALUE;
    v_f04=rand()*:MAX_FLD_VALUE;
    v_f05=rand()*:MAX_FLD_VALUE;
    v_f06=rand()*:MAX_FLD_VALUE;

    -- 11.02.2010 1930:
    v_f07=iif(:v_rnd4err < :LOWER_THRESHOLD_FOR_ERR and i>=v_inserted_cnt-1, rand()*:MAX_FLD_VALUE, -:v_id);
    v_f08=iif(:v_rnd4err < :LOWER_THRESHOLD_FOR_ERR and i>=v_inserted_cnt-1, rand()*:MAX_FLD_VALUE, :v_id);

    v_f09=rand()*:MAX_FLD_VALUE;
    v_f10=rand()*:MAX_FLD_VALUE;
    v_f11=rand()*:MAX_FLD_VALUE;
    v_dt1='01.03.2012 03:00:00';
    begin

      msg='insert into tmp(id,f00,f01,f02,f03,f04,f05,f06,f07,f08,f09,f10,f11,dt1)'
            ||' values('
            ||cast(:v_id as varchar(11))||','
            ||cast(:v_f00 as varchar(11))||','
            ||cast(:v_f01 as varchar(11))||','
            ||cast(:v_f02 as varchar(11))||','
            ||cast(:v_f03 as varchar(11))||','
            ||cast(:v_f04 as varchar(11))||','
            ||cast(:v_f05 as varchar(11))||','
            ||cast(:v_f06 as varchar(11))||','
            ||cast(:v_f07 as varchar(11))||','
            ||cast(:v_f08 as varchar(11))||','
            ||cast(:v_f09 as varchar(11))||','
            ||cast(:v_f10 as varchar(11))||','
            ||cast(:v_f11 as varchar(11))||','
            ||''''||cast(:v_dt1 as varchar(30))||''''
            ||'); -- i='||i;

       
      insert into tmp(id,f00,f01,f02,f03,f04,f05,f06,f07,f08,f09,f10,f11,dt1)
      values(:v_id
            ,:v_f00
            ,:v_f01
            ,:v_f02
            ,:v_f03
            ,:v_f04
            ,:v_f05
            ,:v_f06
            ,:v_f07
            ,:v_f08
            ,:v_f09
            ,:v_f10
            ,:v_f11
            ,:v_dt1
          );

        if (i in(0,1) or mod(i,100)=0 or i>=v_inserted_cnt-1 ) then
          suspend; -- 17.03.2012: minimize output

        when any do
        begin

          suspend; -- msg: insert-statement with zero division
          v_result=gdscode;
          msg='rollback; -- ABORT, gds='||v_result
                ||', i='||i
                ||', curr gen_test='||gen_id(gen_test,0)
                ||' at '||cast('now' as timestamp)||': '
                ||decode(v_result, 
                    335544665, 'violation of PK/UK',
                    335544321, 'num/string ovf',
                    335544345, 'lock on no_wait trn', 
                    335544349, 'dup val in idx', 
                    335544334, 'can`t upd erased row',
                    'UNKNOWN'
                );
          suspend;
          leave;
       end        
    end
    i=i+1;
  end
  if (v_result=0) then begin
    msg='commit; -- finish adding '||v_inserted_cnt||' rows at '||cast('now' as timestamp)
    ||', i='||i
    ||', curr gen_test='||gen_id(gen_test,0)
    ;
    suspend;
  end
end
--/*
^set term ;^
commit;

select 'Take some pause at '||cast('now' as timestamp) msg from rdb$database;
shell rndpause.bat;
select 'Pause is over   at '||cast('now' as timestamp) msg from rdb$database;

Пауза между каждым "пакетом" обеспечиается тривиальным батником 'rndpause.bat', который раньше заставлял ждать от 30 до 50 сек, но сейчас всё проще: ping -n 6 127.0.0.1>nul

Скрипт сей вызывается из батника, в цикле, командой:
Код: plaintext
1.
%fb_isql% %fb_testdb% -b -n -now -q -user %fb_usr% -pas %fb_psw% -i t004- %mode% -log.sql 2>&1 1>>%fb_log% | mtee /d/t/+ %fb_err% > nul
(где %mode% в данном варианте теста = строке ins )

В итоге, работа скрипта логируется в somename.txt, а ошибки выполнения - в соотв-щий somename.err, где имя <somename> генерится в батнике через имя компа + режим (%mode%) + номер_запущенного_окна.

Вот пример лога выполнения скрипта:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
-- INSERTING, window # 120. Start  iter # 1 at 12:05:52,67
Database: 192.168.0.220/3330:idx_test
        Owner: SYSDBA
PAGE_SIZE 4096
Number of DB pages allocated = 31388
Sweep interval = 0
Forced Writes are OFF
Transaction - oldest = 23
Transaction - oldest active = 24
Transaction - oldest snapshot = 20
Transaction - Next = 813
ODS = 12.0
Default Character set: WIN1251

-- PACKET # 1:


-- attach_id=143, intro .sql at 2013-11-03 12:05:42.6850, init gen_test=1280777

-- adding 67 rows, v_rnd4err=0.93, LOWER_THRESHOLD_FOR_ERR=0.00, v_last_gen=1280798

insert into tmp(id,f00,f01,f02,f03,f04,f05,f06,f07,f08,f09,f10,f11,dt1) values(1280800,1,71,30,34,75,99,7
4,-1280800,1280800,65,8,43,'2012-03-01 03:00:00.0000'); -- i=0
insert into tmp(id,f00,f01,f02,f03,f04,f05,f06,f07,f08,f09,f10,f11,dt1) values(1280805,17,7,29,78,85,22,5
4,-1280805,1280805,28,86,82,'2012-03-01 03:00:00.0000'); -- i=1
insert into tmp(id,f00,f01,f02,f03,f04,f05,f06,f07,f08,f09,f10,f11,dt1) values(1281094,64,11,80,73,95,11,
7,-1281094,1281094,73,2,79,'2012-03-01 03:00:00.0000'); -- i=66
commit; -- finish adding 67 rows at 2013-11-03 12:05:42.6920, i=67, curr gen_test=1281098



Take some pause at 2013-11-03 12:05:42.7160


Pause is over   at 2013-11-03 12:05:49.6700


-- PACKET # 2:


-- attach_id=143, intro .sql at 2013-11-03 12:05:49.6980, init gen_test=1308588

-- adding 72 rows, v_rnd4err=0.46, LOWER_THRESHOLD_FOR_ERR=0.00, v_last_gen=1308588
 . . . 
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38451455
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов ДенисDefaultDbCachePages = 65000 чего так многоТестирую SuperServer, что плохого в таком значении ? Памяти на хосте 32 Гб.
Симонов ДенисPage size = 4096 чего так малоДык DML будет фиговее идти (в отличие от селектов), когда размер страницы задран. Я вроде бы ковырял этот вопрос. Но не помню, вываливал сюда результаты или всё так и осталось в кулуаре.
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38451458
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидСнимок лок-таблицы надо делать именно в тот момент, когда возникает это
"нечто", выдающее себя за lock conflict.
Не надо. Общая картина очередей не должна сильно меняться. Просто в какой-то момент одна
из и без того длинных очередей ещё чуть-чуть подрастает и - опа! - у кого-то не
выдерживают нервы.

Таблоидну откудова он тогда берёт текст 'lock conflict on no wait tx' ? какой еще
оператор может вызвать его, кроме инсерта ?
Из пальца высасывает. Это всего лишь текстовая интерпретация ошибки, выбрасываемой
лок-менеджером. И как это обычно бывает, выкидываться она может из любого места, вплоть до
не относящегося к транзакциям вообще.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38451459
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Гаджимурадов РустамТо же самое сообщене (lock conflict on no wait tx) ?
И на каком операторе?Почти то же самое, отличие только во втором слове
Оператор теперь тот, который "следующий в очереди" после закомментаренного:
Код: plaintext
1.
2.
3.
4.
2013-11-03 18:25:32.096 Statement failed, SQLSTATE = 40001
2013-11-03 18:25:32.096 lock conflict on no wait transaction
2013-11-03 18:25:32.096 After line 0 in file t004-ins-log.sql
2013-11-03 18:25:32.096 Command error:  show database 
Гаджимурадов РустамИ приведи текст своего скрипта без закомментированного show version.См пост выше , аттач.
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38451460
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovЭто всего лишь текстовая интерпретация ошибки, выбрасываемой
лок-менеджером. И как это обычно бывает, выкидываться она может из любого места, вплоть до
не относящегося к транзакциям вообще.Код ошибки: 40001 - он должен быть "индивидуальным" для этой ситуации или так же будет выброшен "от балды" ?
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38451462
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovТаблоидСнимок лок-таблицы надо делать именно в тот момент, когда возникает это "нечто", выдающее себя за lock conflict.
Не надо. Общая картина очередей не должна сильно меняться. Просто в какой-то момент одна
из и без того длинных очередей ещё чуть-чуть подрастает и - опа! - у кого-то не
выдерживают нервы.Ну, и с какой частотой посоветуешь запускать fb_lock_print ? Напомню: молотьба идёт 450 коннектами, только insert'ы, ИНДЕКСЫ ВСЕ УБИТЫ (временно :-)), рост размера базы - примерно 0.7 ... 1.0 Мб в секунду.
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38451463
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovИ как это обычно бывает, выкидываться она может из любого места, вплоть до
не относящегося к транзакциям вообще.А это... как его... не может ли она выбрасываться в те моменты, когда ФБ запрашивает у диска место для увеличения размера .fdb ?! А то что-то не вижу в упор, что еще может вызвать сиё...
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38451464
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидКод ошибки: 40001 - он должен быть "индивидуальным" для этой ситуации или
так же будет выброшен "от балды" ?
SQLCODE это ещё большая братская могила чем gdscode. А текст ошибки это именно
интерпретация gdscode.

ТаблоидНу, и с какой частотой посоветуешь запускать fb_lock_print ? Напомню:
молотьба идёт 450 коннектами, только insert'ы
Один раз. Когда все окна уже запустились и молотьба идёт в стабильном режиме.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38451466
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидА то что-то не вижу в упор, что еще может вызвать сиё...
Да всё что угодно. У тебя же ОСь не реального времени. Активировался какой-нибудь процесс
и сожрал немного больше ЦПУ или ввода-вывода и вот уже страница сбросилась в кэш на долю
секунды позже. А молотилок много, они выстроились в очередь и у кого-то из них не
выдержали нервы (то бишь случился таймаут) и была выброшена ошибка "не смог дождаться".
Что в переводе и звучит как "lock conflict on no wait transaction".
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38451482
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovТаблоидА то что-то не вижу в упор, что еще может вызвать сиё...
Да всё что угодно. У тебя же ОСь не реального времени. Активировался какой-нибудь процесс
и сожрал немного больше ЦПУ или ввода-вывода и вот уже страница сбросилась в кэш на долю
секунды позже. А молотилок много, они выстроились в очередь и у кого-то из них не
выдержали нервы (то бишь случился таймаут) и была выброшена ошибка "не смог дождаться".
Что в переводе и звучит как "lock conflict on no wait transaction".В общем, запустил fb_lock_print -c -a -d ... с логированием и упаковкой каждого лога в отдельный .rar, с интервалом 30 сек. Оставляю до завтрего. Если за ночь появятся новые lock conflict'ы, то сделаю тынц на соотв-щие снимки лок-таблы.
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38451486
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
... "before I forget" ((C) John Lord' 1982): надо бы запустить эти инсерты БЕЗ вызова gen_id(). Кто его знает, вдруг причина именно в этом...
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38451487
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А также без show database, select-ов и пр. ненужного.

Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38451490
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Пофиг. Ни генераторы, ни страницы данных при коннекте не читаются.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38451496
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovА молотилок много, они выстроились в очередь и у кого-то из них не
выдержали нервы (то бишь случился таймаут ) и была выброшена ошибка "не смог дождаться".
Что в переводе и звучит как "lock conflict on no wait transaction".Таймаут при no wait... внезапно
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38451530
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladТаймаут при no wait... внезапно
Ну не таймаут... Немного поиска и я вижу, например, что она может кидаться из lck.cpp и
без транзакции вообще. Фиг знает, конечно, в каких случаях...
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38451618
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоидзапустил fb_lock_print -c -a -d ... с логированием и упаковкой каждого лога в отдельный .rar, с интервалом 30 сек. Оставляю до завтрего. Если за ночь появятся новые lock conflict'ы, то сделаю тынц на соотв-щие снимки лок-таблы.Попалось три карася. В 05:37:20, 05:37:27 & 08:50:14.
Все три в своих .err-логах вывели одно и тоже:
Код: plaintext
1.
2.
3.
4.
Statement failed, SQLSTATE = 40001
lock conflict on no wait transaction
After line 0 in file t004-ins-log.sql
Command error: show database

Поскольку всё это время работал shell-скрипт, фоткавший лок-таблицу с интервалом 30 сек (от заверешния упаковки предыдущего снимка до запуска нового fb_lock_print'a), то в наличии есть соотв-щие архивы перед и после наступления моментов времени 05:37 и 08:50.
Эти архивы (две папки с .rar'ами) выложил сюда: http://yadi.sk/d/tQ1mIjw-C64C7

Тест остановил, сейчас перезапущу его уже без всяких show version, gen_id и прочего - выкину всё, что только возможно.
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38451620
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PS. А еще есть несколько (четыре штуки) .err-логов вот с такой странностью:
Код: plaintext
Your user name and password are not defined. Ask your database administrator to set up a Firebird login.
При том, что батник с isql подсовывает, разумеется, правильный пароль.
Такие вот делы... :-/
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38451623
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидPS. А еще есть несколько (четыре штуки) .err-логов вот с такой странностью:
Код: plaintext
Your user name and password are not defined. Ask your database administrator to set up a Firebird login.
При том, что батник с isql подсовывает, разумеется, правильный пароль.
Такие вот делы... :-/... забыл добавить: в логе ФБ этим странностям (про неправильный пароль) соответствуют мессаги:
Код: plaintext
1.
2.
3.
4.
5.
oel64   Mon Nov  4 09:52:50 2013
        Error in isc_attach_database() API call when working with legacy security database
        I/O error during "open" operation for file "/opt/fb30/security3.fdb"
        Error while trying to open file
        No such file or directory
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38451638
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovФиг знает, конечно, в каких случаях...Может тогда лучше просто жевать ?
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38451640
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

а что, разве было сказано, что с security уже всё ок ?
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38451657
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladа что, разве было сказано, что с security уже всё ок ?Нет, не было. Но никто и не ждёт, что в ФБ-3 будет сразу всё ОК.
К тому же, в этом варианте теста коннекты все идут через legacy-плагин, т.е. клиент=2.5 (кроме bash-скрипта калибратора). Может, это как-то влияет...
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38451671
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В общем, закомментарил все вызовы gen_id, заменил маразм вида "||(select cast('now') from rdb$database)" на просто "||cast('now')", закомментарил все прочие select'ы.
Операторы show version & show database - закомментарены.

Скрипт, который теперь выполняют 450 молотилок, выглядит так:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
117.
118.
119.
120.
121.
122.
123.
124.
125.
126.
127.
128.
129.
130.
131.
132.
133.
set warnings off; set sql dialect 3; 
-- show version; 
-- show database; 
set heading off; set list off;  
select '-- PACKET # 1:' BEGIN_SECTION from rdb$database; commit;  
--/*
COMMIT;
SET TRANSACTION READ WRITE READ COMMITTED RECORD_VERSION NO WAIT;
set heading off;
set list off;
set term ^;
--*/

execute block returns(msg varchar(200)) as

. . . declare-секция всяких там переменных . . .

begin
 
  msg=
    '-- attach_id='||current_connection||', intro .sql at '
    ||cast('now' as timestamp)
    ||', init gen_test='; -- tmp 04.11.2013 -- ||g`en_id(gen_test,0);
  suspend;

  v_rndval=rand();
  v_rnd4err=rand(); -- error probability
  v_inserted_cnt=MIN_ROWS_FOR_INSERTING + v_rndval * (MAX_ROWS_FOR_INSERTING-MIN_ROWS_FOR_INSERTING);
  v_last_gen=-1; -- since 04.11.2013, before: g`en_id(gen_test,0);
  msg='-- adding '||v_inserted_cnt||' rows'
      ||', v_rnd4err='||cast(:v_rnd4err as numeric(6,2))
      ||', LOWER_THRESHOLD_FOR_ERR='||cast(LOWER_THRESHOLD_FOR_ERR as numeric(6,2))
      ||', v_last_gen='||v_last_gen
  ;
  suspend;
  v_result=0;
  i=0;
  while (i < v_inserted_cnt and v_result=0) do begin

    v_id=-1; -- since 04.11.2013, before: g`en_id(gen_test,1);

    . . . присваиваем переменным v_f00, v_f01 etc случайные значения . . .

    begin

      msg='insert into tmp(id,f00,f01,f02,f03,f04,f05,f06,f07,f08,f09,f10,f11,dt1)'
            ||' values( . . .';  -- далее сцепление строки со значениями v_id, v_f00, etc
       
      insert into tmp(id,f00,f01,f02,f03,f04,f05,f06,f07,f08,f09,f10,f11,dt1)
      values(:v_id
            ,:v_f00
            ,:v_f01
            ,:v_f02
            ,:v_f03
            ,:v_f04
            ,:v_f05
            ,:v_f06
            ,:v_f07
            ,:v_f08
            ,:v_f09
            ,:v_f10
            ,:v_f11
            ,:v_dt1
          );

        if (i in(0,1) or mod(i,100)=0 or i>=v_inserted_cnt-1 ) then
        suspend; -- 17.03.2012: minimize output

        when any do
        begin

          suspend; -- msg: insert-statement with zero division
          v_result=gdscode;
          msg='rollback; -- ABORT, gds='||v_result
                ||', i='||i -- since 04.11.2013, before:  ||', curr gen_test='||g`en_id(gen_test,0)
                ||' at '||cast('now' as timestamp)||': '
                ||decode(v_result, 
                    335544665, 'violation of PK/UK',
                    335544321, 'num/string ovf',
                    335544345, 'lock on no_wait trn', 
                    335544349, 'dup val in idx', 
                    335544334, 'can`t upd erased row',
                    'UNKNOWN'
                );
          -- gds=335544321: arithmetic exception, numeric overflow, or string truncation
          -- gds=335544345: lock conflict on no wait transaction
          -- gds=335544349: Attempt to store duplicate value (visible to active transactions) in unique index "@1".
          -- gds=335544334: Can not update erased record
          suspend;
          leave;
       end        
    end
    i=i+1;
  end
  if (v_result=0) then begin
    msg='commit; -- finish adding '||v_inserted_cnt||' rows at '||cast('now' as timestamp)
    ||', i='||i -- since 04.11.2013, before:  ||', curr gen_test='||g`en_id(gen_test,0)
    ;
    suspend;
  end
end
--/*
^set term ;^
commit;

shell rndpause.bat; -- отдыхаем 5 сек

--*/
----------------------------------------------------------------------------------
set heading off; set list off;  
select '-- PACKET # 2:' BEGIN_SECTION from rdb$database; commit;  
--/*
COMMIT;
SET TRANSACTION READ WRITE READ COMMITTED RECORD_VERSION NO WAIT;
set heading off;
set list off;
set term ^;
--*/

execute block returns(msg varchar(200)) as

. . . далее всё повторяется, как в пакете #1 . . .

end
--/*
^set term ;^
commit;

shell rndpause.bat; -- отдыхаем 5 сек

--*/

. . . и так далее, 30 пакетов . . .

Также запустил:
0) калибратор скорости установки коннектов (это - святое ;));
1) скрипт, ожидающий появление в .err-логах сообщения 'lock conflict', и регистрирующий это;
2) скрипт, снимающий лок-таблицу, но интервал поставил 15 сек вместо 30.

Оставляю на несколько часов, "пущай полетает".
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38451672
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

ты на более свежем снапшоте проверь. Там CORE-4200 исправили. Может она являлась причиной.
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38451683
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов ДенисТаблоид,

ты на более свежем снапшоте проверь. Там CORE-4200 исправили. Может она являлась причиной.Это только завтра, видимо. Тест получается каждый раз часов на 10-12. Хотелось бы ясности сначала с сабжем, а уже после копать на тему неправильных (якобы) паролей.
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38451692
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

там тикет не про неправильные пароли, про блокировку подключений. Кто знает может твой lock conflict от туда лез.
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38451696
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидВ общем, закомментарил все вызовы gen_id, заменил маразм вида "||(select cast('now') from rdb$database)" на просто "||cast('now')", закомментарил все прочие select'ы.
Операторы show version & show database - закомментарены.
<...>
Оставляю на несколько часов, "пущай полетает".Хоп! А вот и первый (и единственный пока) карась, быстро же он попался:

Код: plaintext
1.
2.
2013-11-04  12:18:12 .706 Statement failed, SQLSTATE = 40001
2013-11-04 12:18:12.737 lock conflict on no wait transaction
2013-11-04 12:18:12.737 After line 0 in file t004-ins-log.sql

Снимки лок-таблицы за период с 12:10 по 12:20 - тут: http://yadi.sk/d/DJqYJXYlC6Nwi
HTH.
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38451697
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов Денистам тикет не про неправильные пароли, про блокировку подключений. Кто знает может твой lock conflict от туда лез.Тогда бы они вместе "ходили", сообщения эти: о недоступности sec3.fdb и о лок-конфликтах. А они, судя по всему, не связаны, т.к. в разное время лезут.
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38451778
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladМожет тогда лучше просто жевать ?
Нет, лучше не использовать вторсырьё левые коды ошибок.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38451892
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидХоп! А вот и первый (и единственный пока) карась, быстро же он попалсяВторой карась попался.
В общем, ошибка эта всё-таки НЕ была связана ни с show version / database, ни с вызовами gen_id().
Это выплёвывает либо вызов isc_attach, либо всё-таки insert.
Снимки ЛТ во временнОй "окрестности" второго карася пока не делаю - жду, чего скажут Источники Света.

Может, оно вообще так и должно быть сейчас в Фб-3.х, да на большой нагрузке ?.. ;-)
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38452022
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Итог печален, как дождливый день.
За период с 11:28 (т.е. пять часов) на двух машинах проявилось вполне себе ощутимое число lock conflict'ов при insert'ах(?).
Часть из них действительно как-то "странно близки" по времени (см выделенные цветом), остальные вылезли сами по себе, вне связи с чем-либо.

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
log_ins_CSMIR_206.err:2013-11-04 12:18:12.737 lock conflict on no wait
log_ins_TLPRG_046.err:2013-11-04 14:20:45.233 lock conflict on no wait
log_ins_CSMIR_239.err:2013-11-04 14:52:39.362 lock conflict on no wait
log_ins_CSMIR_072.err:2013-11-04 14:55:19.737 lock conflict on no wait
log_ins_CSMIR_148.err:2013-11-04 14:55:23.971 lock conflict on no wait
log_ins_TLPRG_059.err:2013-11-04 15:13:16.499 lock conflict on no wait
log_ins_CSMIR_148.err:2013-11-04 15:28:10.050 lock conflict on no wait
log_ins_CSMIR_208.err:2013-11-04 15:55:06.581 lock conflict on no wait
log_ins_TLPRG_001.err:2013-11-04 15:57:43.108 lock conflict on no wait
log_ins_TLPRG_095.err:2013-11-04 16:00:33.796 lock conflict on no wait
log_ins_TLPRG_003.err:2013-11-04 16:13:28.421 lock conflict on no wait
log_ins_TLPRG_073.err:2013-11-04 16:13:28.467 lock conflict on no wait
log_ins_CSMIR_224.err:2013-11-04 16:21:04.565 lock conflict on no wait
log_ins_CSMIR_067.err:2013-11-04 16:23:41.518 lock conflict on no wait
log_ins_CSMIR_042.err:2013-11-04 16:23:41.878 lock conflict on no wait
log_ins_CSMIR_220.err:2013-11-04 16:30:11.940 lock conflict on no wait

Ошибка лезет на скрипте, который делает execute block'и только с инсертами + коммиты.
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38452130
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
у тебя триггер на коннект небось есть? Может он не только бесконфликтные инсерты делает?
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38452148
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitr,

есть конечно. Вот он у него какой

Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
CREATE OR ALTER TRIGGER TRG_LOGON
ACTIVE ON CONNECT POSITION 0
as
begin
  if ( current_user = 'CALIBRATOR' )
  then
    execute procedure SYS_CONNECT_CALIBRATE;
end



но вроде он свои скрипты другим плоьзователем исполняет.
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38452151
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
dimitrу тебя триггер на коннект небось есть? Может он не только бесконфликтные инсерты делает?Есть. База, кстати, та же самая, что и у тебя.

Но не вижу в упор, что там такого конфликтного в триггере на коннект. Вот:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
$ isql idx_under_load_test.fdb
Database:  idx_under_load_test.fdb
SQL> show trigger;
Trigger name                     Invalid
================================ =======
TRG_LOGON

Table name                       Trigger name                     Invalid
================================ ================================ =======
LOG_ACTIVITY                     LOG_ACTIVITY_GEN_PK
SQL> set blob all;

 SQL> show trigger trg_logon; 
TRG_LOGON, Sequence: 0, Type: ON CONNECT, Active
as
begin
  if ( current_user = 'CALIBRATOR' ) -- ==> молотилки сюда  НЕ  попадут, они все как SYSDBA
  then
    execute procedure SYS_CONNECT_CALIBRATE;
end
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

 SQL> show trigger log_activity_gen_pk;  -- соотв-щая таблица сейчас НЕ используется.

Triggers on Table LOG_ACTIVITY:
LOG_ACTIVITY_GEN_PK, Sequence: 0, Type: BEFORE INSERT, Active
as
begin
    if (new.id is null) then
        new.id = gen_id(log_activity_seq, 1);
end
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

 SQL> show proc sys_connect_calibrate; 
Procedure text:
=============================================================================
declare variable v_dts_beg timestamp;
declare variable v_dts_end timestamp;
declare variable c_min_duration_to_log int = 1000; --00; --3000; --5000; --0; -- 3000;
begin
    v_dts_end=cast('now' as timestamp);
    if (current_user <> 'CALIBRATOR') then -- => на всякий случай еще раз проверяем...
        EXIT; -- ##################  E X I T  ###############

    select first 1 cast(dts as timestamp) from ext_connect_calibr into v_dts_beg;
    if (
        v_dts_beg is null
        or
        datediff(millisecond from v_dts_beg to v_dts_end)
        < c_min_duration_to_log -- or connect was established enough quickly
       ) then
        EXIT; -- ##################  E X I T  ###############

    -- now we must log event of too long connection:
    insert into log_connect_calibr(dts_before_establish, dts_after_establish)
    values( :v_dts_beg, :v_dts_end);
    -- external file used by shell to run gdb if it`s size greater than zero
    insert into ext_long_connect_log(msg)
    values( 'ms_'||lpad( datediff(millisecond from :v_dts_beg to :v_dts_end),8,'0'));
end
=============================================================================
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38452157
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидНо не вижу в упор, что там такого конфликтного в триггере на коннект.

Для него стартует транзакция, так что лично я бы его для тестов убрал.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38452166
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovТаблоидНо не вижу в упор, что там такого конфликтного в триггере на коннект.Для него стартует транзакция, так что лично я бы его для тестов убрал.Можно, конечно, попробовать. Но при сильной нагрузке каждая из молотилок выполняет своё задание (30 пакетов вида ecxecute block + commit, код я приводил выше) на несколько минут. Так что триггер этот будет гораздо чаще дёргаться одним лишь калибратором.
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38452171
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
У тебя ошибка вылазит при connect. Триггер выполняется при connect. Какая разница как
часто он выполняется, если каждый раз он выполняется как раз тогда, когда вылазит ошибка?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38452175
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovУ тебя ошибка вылазит при connect .Обоснуй! Меня терзают смутные сомнения, что это *не* isc_attach, а всё-таки какой-то баг при insert'ах.
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38452179
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидОбоснуй!
Тебе "After line 0" ничего не говорит?..
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38452213
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А, вижу. Сейчас проверил: действительно, при ошибке внутри execute block'а номер строки будет 1, а не 0.
Ладно, дождусь результатов при DatabaseGrowthIncrement = 0 (запустил недавно), после чего проверю вариант без connect-триггера и калибратора.
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38452319
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кажись, ДС прав: "что-то" там неправильное живёт в триггере на connect. Сейчас этот триггер удалён, и сабжевого сообщения в .err-логах нету.
Оставляю молотьбу до утра. Если к утру ни одного карася не появится, значит точно трабл где-то в db_level-триггере.
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38452343
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидЕсли к утру ни одного карася не появится, значит точно трабл где-то в db_level-триггере."Караси" всё-таки случились. За полчаса - сразу 4 штуки. При отсутствии каких-либо триггеров . Индексов тоже нет.

Код: plaintext
1.
2.
3.
4.
log_ins_TLPRG_020.err:2013-11-04 22:24:53.483 lock conflict on no wait transaction
log_ins_CSMIR_018.err:2013-11-04 22:50:58.206 lock conflict on no wait transaction
log_ins_CSMIR_075.err:2013-11-04 22:56:42.971 lock conflict on no wait transaction
log_ins_CSMIR_135.err:2013-11-04 23:01:16.956 lock conflict on no wait transaction

А это значит, что проблема не в триггере. Any comments ?
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38452382
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Запусти тест заново и на чистой БД.
А-то у тебя то триггеры, то ещё что.

Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38452419
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Гаджимурадов РустамЗапусти тест заново и на чистой БД.
А-то у тебя то триггеры, то ещё что.я запускаю каждый раз на базе, являющейся копией эталона. А эталон сейчас НЕ содержит ни индексов ни триггеров.
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38452454
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ДЕ и Владу ты его уже заслал?

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

Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38452627
Сисдба Мастеркеевич
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Если есть подозрение, что виноваты инсерты, надо попробовать без них.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38452735
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сисдба Мастеркеевич,

Кстати да. Интересный вариант. У меня почему-то пока подозрение на security
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38452930
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Гаджимурадов РустамДЕ и Владу ты его уже заслал?Этот тест есть у всех трёх Источников Света. Я понимаю, что у них нет времени на возню с подкручиванием его настроек, изменением режимов запуска, написание вспомогательных скриптов и проч., поэтому пишу им в личку результаты, в "фоновом режиме". Ну и сюда выкладываю, когда уже совсем что-то непонятное (типа сабжа).

2 Симонов Денис: у тебя есть там резервный сервак (линуксовый), чтобы запустить кое-что ?
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38452932
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сисдба МастеркеевичЕсли есть подозрение, что виноваты инсерты, надо попробовать без них.Была такая мысль, еще вчера. Запущу сегодня, попозже.
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38452958
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

есть виртуалка CentOS 6.4 x64. Вечерком после работы могу попробовать. На работе есть и реальная машинка, но тут на ней оракля крутится. Использую для отладки одного
приложения (досталось поддержка), а потому не хотелось бы на нее ставить ещё что либо.
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38452963
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов Денисесть виртуалка CentOS 6.4 x64.сколько там памяти ?
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38452970
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

оперативы 2 Гб, а вот дискового пространства не много ~60 Гб. Сколько надо (пора фильмы на болванки зарезать)?
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38452974
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов Денис,

оперативы для 350 коннектов маловато будет, но больше вряд ли получиться предоставить. Компьютер - обычная рабочая станция с 4 Гб оперативки, больше половины под виртуалку отдать не могу.
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38452982
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

хотя для супера может и ничего будет
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38453023
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов Денисоперативы 2 Гб, а вот дискового пространства не много ~60 Гб. Сколько надо (пора фильмы на болванки зарезать)?ну, хотя бы 4 гб оперативки хотелось бы...
Впрочем, ладно: будем довольствоваться этим.
Запустить тест на INSERT'ы (и только на них) сможешь ? Наверное, окошек 200 можно будет открыть - у мну дома комп с еще меньшим объемом памяти, он ворочал это количество окон.
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38453029
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

хорошо попробую вечерком.
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38453076
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сисдба МастеркеевичЕсли есть подозрение, что виноваты инсерты, надо попробовать без них.В общем, по итогам ночного теста докладываю: "карасей" пришло целое стадо.
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
log_ins_TLPRG_001.err:2013-11-05 05:49:30.750 lock conflict on no wait transaction
log_ins_TLPRG_023.err:2013-11-05 05:18:47.203 lock conflict on no wait transaction
log_ins_TLPRG_029.err:2013-11-05 07:15:54.781 lock conflict on no wait transaction
log_ins_TLPRG_031.err:2013-11-05 04:58:09.109 lock conflict on no wait transaction
log_ins_TLPRG_039.err:2013-11-05 06:33:11.843 lock conflict on no wait transaction
log_ins_TLPRG_041.err:2013-11-05 03:15:50.687 lock conflict on no wait transaction
log_ins_TLPRG_041.err:2013-11-05 10:23:18.218 lock conflict on no wait transaction
log_ins_TLPRG_044.err:2013-11-05 05:18:47.218 lock conflict on no wait transaction
log_ins_TLPRG_059.err:2013-11-05 04:01:49.921 lock conflict on no wait transaction
log_ins_TLPRG_069.err:2013-11-05 06:01:23.828 lock conflict on no wait transaction
log_ins_TLPRG_075.err:2013-11-05 08:41:15.437 lock conflict on no wait transaction
log_ins_TLPRG_075.err:2013-11-05 12:52:02.546 lock conflict on no wait transaction
log_ins_TLPRG_082.err:2013-11-05 11:39:04.046 lock conflict on no wait transaction
log_ins_TLPRG_090.err:2013-11-05 07:15:54.750 lock conflict on no wait transaction
log_ins_TLPRG_091.err:2013-11-05 07:15:54.734 lock conflict on no wait transaction
log_ins_TLPRG_099.err:2013-11-05 11:26:15.578 lock conflict on no wait transaction

log_ins_CSMIRROR_004.err:2013-11-05 07:49:45.800 lock conflict on no wait
log_ins_CSMIRROR_016.err:2013-11-05 06:37:55.925 lock conflict on no wait
log_ins_CSMIRROR_025.err:2013-11-05 05:11:35.612 lock conflict on no wait
log_ins_CSMIRROR_040.err:2013-11-05 04:49:29.393 lock conflict on no wait
log_ins_CSMIRROR_046.err:2013-11-05 07:18:51.096 lock conflict on no wait
log_ins_CSMIRROR_048.err:2013-11-05 04:49:47.768 lock conflict on no wait
log_ins_CSMIRROR_048.err:2013-11-05 08:11:27.003 lock conflict on no wait
log_ins_CSMIRROR_061.err:2013-11-05 06:40:21.003 lock conflict on no wait
log_ins_CSMIRROR_075.err:2013-11-05 12:30:28.362 lock conflict on no wait
log_ins_CSMIRROR_096.err:2013-11-05 04:29:30.065 lock conflict on no wait
log_ins_CSMIRROR_098.err:2013-11-05 09:41:46.643 lock conflict on no wait
log_ins_CSMIRROR_100.err:2013-11-05 11:06:49.253 lock conflict on no wait
log_ins_CSMIRROR_107.err:2013-11-05 08:01:03.159 lock conflict on no wait
log_ins_CSMIRROR_111.err:2013-11-05 09:14:53.815 lock conflict on no wait
log_ins_CSMIRROR_113.err:2013-11-05 06:37:11.393 lock conflict on no wait
log_ins_CSMIRROR_123.err:2013-11-05 05:18:08.003 lock conflict on no wait
log_ins_CSMIRROR_139.err:2013-11-05 11:44:59.581 lock conflict on no wait
log_ins_CSMIRROR_158.err:2013-11-05 05:47:45.128 lock conflict on no wait
log_ins_CSMIRROR_162.err:2013-11-05 05:18:46.471 lock conflict on no wait
log_ins_CSMIRROR_169.err:2013-11-05 06:36:06.643 lock conflict on no wait
log_ins_CSMIRROR_170.err:2013-11-05 05:17:23.018 lock conflict on no wait
log_ins_CSMIRROR_174.err:2013-11-05 05:49:29.034 lock conflict on no wait
log_ins_CSMIRROR_189.err:2013-11-05 08:11:27.003 lock conflict on no wait
log_ins_CSMIRROR_199.err:2013-11-05 10:14:08.253 lock conflict on no wait
log_ins_CSMIRROR_204.err:2013-11-05 12:46:01.268 lock conflict on no wait
log_ins_CSMIRROR_205.err:2013-11-05 04:42:37.565 lock conflict on no wait
log_ins_CSMIRROR_253.err:2013-11-05 05:11:15.987 lock conflict on no wait
log_ins_CSMIRROR_257.err:2013-11-05 07:28:44.878 lock conflict on no wait
log_ins_CSMIRROR_264.err:2013-11-05 07:09:20.003 lock conflict on no wait
log_ins_CSMIRROR_277.err:2013-11-05 11:12:56.253 lock conflict on no wait
log_ins_CSMIRROR_282.err:2013-11-05 11:45:59.143 lock conflict on no wait
log_ins_CSMIRROR_296.err:2013-11-05 05:20:19.659 lock conflict on no wait
log_ins_CSMIRROR_300.err:2013-11-05 03:47:47.612 lock conflict on no wait
log_ins_CSMIRROR_301.err:2013-11-05 04:00:22.081 lock conflict on no wait
log_ins_CSMIRROR_310.err:2013-11-05 05:49:29.003 lock conflict on no wait
log_ins_CSMIRROR_311.err:2013-11-05 03:51:29.690 lock conflict on no wait
log_ins_CSMIRROR_322.err:2013-11-05 09:37:24.628 lock conflict on no wait
log_ins_CSMIRROR_334.err:2013-11-05 06:47:24.612 lock conflict on no wait
log_ins_CSMIRROR_341.err:2013-11-05 05:06:24.675 lock conflict on no wait
log_ins_CSMIRROR_348.err:2013-11-05 06:40:21.003 lock conflict on no wait
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38453094
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 dimitr: а можно ли сбацать какой-нибудь хитрый патч (только для этого варианта теста), чтобы он вываливал дамп и всю прочую инфу, как только в движке возникает lock conflict ?
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38453136
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PS. И еще.

1. Вылезли также ошибки инвалидных усеров-паролей:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
log_ins_CSMIR_147.err:2013-11-05 06:42:49.581 Your user name and password are not defined.
log_ins_CSMIR_110.err:2013-11-05 06:51:27.081 Your user name and password are not defined.
log_ins_TLPRG_034.err:2013-11-05 07:17:13.203 Your user name and password are not defined.
log_ins_TLPRG_076.err:2013-11-05 07:45:48.656 Your user name and password are not defined.
log_ins_CSMIR_144.err:2013-11-05 07:31:16.565 Your user name and password are not defined.
log_ins_CSMIR_148.err:2013-11-05 08:00:59.096 Your user name and password are not defined.
log_ins_CSMIR_078.err:2013-11-05 08:41:41.221 Your user name and password are not defined.
log_ins_CSMIR_107.err:2013-11-05 08:45:47.112 Your user name and password are not defined.
log_ins_CSMIR_233.err:2013-11-05 09:25:32.346 Your user name and password are not defined.
log_ins_CSMIR_193.err:2013-11-05 10:36:09.659 Your user name and password are not defined.
log_ins_CSMIR_221.err:2013-11-05 10:59:17.393 Your user name and password are not defined.
log_ins_CSMIR_339.err:2013-11-05 12:46:50.096 Your user name and password are not defined.

2 . Сейчас у меня есть вспомогательная база с результатами логирования вызовов isql батником (батник записывал в лог результат команды echo %time% непосредственно перед вызовом isql на каждой итерации; лог этот был обработан и загружен в .fdb).
Таким обр., можно точно понять, каким было максимальное число isql'ей, выстраивавшихся в очередь на аттач к базе. На интервале 0.01 сек максимальные очереди возникали в следующие моменты времени (показаны первые 10 строк по убыванию `cnt`):

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
DTS                   CNT
============ ============
02:06:20.000           16
02:58:47.650           16
02:09:48.000           15
02:06:20.010           13
02:53:44.970           12
06:05:00.700           12
01:53:18.640           11
02:30:40.760           11
03:38:36.700           11
01:45:31.300           10
(тест был из 450 окон-молотилок, все делали только инсерты, каждая молотилка после дисконнекта уходила в случайно выбираемую паузу в диапазоне от 10 до 30 сек).

Как видим, никакой связи между появлением ошибки 'invalid user/password' и числом isql'ей в очереди нет.
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38453145
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
До тех пор, пока Алекс не скажет, что с секюрити всё ок, я даже думать не буду об этом.
Займись чем-то другим, неужели нет более важных задач ?
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38453266
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladДо тех пор, пока Алекс не скажет, что с секюрити всё ок, я даже думать не буду об этом.Алексу по поводу invalid user/password'a я сигналил еще до выходных. Сам жду от него ответа по этой теме.
hvladЗаймись чем-то другим, неужели нет более важных задач ?Да заняться-то мне всегда есть чем.
Ладно. Тест есть уже у четверых (три Источника Света и Денис), поддать с его помощью средний или сильный "жар" и получить ошибки - дело нескольких часов.
Когда и если надо будет - сами сможете во всём убедиться.
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38453269
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидВылезли также ошибки инвалидных усеров-паролей:
Выкинь вообще из схемы security пока она сырая - запускай свои тесты в Embedded режиме.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38453303
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovТаблоидВылезли также ошибки инвалидных усеров-паролей:
Выкинь вообще из схемы security пока она сырая - запускай свои тесты в Embedded режиме.
да хрен с ней, с этой сек3.фдб! ты мну ответь лучше, как такое может быть, что lock conflict'ы лезут ? они НЕ связаны с секурити3.
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38453309
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

с чего ты взял? Мне не известно что там делается в security, но могу предположить что там есть внутренние запросы и не факт что только SELECT.
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38453321
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов Денисс чего ты взял? Мне не известно что там делается в security, но могу предположить что там есть внутренние запросы и не факт что только SELECT.А эти "внутренние запросы" - они в трейсе должны быть видны или нет (я про ФБ-3.х) ?
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38453325
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоидты мну ответь лучше, как такое может быть, что lock conflict'ы лезут ? они
НЕ связаны с секурити3.
Во-первых, ты не путай "lock conflict" и "update conflict".
Во-вторых, с чего ты так уверен, что они не связаны?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38453329
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

по уму не должны иначе секьюрность фиговая будет.
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38453353
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dimitry SibiryakovТаблоидты мну ответь лучше, как такое может быть, что lock conflict'ы лезут ? они
НЕ связаны с секурити3.
Во-первых, ты не путай "lock conflict" и "update conflict".
Во-вторых, с чего ты так уверен, что они не связаны?1) вижу, что по времени нет никакой связи, вообще (между lock conflict'ами и invalid u/p)
2) помню - 100% - что этот самый lock conflict вылезал на ЭТОМ ЖЕ тесте, на ИНСЕРТАХ, в 2010-2011, когда шла борьба в 2.5.х с missing entries.
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38453602
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Только сейчас понял, что он 3.0 тестировал. Тьфу..

Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38453633
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 ГР: всем нечитателям посвящается... :-) http://www.sql.ru/forum/actualutils.aspx?action=gotomsg&tid=1056826&msg=15069553 <...>
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
ISQL Version: WI-V2.5.3.26682 Firebird 2.5
Server version:
Firebird/linux AMD64 (access method), version " LI-T3.0.0.30695  Firebird 3.0 Alpha 1"
Firebird/linux AMD64 (remote server), version "LI-T3.0.0.30695 Firebird 3.0 Alpha 1/tcp (oel64)/P12"
Firebird/x86/Windows NT (remote interface), version "WI-V2.5.3.26682 Firebird 2.5/tcp (CSMIRROR)/P12"
on disk structure version 12.0
Database: 192.168.0.220/3330:idx_test
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38453637
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Во-первых, я уже говорил о том, что это неудачная
форма оформления и указания версии в частности.
Но тогда, IIRC, птицеводы сказали, что кошерно и
понятно - ну если вам удобно, то флаг в руки.

Во-вторых, я понял, что 3.0 не перечитав первый
пост, а увидев ваши диалоги про security-БД и пр.

Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38453640
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Гаджимурадов РустамВо-первых, я уже говорил о том, что это неудачная
форма оформления и указания версии в частности.поясни, плз: чем она плохая ?
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38453666
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

тем что в глаза бросается первая строчка, а в ней указана версия клиента. Которая кстати 2.5.
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38453678
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов Денистем что в глаза бросается первая строчка, а в ней указана версия клиента. Которая кстати 2.5.Слабоватый аргумент. Не верю, что завсегдатаи ФБ-кабачка не читают дальше первой строки. Хотя согласен в том, что версию клиента лучше задвинуть в подвал, она обычно не так важна, как версия сервера.
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38453691
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

ты пробовал ставить Fb3 на CentOS? Есть ли какие-нибудь грабли?
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38453693
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов Денисты пробовал ставить Fb3 на CentOS? Есть ли какие-нибудь грабли?нет, CentOS я в глаза не видел.
Но прошёл все круги адцтва при установке ФБ-3 на Oracle Ent Linux. На всякий случай: будь готов, что постоянно чего-то не хватает.
А также, что требуется какой-то там пакет версии именно 12.6, а не 12.6.3 (!!), ну и к прочим прелестям.
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38453709
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид> поясни, плз: чем она плохая ?

Всем, кроме того, что она "стандартна" и её легко копипастить.

Сравни твой


ISQL Version: WI-V2.5.3.26682 Firebird 2.5Server version:Firebird/linux AMD64 (access method), version "LI-T3.0.0.30695 Firebird
3.0 Alpha 1"Firebird/linux AMD64 (remote server), version "LI-T3.0.0.30695 Firebird 3.0 Alpha 1/tcp
(oel64)/P12"Firebird/x86/Windows NT (remote interface), version "WI-V2.5.3.26682 Firebird 2.5/tcp (CSMIRROR)/P12"on disk structure
version 12.0Database: 192.168.0.220/3330:idx_test
и простой (зачёркнутое - опционально, как и инфа о клиенте)
FB
Linux.64 3.0.0.30695 TCP
Какой нагляднее и понятнее?

Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38453710
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Разметка съехала (неправильные переносы строк).

Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38453742
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

да вроде установка прошла успешно, особых танцев с бубном не было. Единственное чего не хватало libtommath.so
Правда я устанавливал не из исходников.
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38453842
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов ДенисЕдинственное чего не хватало libtommath.so
Правда я устанавливал не из исходников.Повезло (что не хватало только этой библы).
Есть, впрочем, смутное подозрение, что если бы ты ставил из исходников, то всё равно её пришлось бы ставить.

Ну, так что ? Запустил тест на инсерты ?
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38453853
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидСисдба МастеркеевичЕсли есть подозрение, что виноваты инсерты, надо попробовать без них.Была такая мысль, еще вчера. Запущу сегодня, попозже.Запустил снова 450 молотилок, каждая из которых делает вот такой оф-фигительный скрипт:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
117.
118.
119.
120.
121.
122.
123.
124.
125.
126.
127.
128.
129.
130.
131.
132.
133.
134.
135.
136.
137.
138.
139.
140.
141.
142.
143.
144.
145.
146.
147.
148.
149.
150.
151.
152.
153.
154.
155.
156.
157.
158.
159.
160.
161.
162.
163.
164.
165.
166.
167.
168.
169.
170.
171.
172.
173.
174.
175.
176.
177.
178.
179.
180.
181.
182.
183.
184.
185.
186.
187.
188.
189.
190.
191.
192.
193.
194.
195.
196.
197.
198.
199.
200.
201.
202.
203.
204.
205.
206.
207.
208.
209.
210.
211.
212.
213.
set warnings off; set sql dialect 3; 
--show version; 
--show database; 
set heading off; set list off;  
select '-- PACKET # 1:' BEGIN_SECTION from rdb$database; commit;  
COMMIT;
SET TRANSACTION READ WRITE READ COMMITTED RECORD_VERSION NO WAIT;
commit;

shell rndpause.bat;
set heading off; set list off;  
select '-- PACKET # 2:' BEGIN_SECTION from rdb$database; commit;  
COMMIT;
SET TRANSACTION READ WRITE READ COMMITTED RECORD_VERSION NO WAIT;
commit;

shell rndpause.bat;
set heading off; set list off;  
select '-- PACKET # 3:' BEGIN_SECTION from rdb$database; commit;  
COMMIT;
SET TRANSACTION READ WRITE READ COMMITTED RECORD_VERSION NO WAIT;
commit;

shell rndpause.bat;
set heading off; set list off;  
select '-- PACKET # 4:' BEGIN_SECTION from rdb$database; commit;  
COMMIT;
SET TRANSACTION READ WRITE READ COMMITTED RECORD_VERSION NO WAIT;
commit;

shell rndpause.bat;
set heading off; set list off;  
select '-- PACKET # 5:' BEGIN_SECTION from rdb$database; commit;  
COMMIT;
SET TRANSACTION READ WRITE READ COMMITTED RECORD_VERSION NO WAIT;
commit;

shell rndpause.bat;
set heading off; set list off;  
select '-- PACKET # 6:' BEGIN_SECTION from rdb$database; commit;  
COMMIT;
SET TRANSACTION READ WRITE READ COMMITTED RECORD_VERSION NO WAIT;
commit;

shell rndpause.bat;
set heading off; set list off;  
select '-- PACKET # 7:' BEGIN_SECTION from rdb$database; commit;  
COMMIT;
SET TRANSACTION READ WRITE READ COMMITTED RECORD_VERSION NO WAIT;
commit;

shell rndpause.bat;
set heading off; set list off;  
select '-- PACKET # 8:' BEGIN_SECTION from rdb$database; commit;  
COMMIT;
SET TRANSACTION READ WRITE READ COMMITTED RECORD_VERSION NO WAIT;
commit;

shell rndpause.bat;
set heading off; set list off;  
select '-- PACKET # 9:' BEGIN_SECTION from rdb$database; commit;  
COMMIT;
SET TRANSACTION READ WRITE READ COMMITTED RECORD_VERSION NO WAIT;
commit;

shell rndpause.bat;
set heading off; set list off;  
select '-- PACKET # 10:' BEGIN_SECTION from rdb$database; commit;  
COMMIT;
SET TRANSACTION READ WRITE READ COMMITTED RECORD_VERSION NO WAIT;
commit;

shell rndpause.bat;
set heading off; set list off;  
select '-- PACKET # 11:' BEGIN_SECTION from rdb$database; commit;  
COMMIT;
SET TRANSACTION READ WRITE READ COMMITTED RECORD_VERSION NO WAIT;
commit;

shell rndpause.bat;
set heading off; set list off;  
select '-- PACKET # 12:' BEGIN_SECTION from rdb$database; commit;  
COMMIT;
SET TRANSACTION READ WRITE READ COMMITTED RECORD_VERSION NO WAIT;
commit;

shell rndpause.bat;
set heading off; set list off;  
select '-- PACKET # 13:' BEGIN_SECTION from rdb$database; commit;  
COMMIT;
SET TRANSACTION READ WRITE READ COMMITTED RECORD_VERSION NO WAIT;
commit;

shell rndpause.bat;
set heading off; set list off;  
select '-- PACKET # 14:' BEGIN_SECTION from rdb$database; commit;  
COMMIT;
SET TRANSACTION READ WRITE READ COMMITTED RECORD_VERSION NO WAIT;
commit;

shell rndpause.bat;
set heading off; set list off;  
select '-- PACKET # 15:' BEGIN_SECTION from rdb$database; commit;  
COMMIT;
SET TRANSACTION READ WRITE READ COMMITTED RECORD_VERSION NO WAIT;
commit;

shell rndpause.bat;
set heading off; set list off;  
select '-- PACKET # 16:' BEGIN_SECTION from rdb$database; commit;  
COMMIT;
SET TRANSACTION READ WRITE READ COMMITTED RECORD_VERSION NO WAIT;
commit;

shell rndpause.bat;
set heading off; set list off;  
select '-- PACKET # 17:' BEGIN_SECTION from rdb$database; commit;  
COMMIT;
SET TRANSACTION READ WRITE READ COMMITTED RECORD_VERSION NO WAIT;
commit;

shell rndpause.bat;
set heading off; set list off;  
select '-- PACKET # 18:' BEGIN_SECTION from rdb$database; commit;  
COMMIT;
SET TRANSACTION READ WRITE READ COMMITTED RECORD_VERSION NO WAIT;
commit;

shell rndpause.bat;
set heading off; set list off;  
select '-- PACKET # 19:' BEGIN_SECTION from rdb$database; commit;  
COMMIT;
SET TRANSACTION READ WRITE READ COMMITTED RECORD_VERSION NO WAIT;
commit;

shell rndpause.bat;
set heading off; set list off;  
select '-- PACKET # 20:' BEGIN_SECTION from rdb$database; commit;  
COMMIT;
SET TRANSACTION READ WRITE READ COMMITTED RECORD_VERSION NO WAIT;
commit;

shell rndpause.bat;
set heading off; set list off;  
select '-- PACKET # 21:' BEGIN_SECTION from rdb$database; commit;  
COMMIT;
SET TRANSACTION READ WRITE READ COMMITTED RECORD_VERSION NO WAIT;
commit;

shell rndpause.bat;
set heading off; set list off;  
select '-- PACKET # 22:' BEGIN_SECTION from rdb$database; commit;  
COMMIT;
SET TRANSACTION READ WRITE READ COMMITTED RECORD_VERSION NO WAIT;
commit;

shell rndpause.bat;
set heading off; set list off;  
select '-- PACKET # 23:' BEGIN_SECTION from rdb$database; commit;  
COMMIT;
SET TRANSACTION READ WRITE READ COMMITTED RECORD_VERSION NO WAIT;
commit;

shell rndpause.bat;
set heading off; set list off;  
select '-- PACKET # 24:' BEGIN_SECTION from rdb$database; commit;  
COMMIT;
SET TRANSACTION READ WRITE READ COMMITTED RECORD_VERSION NO WAIT;
commit;

shell rndpause.bat;
set heading off; set list off;  
select '-- PACKET # 25:' BEGIN_SECTION from rdb$database; commit;  
COMMIT;
SET TRANSACTION READ WRITE READ COMMITTED RECORD_VERSION NO WAIT;
commit;

shell rndpause.bat;
set heading off; set list off;  
select '-- PACKET # 26:' BEGIN_SECTION from rdb$database; commit;  
COMMIT;
SET TRANSACTION READ WRITE READ COMMITTED RECORD_VERSION NO WAIT;
commit;

shell rndpause.bat;
set heading off; set list off;  
select '-- PACKET # 27:' BEGIN_SECTION from rdb$database; commit;  
COMMIT;
SET TRANSACTION READ WRITE READ COMMITTED RECORD_VERSION NO WAIT;
commit;

shell rndpause.bat;
set heading off; set list off;  
select '-- PACKET # 28:' BEGIN_SECTION from rdb$database; commit;  
COMMIT;
SET TRANSACTION READ WRITE READ COMMITTED RECORD_VERSION NO WAIT;
commit;

shell rndpause.bat;
set heading off; set list off;  
select '-- PACKET # 29:' BEGIN_SECTION from rdb$database; commit;  
COMMIT;
SET TRANSACTION READ WRITE READ COMMITTED RECORD_VERSION NO WAIT;
commit;

shell rndpause.bat;
set heading off; set list off;  
select '-- PACKET # 30:' BEGIN_SECTION from rdb$database; commit;  
COMMIT;
SET TRANSACTION READ WRITE READ COMMITTED RECORD_VERSION NO WAIT;
commit;

shell rndpause.bat;
(всё правильно, глаза вас не подводят: в скрипте нет не только инсертов, но и вообще execute block'ов; только 30 одинаковых кусков с однократным select'ом из rdb$database и коммитами, между которыми - shell-вызов батника с пингом локалхоста в несколько секунд).

Заодно запустил:
1) калибратор скорости коннектов, интервал его работы между возвратом из isql и стартом новой попытки коннекта = 5 сек (он пока что отловил только одного "полу-тупицу", который устанавливался 1104 мс; посмотрим, что будет утром);
2) скрипт, сканирующий .err-логи на наличие ошибок с текстом 'lock conflict' и/или 'password';
3) скрипт, логирующий аппетит процесса firebird (просто так, до кучи: кушать не просит, а какую-то инфу всё-таки даст):

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
$ cat fb_memo_watch.sh
log=fb_memo_$(date +'%y%m%d_%H%M%S').log
rm -f $log
while :
do
  supertee -a -n $log echo $(date +'%y%m%d_%H%M%S') $(pmap -d $(pgrep firebird)|tail -1)
  sleep 1
done

Посмотрим утром, что там будет в итоге.
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38453933
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидПосмотрим утром, что там будет в итоге....а в итоге следующее:
1) .err-логи молотилок не содержат ни одного возгласа на тему 'lock conflict' или 'invalid password';

2) калибратор скорости установки коннектов показывает следующие топ-10 тормозов, которые были за минувшие 6 часов:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
2013-11-06 07:37:15.0211 pure time of connect: 6034 ms, threads: 269
2013-11-06 07:33:46.2151 pure time of connect: 5904 ms, threads: 268
2013-11-06 07:37:34.5292 pure time of connect: 5805 ms, threads: 293
2013-11-06 06:50:38.9750 pure time of connect: 5533 ms, threads: 299
2013-11-06 06:38:55.4584 pure time of connect: 5275 ms, threads: 249
2013-11-06 07:34:38.4243 pure time of connect: 4997 ms, threads: 264
2013-11-06 06:11:03.1868 pure time of connect: 4840 ms, threads: 208
2013-11-06 05:28:11.9191 pure time of connect: 4770 ms, threads: 297
2013-11-06 07:31:43.4990 pure time of connect: 4737 ms, threads: 218
2013-11-06 07:35:30.6731 pure time of connect: 4700 ms, threads: 227
('pure time of connect' = дельта в ms между временем "закладки" в текст системного времени непосредственно перед вызовом isql и временем считывания этого же текста "внутри" процедуры, которую вызывает калибратор; 'threads' подсчитываются так: ps -FLC firebird | wc -l)

3) Потребление памяти (кому интересно - вот статья , тынц на которую дал Источник Света):

3.1) сразу после загрузки ФБ, до старта теста:
Код: plaintext
131106_002646 mapped: 217904K  writeable/private: 34'024K  shared: 28K

3.2) Все 450 молотилок окончательно загрузились в 00:36:40 (по данным лога с наибольшим "номером"), при этом:
Код: plaintext
131106_003700 mapped: 8411336K  writeable/private: 2'229'248K  shared: 5888K

3.3) несколько промежуточных точек:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
131106_010000 mapped: 7692188K writeable/private: 1567724K shared: 7520K
131106_013000 mapped: 8954060K writeable/private: 2831796K shared: 5392K
131106_020000 mapped: 8223248K writeable/private: 2102776K shared: 4688K
131106_023000 mapped: 8255740K writeable/private: 2134780K shared: 5208K
131106_030000 mapped: 8161192K writeable/private: 2040860K shared: 5344K
131106_033000 mapped: 8491692K writeable/private: 2373196K shared: 4208K
131106_040000 mapped: 10172012K writeable/private: 4050172K shared: 7640K
131106_043000 mapped: 9163752K writeable/private: 3044020K shared: 6424K
131106_050000 mapped: 8881236K writeable/private: 2761100K shared: 7480K
131106_053000 mapped: 9531136K writeable/private: 3413468K shared: 5464K
131106_060000 mapped: 9576236K writeable/private: 3457260K shared: 7176K
131106_063000 mapped: 9457016K writeable/private: 3338328K shared: 7544K
131106_070000 mapped: 9746652K writeable/private: 3630616K shared: 5776K

3.4) сейчас:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
131106_071811 mapped: 9479404K  writeable/private: 3'362'084K  shared: 7336K
131106_071812 mapped: 9473756K writeable/private: 3357092K shared: 6680K
131106_071813 mapped: 9473604K writeable/private: 3357668K shared: 5952K
131106_071814 mapped: 9474484K writeable/private: 3359268K shared: 5232K
131106_071815 mapped: 9465708K writeable/private: 3351204K shared: 4520K
131106_071816 mapped: 9459716K writeable/private: 3345444K shared: 4288K
<...>
131106_073836 mapped: 10142572K writeable/private: 4027064K shared: 5752K
131106_073837 mapped: 10144308K writeable/private: 4028344K shared: 6208K
131106_073838 mapped: 10135884K writeable/private: 4019512K shared: 6616K
131106_073839 mapped: 10126844K writeable/private: 4010040K shared: 7040K
131106_073840 mapped: 10118156K writeable/private: 4001016K shared: 7384K
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38453941
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Да, и еще. По поводу времени установки коннекта.
(я знаю, что жутко надоел с этим всем Источникам Света, но всё-таки проблема эта существует, и не в моей голове, а натурально; так что извиняйте, но поэма будет продолжена!.. :))

Если затолкать в базу моменты времени вызовов isql'ей (а они складываются в лог батником, который вызывается молотилками: echo %time% >> %this_window_log% ) и затем сгруппировать записи, то получаем число isql'ей, которые выстраивались в очередь на установку коннекта в интервалах времени = 0.01 сек .
Наибольшие очереди на интервалах 0.01 сек были такими:
~40 строк
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
SQL> select * from (select dts,count(*) cnt from attlog group by dts having count(*)>=10) order by dts;

0:39:45.80             11
0:46:06.37             12
0:49:27.87             10
1:01:55.67             10
1:25:39.01             16
1:33:33.03             10
1:46:21.06             23
1:46:21.08             15
2:17:48.90             12
2:18:20.30             14
2:24:28.11             10
2:26:00.22             14
2:26:00.25             10
2:32:13.50             10
2:52:01.34             11
2:52:42.19             12
2:56:18.36             14
3:08:10.62             10
3:08:32.47             16
3:16:49.78             11
3:54:01.53             17
3:58:40.47             10
4:02:47.55             14
4:02:54.64             11
4:15:17.19             11
4:15:42.14             10
4:18:56.65             10
4:33:53.51             10
4:36:50.40             14
4:47:05.00             11
4:59:18.45             10
5:11:34.95             14
6:10:26.23             13
6:21:16.50             10
6:21:26.09             13
6:29:07.83             17
6:53:15.87             11
6:56:19.89             17
7:24:40.42             12
7:36:01.20             20
7:44:04.87             11
Сопоставляя это с тем, что фиксировал калибратор:
top-10 коннектов, устанавливавшихся дольше всего
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
2013-11-06 07:37:15.0211 pure time of connect: 6034 ms, threads: 269
2013-11-06 07:33:46.2151 pure time of connect: 5904 ms, threads: 268
2013-11-06 07:37:34.5292 pure time of connect: 5805 ms, threads: 293
2013-11-06 06:50:38.9750 pure time of connect: 5533 ms, threads: 299
2013-11-06 06:38:55.4584 pure time of connect: 5275 ms, threads: 249
2013-11-06 07:34:38.4243 pure time of connect: 4997 ms, threads: 264
2013-11-06 06:11:03.1868 pure time of connect: 4840 ms, threads: 208
2013-11-06 05:28:11.9191 pure time of connect: 4770 ms, threads: 297
2013-11-06 07:31:43.4990 pure time of connect: 4737 ms, threads: 218
2013-11-06 07:35:30.6731 pure time of connect: 4700 ms, threads: 227
- видим, что когда возникала тупизна при установке коннектов, то очередь isql'ей на вход в ФБ *не* превышала 10.

А вот результат группировки на интервалах = 1.00 сек для моментов времени, соотв-щих тупым коннектам:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
 07:37:15 .0211 pure time of connect: 6034 ms
SQL> select sec,count(*) cnt from attlog where sec between '7:37:10' and '7:37:20' group by sec ;

7:37:14             2
7:37:16             4
7:37:19             2
7:37:20             5

-------

 07:33:46 .2151 pure time of connect: 5904 ms
SQL> select sec,count(*) cnt from attlog where sec between '7:33:40' and '7:33:50' group by sec ;

7:33:42             4
7:33:43             2
7:33:44             2
7:33:46             2
7:33:48             3
7:33:50             3

-------

 07:37:34 .5292 pure time of connect: 5805 ms
SQL> select sec,count(*) cnt from attlog where sec between '7:37:30' and '7:37:40' group by sec ;

7:37:30             3
7:37:31             6
7:37:32             4
7:37:33             2
7:37:34             6
7:37:35             6
7:37:36             4
7:37:39             2

-------

 06:50:38 .9750 pure time of connect: 5533 ms
SQL> select sec,count(*) cnt from attlog where sec between '6:50:33' and '6:50:43' group by sec ;

6:50:33             4
6:50:34             3
6:50:35             2
6:50:39             6
6:50:40             7
6:50:41             3
6:50:43             8

-------

 06:38:55 .4584 pure time of connect: 5275 ms
SQL> select sec,count(*) cnt from attlog where sec between '6:38:53' and '6:38:58' group by sec ;

6:38:53             2
6:38:54             2
6:38:56             4
6:38:57             5
6:38:58             7
Число isql'ей, находившихся в очереди на установку коннекта в те моменты, когда возникала тупизна свыше 5 сек, не превышало 6-7.
Сервак не мог быть загружен даже на 5% тем дурацким скриптом, который приведен тут . Там одни commit'ы!

Причина внезапных тормозов при установке коннектов, увы, так и остается пока загадкой.
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38453949
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

нет ещё не запускал. Пока только подготовил всё. Установил FB, добавил дополнительный виртуальный диск, пробросил сеть.

Я так понял ты мониторинг снимал с linux, а сам тест на винде запускал? Или это не обязательно.
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38453953
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

по поводу скорости установки коннектов я говорил что через srp оно значительно ниже. И даже приводил тест. Мне ответили, что в этом виновата процедура генерации ключа и обмена ключами. Также замедление может вызывать шифрование (но значительного замедления я там не заметил ~10%), а вот сами коннекты в 3 раза медленней.

По поводу провалов скорости коннектов ничего сказать не могу.
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38453958
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов ДенисЯ так понял ты мониторинг снимал с linux, а сам тест на винде запускал? Или это не обязательно.Скрипт калибратора коннектов, а также скрипт-наблюдатель за расходом памяти ФБ - да, на консоли линуха. Молотилки и скрипты, которые "смотрят" в их .err-логи - на виндузе.
Батник, который вертит молотилками (t004dml.bat) и запускалка его (t004act.bat) есть в линуксовом варианте, но я его не запускал и даже еще не смотрел (его мне прислал Алекс). Если надо этот вариант - сообщи.
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38453962
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов Дениспо поводу скорости установки коннектов я говорил что через srp оно значительно ниже. И даже приводил тест. Мне ответили, что в этом виновата процедура генерации ключа и обмена ключами. Также замедление может вызывать шифрование (но значительного замедления я там не заметил ~10%), а вот сами коннекты в 3 раза медленней.Да эта хрень и год взад была, на 2.5. еще.
Картина одна и та же: коннекты даже при сильной нагрузке спокойно укладываются в 500-1500 мс (это вполне приемлемое время!), а дальше - БАЦ! - застревание на 4-5 сек или 10 сек, или еще больше. И так длится 1-2 минуты, после чего "отпускает". И моменты времени этого "приступа" никак и ни с чем не связаны: ни с данными iostat'a, ни с инфой top'a, ни с числом isql'ей в очереди (как выяснилось).
Одно только нарыл (недавно): в каждом случае, когда коннект застревает более чем на 20-30 сек, рост размера .fdb прекращается на некоторые промежутки времени (10-15 сек, иногда таких "плато" два).
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38453966
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

пришли на мыло. Так будет проще и можно будет влияние сети (виртуальной) исключить.

ТаблоидПовезло (что не хватало только этой библы).
Есть, впрочем, смутное подозрение, что если бы ты ставил из исходников, то всё равно её пришлось бы ставить

Просто RHEL заточен под Oracle, а вот зато всё остальное на нём работает с большим геморроем.

P.S. После установки Oracle 10 R2 на RHEL - установка FB просто праздник. Да и как ни странно на CentOS оракля встала с меньшим геморром.
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38453984
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов Дениспришли на мыло.чек мыл.
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38453988
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

письмо пришло. Спасибо.
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38454445
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сисдба МастеркеевичЕсли есть подозрение, что виноваты инсерты, надо попробовать без них.Проверил еще и такой вариант:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
set warnings off; set sql dialect 3;
show version;
show database;
set heading off; set list off;
select '-- PACKET # 1:' BEGIN_SECTION from rdb$database; commit;
COMMIT;
SET TRANSACTION READ WRITE READ COMMITTED RECORD_VERSION NO WAIT;
insert into tmp(id,f00,f01,f02,f03,f04,f05,f06,f07,f08,f09,f10,f11,dt1) values(1267083,32,56,70,57,76,6,7
1,-1267083,1267083,69,68,40,'2012-03-01 03:00:00.0000');

<. . . дальше пятьсот аналогичных строк . . .>

commit;

shell rndpause.bat;
set heading off; set list off;
select '-- PACKET # 2:' BEGIN_SECTION from rdb$database; commit;
COMMIT;
SET TRANSACTION READ WRITE READ COMMITTED RECORD_VERSION NO WAIT;
insert into tmp(id,f00,f01,f02,f03,f04,f05,f06,f07,f08,f09,f10,f11,dt1) values(1267083,32,56,70,57,76,6,7
1,-1267083,1267083,69,68,40,'2012-03-01 03:00:00.0000');

<. . . дальше снова пятьсот аналогичных строк . . .>

commit;

shell rndpause.bat;
set heading off; set list off;

<. . . и так далее до 30-го пакета . . .>


Молотьба идёт несколько часов, 450 окон. Сообщений 'lock conflict' или 'invalid password' в .err-логах НЕТ.
Начинает терзать смутное сомнение: а не может ли быть причина в... наличии конструкции "execute block", внутри которой (-го) был цикл с аналогичными insert'ами ?!
Другой кандидатуры вроде бы уже не остаётся...
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38454495
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид,

у тебя в том блоке insert'ы с suspend'ами перемешаны
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38455167
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Симонов Денису тебя в том блоке insert'ы с suspend'ами перемешаныПопробовал пустые execute block'и, без returns(msg varchar(...)) -эффекта нет, ошибка не вылазит.
Сейчас немного усложнил: добавил returns, suspend, но пока без самих insert'ов и без обработчика 'when any':
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
COMMIT;
SET TRANSACTION READ WRITE READ COMMITTED RECORD_VERSION NO WAIT;
set heading off;
set list off;
set term ^;

execute block returns(msg varchar(200)) as
begin
  msg=
    '-- attach_id='||current_connection||', intro .sql at '
    ||cast('now' as timestamp);
    --||', init gen_test='||gen_id(gen_test,0);
  suspend;
end

^set term ;^
commit;

--select 'Take some pause at '||cast('now' as timestamp) msg from rdb$database;
shell rndpause.bat;
--select 'Pause is over   at '||cast('now' as timestamp) msg from rdb$database;

Запустил всё те же 450 молотилок, буду подождать.
(пфф... не ошибка, а оборотень какой-то... хрен поймёшь, когда и на чём вылезет...)
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38455189
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоидне ошибка, а оборотень какой-то... хрен поймёшь, когда и на чём вылезет...

Так и будет пока разработчики не разроют эту братскую могилу и не идентифицируют трупы. То
бишь пока не добавят уточняющей информации в сообщение.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38455202
NickDee
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Таблоид(пфф... не ошибка, а оборотень какой-то... хрен поймёшь, когда и на чём вылезет...)
Инструмент не умеет нормально показывать инфу об ошибках. Главный баг в этом :)
Хорошее решение - научить инструмент нормально показывать инфу об ошибках :)
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38455523
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидЗапустил всё те же 450 молотилок, буду подождать....в общем, встречайте, дамы и господа!
Минимальный вариант, на котором мну удалось получить обе ошибки при молотьбе 450 окон: как lock conflict, так и invalid password.
Тест стартовал 06.11.2013 в 21:50, первая из них (lock conflict) случилась 07.11.2013 в 08:29, вторая - только что, в 08:44. Ошибки произошли в разных окнах, более того - на разных компах.
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
set warnings off; set sql dialect 3; 
--show version; 
--show database; 
set heading off; set list off;  
select '-- PACKET # 1:' BEGIN_SECTION from rdb$database; commit;  

COMMIT;
SET TRANSACTION READ WRITE READ COMMITTED RECORD_VERSION NO WAIT;
set heading off;
set list off;
set term ^;

execute block returns(msg varchar(200)) as
  declare i int;
  declare v_inserted_cnt int = 200;
  declare v_result int;
begin
  msg=
    '-- attach_id='||current_connection||', intro .sql at '
    ||cast('now' as timestamp);
  suspend;

  i=0;
  while (i < v_inserted_cnt ) do begin

    begin
       msg='insert into tmp(id,f00,f01,f02,f03,f04,f05,f06,f07,f08,f09,f10,f11,dt1) . . .';

       when any do
       begin
          v_result=gdscode;
          msg='rollback; -- ABORT, gds='||v_result
                ||', i='||i
                ||', curr gen_test='||gen_id(gen_test,0)
                ||' at '||cast('now' as timestamp)||': '
                ||decode(v_result, 
                    335544665, 'violation of PK/UK',
                    335544321, 'num/string ovf',
                    335544345, 'lock on no_wait trn', 
                    335544349, 'dup val in idx', 
                    335544334, 'can`t upd erased row',
                    'UNKNOWN'
                );
          suspend;
          leave;
       end -- when any        
    end
    i=i+1;
  end

end

^set term ;^
commit;

--select 'Take some pause at '||cast('now' as timestamp) msg from rdb$database;
shell rndpause.bat;
--select 'Pause is over   at '||cast('now' as timestamp) msg from rdb$database;

----------------------------------------------------------------------------------
-- далее 30 раз повтор вышеприведенного кода, начиная со строки "set heading off; set list off;" --


Теорема доказана. Это были НЕ insert'ы, и это - главное :-)
ЗЫ. Хорошо, что я сегодня долго спал, а то бы вырубил тест в 8 утра, подумав, что снова ничего не прокатит.
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38455555
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Со скоростью установки коннектов на этом скрипте - веселуха. Форменная.

TOP-20 тормозов за минувшие 11 часов молотьбы:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
2013-11-07 08:20:22.7815 pure time of connect: 25029 ms, threads: 431
2013-11-07 08:44:44.9117 pure time of connect: 25028 ms, threads: 405
2013-11-07 07:05:08.9659 pure time of connect: 19838 ms, threads: 388
2013-11-07 07:15:00.7115 pure time of connect: 10188 ms, threads: 363
2013-11-07 07:36:25.6019 pure time of connect: 10132 ms, threads: 363
2013-11-07 04:48:35.5960 pure time of connect: 9560 ms, threads: 400
2013-11-07 08:52:11.9958 pure time of connect: 9333 ms, threads: 292
2013-11-07 07:29:41.9147 pure time of connect: 9283 ms, threads: 364
2013-11-07 08:35:55.5977 pure time of connect: 8904 ms, threads: 358
2013-11-07 05:04:06.0054 pure time of connect: 8888 ms, threads: 393
2013-11-07 08:38:12.6344 pure time of connect: 8769 ms, threads: 353
2013-11-07 09:00:39.3052 pure time of connect: 8508 ms, threads: 396
2013-11-07 08:55:52.5943 pure time of connect: 8476 ms, threads: 306
2013-11-07 08:31:43.4005 pure time of connect: 8428 ms, threads: 342
2013-11-07 08:32:09.9356 pure time of connect: 8258 ms, threads: 371
2013-11-07 08:33:32.4729 pure time of connect: 8217 ms, threads: 366
2013-11-07 08:06:23.5047 pure time of connect: 8031 ms, threads: 368
2013-11-07 08:49:02.6714 pure time of connect: 7750 ms, threads: 349
2013-11-07 07:47:23.1614 pure time of connect: 7682 ms, threads: 329
2013-11-07 08:13:46.0201 pure time of connect: 7633 ms, threads: 367

Сколько там выстраивалось в очередь isql'ей в эти пиковые моменты - пока не знаю, надо логи заново парсить и в базу текст загружать. Выложу позже.
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38455986
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ТаблоидTOP-20 тормозов за минувшие 11 часов молотьбы:

Код: plaintext
1.
2.
3.
4.
5.
2013-11-07 08:20:22.7815 pure time of connect: 25029 ms, threads: 431
2013-11-07 08:44:44.9117 pure time of connect: 25028 ms, threads: 405
2013-11-07 07:05:08.9659 pure time of connect: 19838 ms, threads: 388
2013-11-07 07:15:00.7115 pure time of connect: 10188 ms, threads: 363
2013-11-07 07:36:25.6019 pure time of connect: 10132 ms, threads: 363
. . .
Сколько там выстраивалось в очередь isql'ей в эти пиковые моменты - пока не знаю, надо логи заново парситьОбработал логи с моментами времени, непосредственно предшествовавшими загрузкам isql'ей. Не вижу (снова) никакой связи между временем самых одиозных затыков (более 10 сек) в числом isql'ей, пребывавших в очереди на аттач: эта самая "очередь" состояла из 1-2 isql'ей.
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
 08:20:22 .7815 pure time of connect:  25029 ms 
SQL> select sec,count(*) cnt from attlog where sec between '08: 20:12 ' and '08: 20:32 ' group by sec ;

08:20:12            2
08:20:14            2
08:20:21            1
08:20:22            1
08:20:23            1
08:20:25            3
08:20:27            1
08:20:28            2

-------

2013-11-07  08:44:44 .9117 pure time of connect: 25028 ms, threads: 405
SQL> select sec,count(*) cnt from attlog where sec between '08: 44:34 ' and '08: 44:54 ' group by sec ;

08:44:39            1
08:44:40            1
08:44:50            2

-------

2013-11-07  07:05:08 .9659 pure time of connect: 19838 ms, threads: 388
SQL> select sec,count(*) cnt from attlog where sec between '07: 04:58 ' and '07: 05:18 ' group by sec ;

07:04:58            2
07:04:59            2
07:05:00            3
07:05:01            1
07:05:02            1
07:05:06            1
07:05:08            2
07:05:09            1
07:05:10            1
07:05:11            2
07:05:12            1
07:05:14            2
07:05:18            3

-------

2013-11-07  07:15:00 .7115 pure time of connect: 10188 ms, threads: 363
SQL> select sec,count(*) cnt from attlog where sec between '07: 14:50 ' and '07: 15:10 ' group by sec ;

07:14:50            2
07:14:51            1
07:14:52            3
07:14:53            1
07:14:54            2
07:14:55            4
07:14:57            3
07:14:58            5
07:14:59            2
07:15:00            5
07:15:01            4
07:15:02            3
07:15:03            5
07:15:04            3
07:15:05            5
07:15:06            3
07:15:07            3
07:15:08            4
07:15:10            2

-------

2013-11-07  07:36:25 .6019 pure time of connect: 10132 ms, threads: 363
SQL> select sec,count(*) cnt from attlog where sec between '07: 36:15 ' and '07: 36:35 ' group by sec ;

07:36:16            1
07:36:17            1
07:36:18            1
07:36:19            1
07:36:20            1
07:36:21            3
07:36:22            3
07:36:23            3
07:36:24            1
07:36:25            1
07:36:26            4
07:36:27            5
07:36:28            3
07:36:29            2
07:36:30            1
07:36:31            2
07:36:32            2
07:36:33            6
07:36:34            5
07:36:35            2
Дальше этот "артефакт" исследовать без Источников Света бессмысленно. Что-то где-то глубоко внутри сидит.
...
Рейтинг: 0 / 0
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38462612
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ищущий да обрящет... Это всё-таки случилось! :-)
...
Рейтинг: 0 / 0
135 сообщений из 135, показаны все 6 страниц
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]