ReSQL.ru
     
powered by simpleCommunicator - 2.0.52     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / fbtracemgr: разные мелкие вопросы
25 сообщений из 201, страница 2 из 9
  2  все
fbtracemgr: разные мелкие вопросы
    #37212981
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Дело в том, что мусор не могу теперь собрать... :-)
Вот:
 
Код: 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.
[firebird@firebirdG firebird]$ isql -n test.fdb
Database:  test.fdb
SQL> set stat on;
SQL> delete from tmp where f01 between 50000 and 51000; -- это удалился 1 млн строк из начальных 100 млн
Current memory = 22614088
Delta memory = 17956624
Max memory = 36252496
Elapsed time= 74.39 sec
Cpu = 0.00 sec
Buffers = 512
Reads = 577475
Writes = 573763
Fetches = 5000966
SQL> commit;
Current memory = 4796048
Delta memory = -17818040
Max memory = 36252496
Elapsed time= 0.04 sec
Cpu = 0.00 sec
Buffers = 512
Reads = 1
Writes = 506
Fetches = 1
SQL> select count(*) from tmp;
- висит, зараза, уже минут 20, не меньше... :-( И непонятно, сервер вообще занимается моим запросом или "обслуживает" только fbtracemgr + ... isql!
...
Рейтинг: 0 / 0
12.04.2011, 21:38
| Ответить | Цитировать | Написать  
fbtracemgr: разные мелкие вопросы
    #37212997
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Таблоидб) да, локальный... а что? :-)Ну так какого fb_inet_server'а ты ждёшь ? :-)
Это линукс, тут нет локального протокола, только embedded.
...
Рейтинг: 0 / 0
12.04.2011, 21:49
| Ответить | Цитировать | Написать  
fbtracemgr: разные мелкие вопросы
    #37213002
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
hvladТаблоидб) да, локальный... а что? :-)Ну так какого fb_inet_server'а ты ждёшь ? :-)
Это линукс, тут нет локального протокола, только embedded.тьфу, ёлыпалы... так я и думал, что глупость опять напорол :-)
Но вот скажи всё равно: срубил я этот самый подсчет каунтов в ISQL, выполнил дисконнект из другого окна (ИБЭ).
Теперь никаких подключений к серверу нет, а fbtracemgr всё равно грузит проц! на те же самые 45-47%.
Отчего это ?
 
Код: 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.
top - 21:56:24 up 20 days,  9:44,  8 users,  load average: 1.50, 1.92, 1.92
Tasks: 256 total,   2 running, 254 sleeping,   0 stopped,   0 zombie
Cpu0  :  0.7%us,  0.7%sy,  0.0%ni, 98.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu1  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu2  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu3  :  0.0%us,  0.3%sy,  0.0%ni, 99.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu4  : 11.9%us, 37.9%sy,  0.0%ni, 46.3%id,  0.0%wa,  0.0%hi,  3.9%si,  0.0%st
Cpu5  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu6  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu7  :  5.7%us, 10.5%sy,  0.0%ni, 82.8%id,  0.0%wa,  0.0%hi,  1.0%si,  0.0%st
Mem:  49548000k total, 35035632k used, 14512368k free,    31180k buffers
Swap: 51367828k total,       20k used, 51367808k free, 32223148k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 29299 firebird  20   0  128m 6776 4580 S 47.1  0.0  27:35.81 fbtracemgr 
29317 firebird  20   0 15076 1340  912 R  0.3  0.0   0:09.52 top
 3623 firebird  20   0 97484 2056 1204 S  0.0  0.0   0:23.92 sshd
 3624 firebird  20   0  105m 1844 1400 S  0.0  0.0   0:00.01 bash
 3651 firebird  20   0  115m 2904 1884 S  0.0  0.0   0:15.52 mc
 3653 firebird  20   0  105m 1868 1404 S  0.0  0.0   0:00.01 bash
 8636 firebird  20   0 97484 2060 1204 S  0.0  0.0   0:03.79 sshd
 8637 firebird  20   0  105m 1848 1400 S  0.0  0.0   0:00.00 bash
 8664 firebird  20   0  115m 2756 1860 S  0.0  0.0   0:00.18 mc
 8666 firebird  20   0  105m 1860 1404 S  0.0  0.0   0:00.03 bash
