ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / mon$memory_usage: почти нет изменений после вып-я сортировки 1 млн строк с char-полем 16К
4 сообщений из 4, страница 1 из 1
mon$memory_usage: почти нет изменений после вып-я сортировки 1 млн строк с char-полем 16К
    #38727448
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
hi all

Что-то не понимаю вывод из mon$memory_usage.
Создаю новую базу, в ней табличку:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
SQL> create table t(id int primary key, dts timestamp, s varchar( 16384 )); commit;
SQL> insert into t select row_number()over(), dateadd(rand()*10000000 second to timestamp '01.01.2000 00:00:00'), rpad('',16384, uuid_to_char(gen_uuid())) from rdb$types,rdb$types,(select 1 i from rdb$types rows 20) rows 1000000; commit;
SQL> select count(*) from t;

                COUNT
=====================
               1000000
 
SQL> exit;

-- Далее рестартую ФБ, затем снова подключаюсь к базе --

Код: 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.
$ /opt/fb30trnk/bin/isql localhost/3333:/var/db/fb30/tmptmp.fdb
Database:  localhost/3333:/var/db/fb30/tmptmp.fdb
SQL> commit; select mon$stat_id si,mon$stat_group sg,mon$memory_used mu,mon$memory_allocated ma from mon$memory_usage order by sg,si;

          SI      SG                    MU                    MA
============ ======= ===================== =====================
           1       0            2450608416            2453884856
           2       1                611392               1245184
           6       1                  9696                131072
           7       1                178240                262144
           3       2                  1112                 65536
           4       2                  8880                 65536
           5       3                 14056                 65536

SQL> out /dev/null; set stat on;
 SQL> select id,s from t order by dts; 
Current memory = 2450920168
Delta memory = 296288
Max memory = 4591129832
Elapsed time= 103.538 sec
Cpu = 33.520 sec
Buffers = 524288
Reads = 4101379
Writes = 0
Fetches = 6207718
SQL> out; set stat off;
SQL> commit; select mon$stat_id si,mon$stat_group sg,mon$memory_used mu,mon$memory_allocated ma from mon$memory_usage order by sg,si;

          SI      SG                    MU                    MA
============ ======= ===================== =====================
           1       0            2450865288            2454609392
           2       1                771320               1638400
           6       1                  9696                131072
           7       1                178240                262144
           3       2                  1112                 65536
           4       2                  8880                 65536
           5       3                 13784                 65536

Команда select id,s from t order by dts должна была захапать очень много памяти, т.к. тут в списке полей указано s varchar(16384).
В конфиге времянки назначены на /dev/shm, а параметр TempCacheLimit = 2Gb - и он очень быстро переполнился, что заставило fb_sort вылезти на диск:

Код: plaintext
1.
2.
3.
$ lsof -a +L1 /dev/shm

COMMAND    PID     USER   FD   TYPE DEVICE    SIZE/OFF NLINK    NODE NAME
firebird 23799 firebird   12u   REG   0,17  14370734080      0 1473035 /dev/shm/fb_sort_qfhcVc (deleted)

Тогда вопрос: а что за попугаи показаны в выводе из mon$memory_usage ? почему такой малый дифферент чисел до и после выполнения сортировки ?
PS. LI-T3.0.0.31288
...
Рейтинг: 0 / 0
24.08.2014, 10:57
| Ответить | Цитировать | Написать  
mon$memory_usage: почти нет изменений после вып-я сортировки 1 млн строк с char-полем 16К
    #38727450
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
Таблоид,

там показаны текущие значения расхода памяти. После окончания сортировки память уже освобождена. Надо смотреть эти счетчики во время сортировки, либо смотреть max-значения, а не текущие.
...
Рейтинг: 0 / 0
24.08.2014, 11:04
| Ответить | Цитировать | Написать  
mon$memory_usage: почти нет изменений после вып-я сортировки 1 млн строк с char-полем 16К
    #38727451
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
Таблоид,

ну дык снимать показания надо было во время сортировки а не после неё. Рискну предположить, что после того как вся выборка отсортирована память возвращается системе.

ТаблоидВ конфиге времянки назначены на /dev/shm, а параметр TempCacheLimit = 2Gb - и он очень быстро переполнился, что заставило fb_sort вылезти на диск:

