ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
25 сообщений из 135, страница 5 из 6
  5  все
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38453321
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Симонов Денисс чего ты взял? Мне не известно что там делается в security, но могу предположить что там есть внутренние запросы и не факт что только SELECT.А эти "внутренние запросы" - они в трейсе должны быть видны или нет (я про ФБ-3.х) ?
...
Рейтинг: 0 / 0
05.11.2013, 16:29:25
| Ответить | Цитировать | Написать  
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38453325
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
Таблоидты мну ответь лучше, как такое может быть, что lock conflict'ы лезут ? они
НЕ связаны с секурити3.
Во-первых, ты не путай "lock conflict" и "update conflict".
Во-вторых, с чего ты так уверен, что они не связаны?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
05.11.2013, 16:30:56
| Ответить | Цитировать | Написать  
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38453329
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
Таблоид,

по уму не должны иначе секьюрность фиговая будет.
...
Рейтинг: 0 / 0
05.11.2013, 16:33:06
| Ответить | Цитировать | Написать  
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
05.11.2013, 16:41:54
| Ответить | Цитировать | Написать  
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38453602
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гаджимурадов Рустам
Участник
Только сейчас понял, что он 3.0 тестировал. Тьфу..

Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
05.11.2013, 19:12:14
| Ответить | Цитировать | Написать  
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
05.11.2013, 19:42:36
| Ответить | Цитировать | Написать  
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38453637
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гаджимурадов Рустам
Участник
Во-первых, я уже говорил о том, что это неудачная
форма оформления и указания версии в частности.
Но тогда, IIRC, птицеводы сказали, что кошерно и
понятно - ну если вам удобно, то флаг в руки.

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

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

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

ты пробовал ставить Fb3 на CentOS? Есть ли какие-нибудь грабли?
...
Рейтинг: 0 / 0
05.11.2013, 20:47:01
| Ответить | Цитировать | Написать  
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38453693
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Симонов Денисты пробовал ставить Fb3 на CentOS? Есть ли какие-нибудь грабли?нет, CentOS я в глаза не видел.
Но прошёл все круги адцтва при установке ФБ-3 на Oracle Ent Linux. На всякий случай: будь готов, что постоянно чего-то не хватает.
А также, что требуется какой-то там пакет версии именно 12.6, а не 12.6.3 (!!), ну и к прочим прелестям.
...
Рейтинг: 0 / 0
05.11.2013, 20:50:50
| Ответить | Цитировать | Написать  
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
05.11.2013, 21:07:09
| Ответить | Цитировать | Написать  
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38453710
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гаджимурадов Рустам
Участник
Разметка съехала (неправильные переносы строк).

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

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

Ну, так что ? Запустил тест на инсерты ?
...
Рейтинг: 0 / 0
06.11.2013, 00:33:14
| Ответить | Цитировать | Написать  
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
06.11.2013, 00:52:24
| Ответить | Цитировать | Написать  
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
06.11.2013, 07:45:57
| Ответить | Цитировать | Написать  
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
06.11.2013, 08:46:00
| Ответить | Цитировать | Написать  
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38453949
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
Таблоид,

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

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

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

По поводу провалов скорости коннектов ничего сказать не могу.
...
Рейтинг: 0 / 0
06.11.2013, 09:04:16
| Ответить | Цитировать | Написать  
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38453958
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Симонов ДенисЯ так понял ты мониторинг снимал с linux, а сам тест на винде запускал? Или это не обязательно.Скрипт калибратора коннектов, а также скрипт-наблюдатель за расходом памяти ФБ - да, на консоли линуха. Молотилки и скрипты, которые "смотрят" в их .err-логи - на виндузе.
Батник, который вертит молотилками (t004dml.bat) и запускалка его (t004act.bat) есть в линуксовом варианте, но я его не запускал и даже еще не смотрел (его мне прислал Алекс). Если надо этот вариант - сообщи.
...
Рейтинг: 0 / 0
06.11.2013, 09:07:09
| Ответить | Цитировать | Написать  
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
06.11.2013, 09:13:59
| Ответить | Цитировать | Написать  
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38453966
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
Таблоид,

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

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

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

P.S. После установки Oracle 10 R2 на RHEL - установка FB просто праздник. Да и как ни странно на CentOS оракля встала с меньшим геморром.
...
Рейтинг: 0 / 0
06.11.2013, 09:19:53
| Ответить | Цитировать | Написать  
lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
    #38453984
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Симонов Дениспришли на мыло.чек мыл.
...
Рейтинг: 0 / 0
06.11.2013, 09:40:26
| Ответить | Цитировать | Написать  
25 сообщений из 135, страница 5 из 6
  5  все
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / lock conflict при работе 350 аттачей, делающих только insert'ы. Отчего ?
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=40&msg=38453691&tid=1564145]:
 0ms
get settings:
 10ms
get forum list:
 21ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 213ms
get topic data:
 12ms
get forum data:
 3ms
get page messages:
 70ms
get tp. blocked users:
 1ms
others: 225ms
total:  563ms
созд. / загр.: 563ms
x
x
Закрыть


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