22612 firebird  20   0 97444 2116 1284 S  0.0  0.0   0:00.18 sshd
22613 firebird  20   0  105m 1840 1400 S  0.0  0.0   0:00.00 bash
22640 firebird  20   0  115m 3416 1936 S  0.0  0.0   0:00.10 mc
22642 firebird  20   0  105m 1856 1400 S  0.0  0.0   0:00.00 bash
25702 firebird  20   0 97484 2148 1288 S  0.0  0.0   0:00.53 sshd
25703 firebird  20   0  105m 1840 1400 S  0.0  0.0   0:00.00 bash
25730 firebird  20   0  115m 3068 2016 S  0.0  0.0   0:00.83 mc
25732 firebird  20   0  105m 1860 1404 S  0.0  0.0   0:00.04 bash
25793 firebird  20   0 97484 2148 1288 S  0.0  0.0   0:00.15 sshd
25794 firebird  20   0  105m 1848 1400 S  0.0  0.0   0:00.00 bash
25821 firebird  20   0  115m 3052 2020 S  0.0  0.0   0:00.45 mc
25823 firebird  20   0  105m 1860 1404 S  0.0  0.0   0:00.04 bash
29308 firebird  20   0 73940  14m 5700 S  0.0  0.0   4:26.29 isql
29442 firebird  20   0 97484 2020 1180 S  0.0  0.0   0:00.00 sshd
29443 firebird  20   0  105m 1844 1400 S  0.0  0.0   0:00.00 bash
29470 firebird  20   0  115m 3088 1936 S  0.0  0.0   0:00.16 mc
29472 firebird  20   0  105m 1848 1396 S  0.0  0.0   0:00.00 bash
...
Рейтинг: 0 / 0
12.04.2011, 21:57
| Ответить | Цитировать | Написать  
fbtracemgr: разные мелкие вопросы
    #37213031
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
ТаблоидТеперь никаких подключений к серверу нет, а fbtracemgr всё равно грузит проц! на те же самые 45-47%.Если это не связано с запись лога в файл, то понятия не имею.
Можешь снять с него бектрейс - посмотрим
...
Рейтинг: 0 / 0
12.04.2011, 22:14
| Ответить | Цитировать | Написать  
fbtracemgr: разные мелкие вопросы
    #37213034
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
hvladТаблоидТеперь никаких подключений к серверу нет, а fbtracemgr всё равно грузит проц! на те же самые 45-47%.Если это не связано с запись лога в файл, то понятия не имею.
Можешь снять с него бектрейс - посмотримЭто уже завтра только смогу.
Сейчас повторил, приконнектился через TCP - всё та же значительная загрузка от fbtracemgr и капля отведена на fb_inet_server:
 
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
top - 22:15:17 up 20 days, 10:03,  8 users,  load average: 2.08, 1.25, 1.36
Tasks: 258 total,   1 running, 257 sleeping,   0 stopped,   0 zombie
Cpu0  :  3.8%us, 37.4%sy,  0.0%ni,  9.3%id, 46.4%wa,  0.0%hi,  3.1%si,  0.0%st
Cpu1  :  1.4%us, 14.9%sy,  0.0%ni, 37.5%id, 45.3%wa,  0.0%hi,  1.0%si,  0.0%st
Cpu2  :  2.3%us,  3.7%sy,  0.0%ni, 93.6%id,  0.0%wa,  0.0%hi,  0.3%si,  0.0%st
Cpu3  :  1.1%us,  7.9%sy,  0.0%ni, 90.6%id,  0.0%wa,  0.0%hi,  0.4%si,  0.0%st
Cpu4  :  0.0%us,  0.3%sy,  0.0%ni, 99.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu5  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu6  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu7  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:  49548000k total, 34909588k used, 14638412k free,    32220k buffers
Swap: 51367828k total,       20k used, 51367808k free, 32202440k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 30150 firebird  20   0  127m 5996 4088 S 46.5  0.0   1:32.90 fbtracemgr 
30165 firebird  20   0  135m  10m 5120 S  6.0  0.0   0:36.79 fb_inet_server
...
Рейтинг: 0 / 0
12.04.2011, 22:18
| Ответить | Цитировать | Написать  
fbtracemgr: разные мелкие вопросы
    #37213051
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Последняя попытка: удаляю всё тот же 1 млн строк, но трейс выключен. В топе вижу загрузку ЦПУ от fb_inet_server'a:
1) от оператора delete - только на 50-55%;.
2) от последующего за этим select count(*) from tmp - всего на 17-19%.
Это тоже непонятно: никаких других процессов сейчас на этом серваке нет, что ему мешает загрузить проц по-полной ?
Если затык при count'e из-за очереди на диск, то где он тут, покажите, плз:
 