Есть подозрения, что если сортировка уходит на диск она не учитывается в mon$. Да и вроде для мониторинга temp хранилища хотели сделать отдельные счётчики
...
Рейтинг: 0 / 0
24.08.2014, 11:07
| Ответить | Цитировать | Написать  
mon$memory_usage: почти нет изменений после вып-я сортировки 1 млн строк с char-полем 16К
    #38727457
Таблоид
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Таблоид
Участник
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.
                      DTS           SI      SG                    MU                    MA
========================= ============ ======= ===================== =====================
2014-08-24 11:52:33.4470             1       0            2451121760            2455400232
2014-08-24 11:52:33.4470             2       1                611008               1245184
2014-08-24 11:52:33.4470             6       1                  9696                131072
2014-08-24 11:52:33.4470             7       1                178240                262144
2014-08-24 11:52:33.4470             8       1                369360                917504
2014-08-24 11:52:33.4470             3       2                  1112                 65536
2014-08-24 11:52:33.4470             4       2                  8880                 65536
2014-08-24 11:52:33.4470             9       2                  1112                 65536
2014-08-24 11:52:33.4470            10       2                  1144                 65536
2014-08-24 11:52:33.4470             5       3                 15144                 65536


                      DTS           SI      SG                    MU                    MA
========================= ============ ======= ===================== =====================
2014-08-24 11:52:34.4510             1       0            2454942424            2459881112
2014-08-24 11:52:34.4510             2       1                610872               1245184
2014-08-24 11:52:34.4510             6       1                  9696                131072
2014-08-24 11:52:34.4510             7       1                178240                262144
2014-08-24 11:52:34.4510             8       1              25975728              26988400
2014-08-24 11:52:34.4510             3       2                  1112                 65536
2014-08-24 11:52:34.4510             4       2                  8880                 65536
2014-08-24 11:52:34.4510             9       2                  2432                 65536
2014-08-24 11:52:34.4510            10       2                  2712                 65536
2014-08-24 11:52:34.4510             5       3                 14872                 65536
2014-08-24 11:52:34.4510            11       3              25216416              25350000


                      DTS           SI      SG                    MU                    MA
========================= ============ ======= ===================== =====================
2014-08-24 11:52:35.6030             1       0            2666628776            2671631568
2014-08-24 11:52:35.6030             2       1                610872               1245184
2014-08-24 11:52:35.6030             6       1                  9696                131072
2014-08-24 11:52:35.6030             7       1                178240                262144
2014-08-24 11:52:35.6030             8       1             745301576             746381168
2014-08-24 11:52:35.6030             3       2                  1112                 65536
2014-08-24 11:52:35.6030             4       2                  8880                 65536
2014-08-24 11:52:35.6030             9       2                  2432                 65536
2014-08-24 11:52:35.6030            10       2                  2712                 65536
2014-08-24 11:52:35.6030             5       3                 14872                 65536
2014-08-24 11:52:35.6030            11       3             744542128             744742768
Счетчики растут для mon$stat_id, mon$stat_group = {1, 0}, { 8, 1 } и {11, 3 }.
Для mon$stat_group дока говорит:
Код: plaintext
1.
2.
3.
4.
5.
      - MON$STAT_GROUP (вид статистики)
           0: база данных 
           1: соединение 
          2: транзакция
           3: оператор 
          4: вызов

1. Почему не прут вверх счетчики для группы 2 ("транзакция") ?
2. Что показывается в mon$stat_id ? (в выводе есть строки с `si` = 2,6,7,3,4,9,10 & 5, в которых счетчики не меняются)
...
Рейтинг: 0 / 0
24.08.2014, 12:08
| Ответить | Цитировать | Написать  
4 сообщений из 4, страница 1 из 1
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / mon$memory_usage: почти нет изменений после вып-я сортировки 1 млн строк с char-полем 16К
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=40&msg=38727448&tid=1563378]:
 0ms
get settings:
 11ms
get forum list:
 20ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 198ms
get topic data:
 9ms
get forum data:
 2ms
get page messages:
 56ms
get tp. blocked users:
 1ms
others: 254ms
total:  559ms
созд. / загр.: 559ms
x
x
Закрыть


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