Код: 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.
top - 22:30:46 up 20 days, 10:19,  8 users,  load average: 0.88, 1.14, 1.41
Tasks: 259 total,   1 running, 258 sleeping,   0 stopped,   0 zombie
Cpu0  :  5.6%us,  7.3%sy,  0.0%ni, 32.8%id, 52.3%wa,  0.0%hi,  2.0%si,  0.0%st
Cpu1  :  1.9%us,  3.2%sy,  0.0%ni, 65.3%id, 29.5%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu2  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu3  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu4  :  0.0%us,  0.3%sy,  0.0%ni, 99.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu5  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu6  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Cpu7  :  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:  49548000k total, 45913316k used,  3634684k free,    34264k buffers
Swap: 51367828k total,       20k used, 51367808k free, 43136944k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
30295 firebird  20   0  135m 9320 4552 S 18.6  0.0   0:57.92 fb_inet_server
29317 firebird  20   0 15076 1340  912 R  0.7  0.0   0:15.11 top
    1 root      20   0 19244 1424 1156 S  0.0  0.0   0:06.91 init
    2 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kthreadd
    3 root      RT   0     0    0    0 S  0.0  0.0   0:00.06 migration/0
    4 root      20   0     0    0    0 S  0.0  0.0  21:52.08 ksoftirqd/0
    5 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 watchdog/0
    6 root      RT   0     0    0    0 S  0.0  0.0   0:00.31 migration/1
    7 root      20   0     0    0    0 S  0.0  0.0   5:46.92 ksoftirqd/1
    8 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 watchdog/1
    9 root      RT   0     0    0    0 S  0.0  0.0   0:00.15 migration/2
   10 root      20   0     0    0    0 S  0.0  0.0   4:49.02 ksoftirqd/2
...
Рейтинг: 0 / 0
12.04.2011, 22:32
| Ответить | Цитировать | Написать  
fbtracemgr: разные мелкие вопросы
    #37213094
miwaonline
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
miwaonline
Участник
ТаблоидЕсли затык при count'e из-за очереди на диск, то где он тут
Прошу прощения, что вмешиваюсь, но нагрузку на диск сподручнее смотреть через iotop.
...
Рейтинг: 0 / 0
12.04.2011, 23:08
| Ответить | Цитировать | Написать  
fbtracemgr: разные мелкие вопросы
    #37213098
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Таблоид,

дисковый ввод-вывод даже при пустой очереди (отсутствии конкуренции) все равно "отрубает" процессор на время операции, так что IMHO тут все нормально - сборка мусора просто сильнее грузит диск, чем удаление.
...
Рейтинг: 0 / 0
12.04.2011, 23:10
| Ответить | Цитировать | Написать  
fbtracemgr: разные мелкие вопросы
    #37213369
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
miwaonlineнагрузку на диск сподручнее смотреть через iotop.спасибо, я этого не знал; учту в след. раз.
dimitrсборка мусора просто сильнее грузит диск, чем удаление.оказалось неожиданным, НАСКОЛЬКО сильнее. Само удаление идёт чуть больше минуты. Каунт после него - 40 минут! Каунт "обычный", не вызывающий сборку мусора, - 45 сек.
Вот что вижу сейчас, по итогам томной ночи:
 
Код: 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.
[fb@fbG fb]$ isql -n 192.168.1.1:/u01/db/firebird/test.fdb
Database:  192.168.1.1:/u01/db/firebird/test.fdb
SQL> set stat on;
SQL> delete from tmp where f01 between 50000 and 51000;
Current memory = 18863640
Delta memory = 17952264
Max memory = 32507816
 Elapsed time= 63.64 sec 
Cpu = 0.00 sec
 Buffers = 75   -- ?! 
Reads = 577466
Writes = 574196
Fetches = 5000892

SQL> commit;
Current memory = 1045592
Delta memory = -17818048
Max memory = 32507816
Elapsed time= 0.02 sec
Cpu = 0.00 sec
Buffers = 75
Reads = 1
Writes = 73
Fetches = 1
SQL> select count(*) from tmp;

       COUNT
============
    99000438

Current memory = 1059808
Delta memory = 13120
Max memory = 32507816
 Elapsed time= 2369.86 sec 
Cpu = 0.00 sec
Buffers = 75
Reads = 10141603
Writes = 5660541
Fetches = 235789600

SQL> select count(*) from tmp;

       COUNT
============
    99000438

Current memory = 1059808
Delta memory = 0
Max memory = 32507816
Elapsed time= 45.69 sec
Cpu = 0.00 sec
Buffers = 75
Reads = 807294
Writes = 32
Fetches = 199614623

2 hvlad, dimitr : и еще две странности.
1) Статистика (в спойлере) показывает, что буферов у меня 75. Базу создавал без явного указания числа буферов, в firebird.conf'e давно уже установлено 512. Откуда ISQL берёт значение buffers=75 ?!
2) поменял число буферов в заголовке базы (gfix -buffers 512). Подсчет числа строк на исходной таблице (100 млн), к сож-ю, остался практически таким же, как и при buf=75: 43 сек. Размер страницы = 8К, памяти на сервере навалом. Хорошо помню, что раньше увеличение числа буферов влияло гораздо сильнее, и на чтение и на запись.

ЗЫ. LI-V2.5.0.26083
...
Рейтинг: 0 / 0
13.04.2011, 09:01
| Ответить | Цитировать | Написать  
fbtracemgr: разные мелкие вопросы
    #37213594
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Таблоидоказалось неожиданным, НАСКОЛЬКО сильнее. Само удаление идёт чуть больше минуты. Каунт после него - 40 минут! Каунт "обычный", не вызывающий сборку мусора, - 45 сек.
- удаление не трогает индексы
- сборка мусора - чистит и данные, и индексы
- 5 индексов приводят к random IO
- кеш в 75 буферов постоянно вытесняется и одно и то же заново читается и пишется
- чтения амортизируются файловым кешем, а вот записи - нет, ибо FW
...
Рейтинг: 0 / 0
13.04.2011, 10:41
| Ответить | Цитировать | Написать  
fbtracemgr: разные мелкие вопросы
    #37213665
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Проблема решена.
Рулят три вещи: 1) buffers = 512; 2) FW = OFF и 3) FileSystemCacheThreshold = 65536
При установленном числе буферов = 512 сделал еще три замера.

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
 1. FW = ON, FileSystemCacheThreshold=disabled :
SQL> delete from tmp where f01 between 50000 and 51000; commit;
Elapsed time= 82.95 sec
SQL> select count(*) from tmp;
 Срубил, ждал более 15 минут 

 2. FW = OFF, FileSystemCacheThreshold=disabled :
SQL> delete from tmp where f01 between 50000 and 51000; commit;
Elapsed time= 24.39 sec
SQL> select count(*) from tmp;
Elapsed time= 447.00 sec

 3. FW = OFF, FileSystemCacheThreshold=65536 :
SQL> delete from tmp where f01 between 50000 and 51000;
Elapsed time=  10.32 sec 

SQL> select count(*) from tmp;
Elapsed time=  181.58 sec  // при "обычном" count'e время = 37.97 sec

Напомню: удаление 1 млн строк из таблицы, содержащей 100 млн.
Скрипт создания таблицы:
 
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
recreate table tmp(id int not null,f01 int,f02 int,f03 int,f04 int);
execute block as begin
execute statement 'drop sequence gen_test;'; when any do begin end
end;
create sequence gen_test;
commit;
execute block as
declare n int =  100000000 ;
begin
  while (n> 0 ) do
    insert into tmp(id,f01,f02,f03,f04)
    values (:n+iif( mod(:n, 1000 )= 0 , gen_id(gen_test, 1000 ),  0 )* 0 , rand()* 100000 , rand()* 100000 , rand()* 100000 , rand()* 100000 )
    returning :n- 1  into :n;
end;
commit;
alter table tmp add constraint tmp_pk primary key (id);
-- 15 min:
create index tmp_idx1 on tmp(f01,f02,f03,f04);
create index tmp_idx2 on tmp(f02,f03,f04,f01);
create index tmp_idx3 on tmp(f03,f04,f01,f02);
create index tmp_idx4 on tmp(f04,f01,f02,f03);
commit;


2 dimitr, hvlad .
Так и не понимаю:
1) зачем по дефолту до сих пор 75. Инсталлятор надо срочно менять и проставить там хотя бы 256. А лучше 512.
2) зачем по дефолту FW = ON, если в природе давно есть HDD-контроллеры, "обманывающие" OS и пишущие не так, как мы просим, а так, как "им надо" (т.е. меняющие последовательность записей). Если некая база крутится в продакшене с FW = OFF и там никто не делает backup'ы, то при жестком обрубе сервака часть их данных ВСЁ РАВНО будет потеряна. Так чего ради этот FW по дефолту = ON ?
3) зачем вырублено кеширование средствами OS, если сам ФБ пока еще не делает упреждающего чтения и отложенной записи.

В итоге, получаем нападки типа этой . И ведь нечем опровергнуть, пока не подкрутишь штатные настройки!
...
Рейтинг: 0 / 0
13.04.2011, 11:14
| Ответить | Цитировать | Написать  
fbtracemgr: разные мелкие вопросы
    #37213778
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Таблоид,

FileSystemCacheThreshold=disabled - это что ?
...
Рейтинг: 0 / 0
13.04.2011, 11:51
| Ответить | Цитировать | Написать  
fbtracemgr: разные мелкие вопросы
    #37214085
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
ТаблоидИнсталлятор надо срочно менять и проставить там хотя бы 256. А лучше 512.
если я правильно помню, конфиг ориентирован на суперсервер, и там прописано значение в 2048. У сервера есть умолчательные значения в кэше, если в конфиге ничего не прописано - 75 для классика и 2048 для супера. Так что, если чего и менять, то умолчательные значения в сервере (а не в конфиге).
...
Рейтинг: 0 / 0
13.04.2011, 13:49
| Ответить | Цитировать | Написать  
fbtracemgr: разные мелкие вопросы
    #37214093
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
hvladFileSystemCacheThreshold=disabled - это что ?это когда пробовал с .conf'ом, в котором закомментирована строка с этим параметром:
#FileSystemCacheThreshold = 65536

Я понимаю, что это значение (65536) в закомментированном виде должно работать так, как и в раскомментированном. Но тогда эффект от удаления комментария был бы нулевым. А он совсем не нулевой - см выше статистику (сборка мусора уменьшилась со 447 до 181 сек).
...
Рейтинг: 0 / 0
13.04.2011, 13:51
| Ответить | Цитировать | Написать  
fbtracemgr: разные мелкие вопросы
    #37214113
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
kdvТак что, если чего и менять, то умолчательные значения в сервере (а не в конфиге).OFF. 2 KDV . А вот вопросик имею, еще вчера хотел задать. Когда тестировалась терабайтная база, то выполнялись ли DML-действия ? (апдейты, делиты ?)
...
Рейтинг: 0 / 0
13.04.2011, 13:55
| Ответить | Цитировать | Написать  
fbtracemgr: разные мелкие вопросы
    #37214226
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
ТаблоидhvladFileSystemCacheThreshold=disabled - это что ?это когда пробовал с .conf'ом, в котором закомментирована строка с этим параметром:
#FileSystemCacheThreshold = 65536

Я понимаю, что это значение (65536) в закомментированном виде должно работать так, как и в раскомментированном. Именно так оно и работает

ТаблоидНо тогда эффект от удаления комментария был бы нулевым. А он совсем не нулевой - см выше статистику (сборка мусора уменьшилась со 447 до 181 сек).Где-то ты опять ошибаешься :)
...
Рейтинг: 0 / 0
13.04.2011, 14:23
| Ответить | Цитировать | Написать  
fbtracemgr: разные мелкие вопросы
    #37214431
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
ТаблоидТак и не понимаю:
1) зачем по дефолту до сих пор 75. Инсталлятор надо срочно менять и проставить там хотя бы 256. А лучше 512.
2) зачем по дефолту FW = ON, если в природе давно есть HDD-контроллеры, "обманывающие" OS и пишущие не так, как мы просим, а так, как "им надо" (т.е. меняющие последовательность записей). Если некая база крутится в продакшене с FW = OFF и там никто не делает backup'ы, то при жестком обрубе сервака часть их данных ВСЁ РАВНО будет потеряна. Так чего ради этот FW по дефолту = ON ?
3) зачем вырублено кеширование средствами OS, если сам ФБ пока еще не делает упреждающего чтения и отложенной записи
1) уже обсуждалось. В 3.0 увеличили.
2) не у каждого нуба есть такой хитрожопый контроллер. А дефолтная конфигурация рассчитана как раз на нубов.
3) вырублено оно лишь для очень больших кешей, чтобы избежать драки с осью за виртуалку
...
Рейтинг: 0 / 0
13.04.2011, 15:26
| Ответить | Цитировать | Написать  
fbtracemgr: разные мелкие вопросы
    #37214449
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
ТаблоидКогда тестировалась терабайтная база, то выполнялись ли DML-действия ? (апдейты, делиты ?)
нет. тупо налито, и все. планировали tpc-c на ней покрутить, соответственно было бы и то и другое. Но не задалось, диск с базой лежит возле компа, отключенный.
...
Рейтинг: 0 / 0
13.04.2011, 15:32
| Ответить | Цитировать | Написать  
fbtracemgr: разные мелкие вопросы
    #37214547
Ivan_Pisarevsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ivan_Pisarevsky
Участник
Таблоид2) зачем по дефолту FW = ON, если в природе давно есть HDD-контроллеры, "обманывающие" OS и пишущие не так, как мы просим, а так, как "им надо" (т.е. меняющие последовательность записей). Если некая база крутится в продакшене с FW = OFF и там никто не делает backup'ы, то при жестком обрубе сервака часть их данных ВСЁ РАВНО будет потеряна. Так чего ради этот FW по дефолту = ON ?Ты тащишь за уши железячный вопрос, для того, чтоб при отрубе питания не развалился рэйд при кэшировании записи на винты есть такое устройство в простонародье батарейка/бабуин, по науке bbu или bbwc (разные вендоры называют по разному). В общем хочешь кэшировать запись на контроллере доукомплектуй его соответствующим устройством, на фоне остальной сметы 100$ не заметно и не парь мозг SQL серверу и его разработчикам. :)
...
Рейтинг: 0 / 0
13.04.2011, 16:01
| Ответить | Цитировать | Написать  
fbtracemgr: разные мелкие вопросы
    #37432302
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
Поднимаю тему, т.к. сижу в ступоре: меняю в firebird.conf'e значение AuditTraceConfigFile (указываю другой файл с настройками трейса), подключаюсь к базе, выполняю запрос, отключаюсь. И вижу, что... создается по-прежнему старый лог.
Подумал, что может это вообще другой firebird.conf, поменял в нём DefaultDBCachePages на вычурное значение = 1234.
Снова подключился к FB (LI-V2.5.1.26353, classic), выполнил set stat on + select 1 from rdb$database - вижу в статистике новое значение для buffers (только что установленное 1234).
Отключил вообще AuditTraceConfigFile, но настройка не подействовала, лог трейса всё пишется.
Перезапустил xinetd - не помогло! "Кто-то" упрямо пишет в лог трейса!

2 hvlad: можно ли в заголовке файла однократно писать, настройки КАКОГО trace.conf'а используются в данный момент ?
Т.е. можно ли вот тут дописать что-то типа того, что зелёным цветом:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
2011-09-09T11:15:01.2770 (26477:0x7f0637436750) TRACE_INIT
        SESSION_1 Firebird Audit USING SETTINGS FROM: /opt/firebird/trace_probe01.conf


2011-09-09T11:15:01.2770 (26477:0x7f0637436750) ATTACH_DATABASE
        /u01/db/firebird/test5.fdb (ATT_27, SYSDBA:NONE, NONE, <internal>)

2011-09-09T11:15:01.2780 (26477:0x7f0637436750) START_TRANSACTION
        /u01/db/firebird/test5.fdb (ATT_27, SYSDBA:NONE, NONE, <internal>)
                (TRA_772, CONCURRENCY | WAIT | READ_WRITE)
<...>
...
Рейтинг: 0 / 0
09.09.2011, 11:34
| Ответить | Цитировать | Написать  
fbtracemgr: разные мелкие вопросы
    #37432397
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
ТаблоидПоднимаю тему, т.к. сижу в ступоре: меняю в firebird.conf'e значение AuditTraceConfigFile (указываю другой файл с настройками трейса), подключаюсь к базе, выполняю запрос, отключаюсь. И вижу, что... создается по-прежнему старый лог.Потому что нужен полный дисконнект.

ТаблоидПодумал, что может это вообще другой firebird.conf, поменял в нём DefaultDBCachePages на вычурное значение = 1234.
Снова подключился к FB (LI-V2.5.1.26353, classic), выполнил set stat on + select 1 from rdb$database - вижу в статистике новое значение для buffers (только что установленное 1234).
Потому что классик перечитывает конфиг при старте.

Но для существующего аудита это не работает.
Как и для пар-ров лок-менеджера, например.

Таблоид 2 hvlad: можно ли в заголовке файла однократно писать, настройки КАКОГО trace.conf'а используются в данный момент ?Нет, потому что в самом трейсе нет никаких файлов конфига.

В принципе, можно при создании трейс-сессии аудита писать об этом в firebird.log...
...
Рейтинг: 0 / 0
09.09.2011, 12:11
| Ответить | Цитировать | Написать  
fbtracemgr: разные мелкие вопросы
    #37432440
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
hvladТаблоидПоднимаю тему, т.к. сижу в ступоре: меняю в firebird.conf'e значение AuditTraceConfigFile (указываю другой файл с настройками трейса), подключаюсь к базе, выполняю запрос, отключаюсь. И вижу, что... создается по-прежнему старый лог.Потому что нужен полный дисконнект.что значит "полный дисконнект" ?! я не только отрубился от базы, но и вообще xinet рестартовал.
Неужто и этого недостаточно ?
hvladТаблоидПодумал, что может это вообще другой firebird.conf, поменял в нём DefaultDBCachePages на вычурное значение = 1234.
Снова подключился к FB (LI-V2.5.1.26353, classic), выполнил set stat on + select 1 from rdb$database - вижу в статистике новое значение для buffers (только что установленное 1234).
Потому что классик перечитывает конфиг при старте.

Но для существующего аудита это не работает.
Как и для пар-ров лок-менеджера, например.Звучит как приговор :-) Как его хотя бы вырубить-то, трейс этот ?

hvladТаблоид 2 hvlad: можно ли в заголовке файла однократно писать, настройки КАКОГО trace.conf'а используются в данный момент ?Нет, потому что в самом трейсе нет никаких файлов конфига.

В принципе, можно при создании трейс-сессии аудита писать об этом в firebird.log...Добавил просьбу: CORE-3595
...
Рейтинг: 0 / 0
09.09.2011, 12:23
| Ответить | Цитировать | Написать  
fbtracemgr: разные мелкие вопросы
    #37432454
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Таблоидчто значит "полный дисконнект" ?! я не только отрубился от базы Полный - значит не должно быть ни одного процесса FB. Это что-то новое ???

Таблоидно и вообще xinet рестартовал. Неужто и этого недостаточно ?Ты вчера ФБ впервые увидел ? При чём тут xinetd ??? Я плакалъ :'(

ТаблоидКак его хотя бы вырубить-то, трейс этот ? Суть аудита в том, чтобы ничего не пропускать. По уму, его должно быть невозможно вырубить. Но лазейка есть. Сам найдёшь :)

Ты мне вот что скажи - зачем ты из пушки (аудит) стреляешь по воробьям (свои частные сиюминутные задачи), когда есть личное оружие (пользовательский трейс) ???
...
Рейтинг: 0 / 0
09.09.2011, 12:29
| Ответить | Цитировать | Написать  
fbtracemgr: разные мелкие вопросы
    #37432550
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
hvladТы мне вот что скажи - зачем ты из пушки (аудит) стреляешь по воробьям (свои частные сиюминутные задачи), когда есть личное оружие (пользовательский трейс) ???Потому что так удобнее: не надо запускать ничего (fbtracemgr -se localhost:service_mgr -start -config /opt/firebird/fbtrace_probe01.conf ), просто подключился к тестовой базе - и вот он лог, уже готовый.
К тому же, старт пользовательского трейса выводит мессаги на консоль, а не в файл. Для логирования вывода в файл надо бубен в виде tee использовать.
И наконец, в "моём" линухе трейс надо запускать не через fbtracemgr, а с использованием fbsvcmgr - иначе его остановка по Упр-Це приводит к созданию какого-то дампа (см http://tracker.firebirdsql.org/browse/CORE-3405). Хотя Алекс и сказал, что этот тикет есть дубликат пролеченного, у меня дамп всё равно создается.
...
Рейтинг: 0 / 0
09.09.2011, 13:04
| Ответить | Цитировать | Написать  
fbtracemgr: разные мелкие вопросы
    #37432559
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
Таблоид,

а то ты не в IBE работаешь ?

Пользуйся инструментом по-назначению, и будет тебе счастье. Аудит не для этого.
...
Рейтинг: 0 / 0
09.09.2011, 13:07
| Ответить | Цитировать | Написать  
25 сообщений из 201, страница 2 из 9
  2  все
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / fbtracemgr: разные мелкие вопросы
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=40&msg=37214449&tid=1561416]:
 0ms
get settings:
 10ms
get forum list:
 14ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 133ms
get topic data:
 11ms
get forum data:
 3ms
get page messages:
 56ms
get tp. blocked users:
 1ms
others: 302ms
total:  538ms
созд. / загр.: 538ms
x
x
Закрыть


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