powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Использование памяти
56 сообщений из 56, показаны все 3 страниц
Использование памяти
    #39472959
Роман Янковский
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
У меня на сервере относительно небольшая БД файрберда и относительно много свободной оперативной памяти. Эту БД туда можно загрузить раза 3 целиком и еще место останется. Но файрберд почему-то использует память очень экономично. Какие бы настройки подкрутить, чтобы он стал попрожорливее и интенсивнее использовал память? Явно же на скорости работы это положительно скажется.
...
Рейтинг: 0 / 0
Использование памяти
    #39472968
KreatorXXI
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Роман Янковский,

А версия ФБ какая? SS или Classic?
...
Рейтинг: 0 / 0
Использование памяти
    #39472973
Роман Янковский
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
KreatorXXI,

Версия 3.0
ServerMode = Super
...
Рейтинг: 0 / 0
Использование памяти
    #39472983
Ivan_Pisarevsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Роман ЯнковскийЯвно же на скорости работы это положительно скажется.Будет пример тормозящего запроса со статистикой исполнения? А то как-то голословно все. Может серверу и не надо больше памяти? Крутить настройки надо осмысленно.
...
Рейтинг: 0 / 0
Использование памяти
    #39472990
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ivan_Pisarevsky,

ну настройки страничного кеша по умолчанию для SS в 3.0 тоже смехатворны.

Роман Янковский,

для начала

Код: plaintext
1.
DefaultDbCachePages = 50K
TempCacheLimit = 512M

если быстродействие устраивает дальше не крути. Я ставлю эти настройки в databases.conf под конкретную БД
...
Рейтинг: 0 / 0
Использование памяти
    #39473154
KreatorXXI
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Роман Янковский,

Я, кстати, поднимал типа такого же вопроса. У нас небольшая БД, вполне вся может влезть в оперативку. Казалось бы скорость при этом должна увеличится существенно. Но ФБ так не работает. А народ требует тестов, которые покажут провалы по быстродействию.
...
Рейтинг: 0 / 0
Использование памяти
    #39473221
Роман Янковский
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ivan_PisarevskyРоман ЯнковскийЯвно же на скорости работы это положительно скажется.Будет пример тормозящего запроса со статистикой исполнения? А то как-то голословно все. Может серверу и не надо больше памяти? Крутить настройки надо осмысленно.

Ну вот например см скриншот. Полторы секунды на сущую ерунду.
Пара сотен таких запросов уже проблема.

Если бы файрберд работал медленнее чем я хочу, выедая все доступные ресурсы, я бы понял в чем дело. Но и память, и CPU почти не использует.
...
Рейтинг: 0 / 0
Использование памяти
    #39473225
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Рома, чем тебя не устроил Оракл?
чего ты с него слез?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Использование памяти
    #39473255
pastor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Роман Янковский,

А статистику выполнения таки можно глянуть?

Очень хочется увидеть как на полутора тысячах записей можно получить полторы секунды.
...
Рейтинг: 0 / 0
Использование памяти
    #39473263
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Роман Янковский,

http://www.ibase.ru/files/firebird/Firebird_Hardware_Guide_2015_rus.pdf
Роман ЯнковскийЭту БД туда можно загрузить раза 3 целиком
операционная система БД в кэш и грузит. В общем, читайте документ.
...
Рейтинг: 0 / 0
Использование памяти
    #39473270
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Роман Янковский,

до кучи - смотреть надо page reads и fetches from cache. А то что на экране - ерунда. Кроме того, запрос сам по себе прекрасен:

select a, b from t
order by c

то есть, х.з. по какому критерию отсортировано.
...
Рейтинг: 0 / 0
Использование памяти
    #39473276
pastor
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Роман ЯнковскийIvan_Pisarevskyпропущено...
Будет пример тормозящего запроса со статистикой исполнения? А то как-то голословно все. Может серверу и не надо больше памяти? Крутить настройки надо осмысленно.

Ну вот например см скриншот. Полторы секунды на сущую ерунду.
Пара сотен таких запросов уже проблема.

Если бы файрберд работал медленнее чем я хочу, выедая все доступные ресурсы, я бы понял в чем дело. Но и память, и CPU почти не использует.

это отчет по двум десяткам таблиц, из которых штук пять - больше миллиона записей


Query
------------------------------------------------
select count(i.STRINGS)
from HTML2$IDENT_INFO( '34013C815D4666') i

Plan
------------------------------------------------
PLAN (HTML_BEGIN NATURAL)(D INDEX (ZLS$DOMAIN_DICT_UNQ))(D INDEX (ZLS$DOMAIN_DICT_UNQ))(IDENT$GET_IDENT NATURAL)JOIN (I INDEX (IDENT$IDENTIFIERS), T INDEX (IDENT$TYPES))JOIN (L INDEX (IDENT$LIFE), RU INDEX (RULE$USES))(I INDEX (IDENT$EMPLOYEE_LIFE))(HTML$RAW_EMP_INFO NATURAL)(HTML2$IDENT_USE NATURAL)JOIN (I INDEX (IDENT$ACCOUNTS_LIFE), TT INDEX (TARIFF$TYPES), RU INDEX (RULE$USES), C INDEX (ACC$CATEGORY))(FORMAT_DATE_TIME NATURAL)(FORMAT_DATE_TIME NATURAL)SORT (JOIN (TR INDEX (IDENT$TEMP_RULE_IA), R INDEX (RULE$USES)))(FORMAT_DATE_TIME NATURAL)(FORMAT_DATE_TIME NATURAL)JOIN (TR INDEX (IDENT$TEMP_RULE_IA), R INDEX (RULE$USES))(FORMAT_DATE_TIME NATURAL)(FORMAT_DATE_TIME NATURAL)SORT (JOIN (A INDEX (IDENT$ATTRIBUTES_IA), T INDEX (IDENT$ATTRIBUTE_TYPES)))(FORMAT_MONEY NATURAL)JOIN (ACC$GET_BALANCE_EX NATURAL, C INDEX (ACC$CURRENCIES))JOIN (O INDEX (PRS$ACCOUNT_OWNERS_UA), P INDEX (PRS$PEOPLES_PRS_UN), G INDEX (PRS$GROUPS), GT INDEX (PRS$GROUP_TYPES))(RAW$PRS_INFO_DOCS_INFO NATURAL)(SPD$SETTINGS INDEX (SPD$SETTINGS_NAME))(ACC$GET_BALANCE NATURAL)(RAW$RULE_ESTIMATION NATURAL)(HTML2$ROOM_USE NATURAL)(HTML2$IDENT_PACKAGES NATURAL)(HTML2$TRANSACTIONS_LIST NATURAL)(HTML2$IDENT_USE NATURAL)(HTML2$ORDER_LIST NATURAL)(HTML2$ACC_OPERATIONS NATURAL)(HTML_END NATURAL)

Query Time
------------------------------------------------
Prepare : 0,00 ms
Execute : 156,00 ms
Avg fetch time: 156,00 ms

Memory
------------------------------------------------
Current: 173 084 472
Max : 173 554 816
Buffers: 9 999

Operations
------------------------------------------------
Read : 0
Writes : 7
Fetches: 6 160
Marks : 12


Enchanced Info:
+-------------------------------+-----------+-----------+-------------+---------+---------+---------+----------+----------+----------+
| Table Name | Records | Indexed | Non-Indexed | Updates | Deletes | Inserts | Backouts | Purges | Expunges |
| | Total | reads | reads | | | | | | |
+-------------------------------+-----------+-----------+-------------+---------+---------+---------+----------+----------+----------+
|ACC$BALANCES | 0 | 3 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
|ACC$CATEGORY | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
|ACC$CURRENCIES | 0 | 105 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
|ACC$ITEMS | 0 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
|ACC$TRANSACTIONS | 0 | 103 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
|ADM_ORGANISATION | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
|BILL$ITEMS | 0 | 11 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
|BILL$POSITIONS | 0 | 32 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
|DESK$ITEMS | 0 | 11 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
|DEV$POINTS | 0 | 11 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
|DEV$REASONS | 0 | 11 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
|DEV$TERRITORIES | 0 | 23 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
|EMP$ITEMS | 0 | 11 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
|IDENT$ACCOUNTS | 0 | 20 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
|IDENT$IDENTIFIERS | 0 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
|IDENT$LIFE | 0 | 3 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
|IDENT$MOTIONS | 0 | 10 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
|IDENT$RESOLUTIONS | 0 | 12 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
|IDENT$TYPES | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
|LOG_EVENTS | 0 | 0 | 0 | 0 | 0 | 2 | 0 | 0 | 0 |
|LOG_EVENT_TYPES | 0 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
|PRS$ACCOUNT_OWNERS | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
|PRS$GROUPS | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
|PRS$GROUP_TYPES | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
|PRS$INFO_DOCS | 0 | 10 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
|PRS$INFO_DOC_TYPES | 0 | 10 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
|PRS$PEOPLES | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
|RULE$DEV_TC_PARAM | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
|RULE$DEV_TC_TERR | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
|RULE$DEV_TIME_COST | 0 | 1 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
|RULE$USES | 0 | 12 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
|RULE$USE_ELEMENTS | 0 | 4 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
|RULE$USE_ITEMS | 0 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
|SALE$ACC_LINK | 0 | 51 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
|SALE$ACC_SB_LINK | 0 | 14 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
|SALE$ACC_TR_LINK | 0 | 5 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
|SALE$DOC_ITEMS | 0 | 83 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
|SALE$DOC_ITEM_BPS | 0 | 32 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
|SALE$IDENT_LINK | 0 | 11 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
|SALE$IDENT_REPL_LINK | 0 | 3 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
|SPD$SETTINGS | 0 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
|TARIFF$TYPES | 0 | 2 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
|ZLS$DOMAIN_DICT | 0 | 311 | 0 | 0 | 0 | 0 | 0 | 0 | 0 |
+-------------------------------+-----------+-----------+-------------+---------+---------+---------+----------+----------+----------+
...
Рейтинг: 0 / 0
Использование памяти
    #39473282
чччД
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kdv...запрос сам по себе прекрасен:

select a, b from t
order by c

то есть, х.з. по какому критерию отсортировано.

И что тут не так? Во многих случаях значение критерия сортировки или фильтрации юзеру видеть не нужно.

Или не сразу нужно. К примеру, нужно просмотреть всю номенклатуру: вытягиваешь список 10 000 000 id's, отсортированных по типу товара и наименованию, затем, сканируя список id's, подтягиваешь по мере надобности остальные поля. И юзеру хорошо (10 000 000 позиций на экране видит), и железо не дохнет от перегрузки.
...
Рейтинг: 0 / 0
Использование памяти
    #39473284
Ivan_Pisarevsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
тот же запрос без order by сколько работает?
...
Рейтинг: 0 / 0
Использование памяти
    #39473363
Роман Янковский
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ivan_Pisarevskyтот же запрос без order by сколько работает?

Столько же. Запрос резко ускоряется до 0.03сек, если убрать условие "and i.station_id = 50".
Предупреждая вопросы - индекс по этому полю имеется.

Дело-то не в одном запросе. В принципе есть ощущение, что что-то не так. Тут полсекунды, там полторы, тут еще чуть-чуть. Вроде немного, но в итоге накапливается большое время. Это нехорошо.
...
Рейтинг: 0 / 0
Использование памяти
    #39473366
Роман Янковский
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
pastorА статистику выполнения таки можно глянуть?

Очень хочется увидеть как на полутора тысячах записей можно получить полторы секунды.

Я не большой специалист по firebird. Я с удовольствием покажу статистику, если мне намекнут как ее посмотреть. Я показал окошко Statistics. Глупо, понимаю, но что есть)) Так что, пожалуйста, подскажите.
...
Рейтинг: 0 / 0
Использование памяти
    #39473367
Роман Янковский
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
МимопроходящийРома, чем тебя не устроил Оракл?
чего ты с него слез?

Не я такой, жизнь такая. В этом проекте файрберд давно уже, не менять же его.
...
Рейтинг: 0 / 0
Использование памяти
    #39473368
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Роман ЯнковскийВ принципе есть ощущение, что что-то не так.

Смотреть планы и статистику тебе уже предлагали. Чтобы не казалось.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Использование памяти
    #39473370
Роман Янковский
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kdvРоман Янковский,

до кучи - смотреть надо page reads и fetches from cache. А то что на экране - ерунда. Кроме того, запрос сам по себе прекрасен:

select a, b from t
order by c

то есть, х.з. по какому критерию отсортировано.

Что значит х.з.? Чтобы сортировать по полю нужно обязательно добавлять его в select? Это какие-то новости sql?
...
Рейтинг: 0 / 0
Использование памяти
    #39473371
Ivan_Pisarevsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Роман ЯнковскийЗапрос резко ускоряется до 0.03сек, если убрать условие "and i.station_id = 50"
напиши and i.station_id+0 = 50
...
Рейтинг: 0 / 0
Использование памяти
    #39473373
Ivan_Pisarevsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
хотя гораздо лучше было бы если условие соединения все бы сидело в одном композитном индексе.
...
Рейтинг: 0 / 0
Использование памяти
    #39473374
Роман Янковский
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ivan_PisarevskyРоман ЯнковскийЗапрос резко ускоряется до 0.03сек, если убрать условие "and i.station_id = 50"
напиши and i.station_id+0 = 50

Стало выполнятся за 0.05сек. Это что за магия такая? :)
...
Рейтинг: 0 / 0
Использование памяти
    #39473380
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Роман ЯнковскийЯ с удовольствием покажу статистику, если мне намекнут как ее посмотреть. Я показал окошко
Statistics. Глупо, понимаю, но что есть))

Используй isql, SET STATS ON, SET PLAN ON.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Использование памяти
    #39473391
чччД
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Роман ЯнковскийIvan_Pisarevskyпропущено...

напиши and i.station_id+0 = 50

Стало выполнятся за 0.05сек. Это что за магия такая? :)
Таким способом ты отключил использование "плохого" индекса по station_id .

Сие тайное знание имхо, специально нигде не описано, но можно поискать здесь по совокупности слов "хинт" и "индекс".
...
Рейтинг: 0 / 0
Использование памяти
    #39473392
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Роман ЯнковскийЧто значит х.з.? Чтобы сортировать по полю нужно обязательно добавлять его в select? Это какие-то новости sql?
я понимаю, что бывает всякая специфика, и конкретная реализация SQL не запрещает, но вот например - вижу я в результате запроса фамилии людей. Которые идут в каком-то порядке. Каком - я не вижу. А они - сюрприз! - отсортированы по номеру паспорта. Или по дате рождения. То есть, оценить, по какому критерию конкретные записи идут одна за другой, я не могу.
Роман ЯнковскийЭто что за магия такая? :)
вполне может быть, что у вас там много лишних индексов создано.
Чччдпросмотреть всю номенклатуру: вытягиваешь список 10 000 000 id's,
с этим я не спорю. К тому же у автора выдается какой-то лог, вероятно, время не важно, важна последовательность. Но спросить-то все равно надо было :-)
...
Рейтинг: 0 / 0
Использование памяти
    #39473429
alekcvp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
чччДТаким способом ты отключил использование "плохого" индекса по station_id . .
Эээ... а можно для нубов: чем он плохой и как вообще определить что индекс - плохой?
...
Рейтинг: 0 / 0
Использование памяти
    #39473432
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
alekcvp,

"плохой" индекс - индекс с плохой избирательностью (селективностью), т.е. большим количеством дубликатов ключей. Классический пример - в таблице 1000 записей, по столбцу построен индекс, в столбце 2 значения (м и ж, 1 и 2, и т.д.). Одно значение ключа - 990 записей, другое - 10. Поиск по первому значению приводит к чтению почти всех страниц с диска, т.е. к лишним операциям ввода-вывода, т.к. все равно выберется 990 записей (почти все). Поиск на второе значение - очень выгоден, т.к. выберет всего 10 записей.
Но оптимизатор не знает, поиск какого значения будет производиться, поэтому индекс в плане скорее всего будет использоваться.
Так что тут все зависит от ситуации, поиск каких значений идет по индексу, и сколько их.

Еще "качество" индекса, если он по нескольким столбцам, зависит от порядка столбцов в индексе, и их селективности.

В общем, создавать индексы вручную (кроме ПК и ФК) нужно только если они явно ускоряют производительность конкретного запроса. Бывает что разработчик наоборот, сначала нафигачит индексов на все случаи жизни, а потом удивляется почему "убирание" индекса ускоряет запрос.
...
Рейтинг: 0 / 0
Использование памяти
    #39473459
alekcvp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ага, спасибо.
...
Рейтинг: 0 / 0
Использование памяти
    #39473469
Роман Янковский
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kdvРоман ЯнковскийЧто значит х.з.? Чтобы сортировать по полю нужно обязательно добавлять его в select? Это какие-то новости sql?
я понимаю, что бывает всякая специфика, и конкретная реализация SQL не запрещает, но вот например - вижу я в результате запроса фамилии людей. Которые идут в каком-то порядке. Каком - я не вижу. А они - сюрприз! - отсортированы по номеру паспорта. Или по дате рождения. То есть, оценить, по какому критерию конкретные записи идут одна за другой, я не могу.

Этот конкретный запрос используется в хранимой процедуре, где важно обрабатывать записи в хронологическом порядке. При этом сама дата не важна. Только порядок.
...
Рейтинг: 0 / 0
Использование памяти
    #39473471
Роман Янковский
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Я так и подумал сначала, что этот трюк отключает индекс. Но потом я вообще задисейблил этот индекс и быстрее не стало. Поэтому засомневался. А потом уже после того как запостил вопрос, увидел, что на это поле есть еще и внешний ключ и в когда я дисейблю индекс, в план попадает он. Индекс я прибить могу, нафиг он нужен, а вот внешний ключ отключать стремно как-то.
...
Рейтинг: 0 / 0
Использование памяти
    #39473503
Роман Янковский
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kdvalekcvp,

"плохой" индекс - индекс с плохой избирательностью (селективностью), т.е. большим количеством дубликатов ключей. Классический пример - в таблице 1000 записей, по столбцу построен индекс, в столбце 2 значения (м и ж, 1 и 2, и т.д.). Одно значение ключа - 990 записей, другое - 10. Поиск по первому значению приводит к чтению почти всех страниц с диска, т.е. к лишним операциям ввода-вывода, т.к. все равно выберется 990 записей (почти все). Поиск на второе значение - очень выгоден, т.к. выберет всего 10 записей.
Но оптимизатор не знает, поиск какого значения будет производиться, поэтому индекс в плане скорее всего будет использоваться.
Так что тут все зависит от ситуации, поиск каких значений идет по индексу, и сколько их..

Это кстати не объясняет почему с индексом значительно медленнее, чем без индекса.
...
Рейтинг: 0 / 0
Использование памяти
    #39473504
Siemargl
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Роман ЯнковскийIvan_Pisarevskyпропущено...

напиши and i.station_id+0 = 50

Стало выполнятся за 0.05сек. Это что за магия такая? :)
Это отсутствие реального оптимизатора в ФБ
...
Рейтинг: 0 / 0
Использование памяти
    #39473506
Роман Янковский
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Сделал индекс по двум полям, нормально стало. Спасибо огромное!

Но это не объясняет мое изначальное недоумение. Ну допустим запрос плохой и индексы не те. Так пусть файрберд жрет ресурсы, чтоб его выполнить. Эти таблицы все целиком 20 раз в память поместятся, оно тупым перебором должно было быстрее работать.
...
Рейтинг: 0 / 0
Использование памяти
    #39473507
Роман Янковский
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
На всякий случай еще старую медленную статистику запосчу. Завтра.
Извиняюсь за много постов.
...
Рейтинг: 0 / 0
Использование памяти
    #39473528
Роман Янковский
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
И еще. Такое вот:

Код: sql
1.
2.
3.
4.
5.
select count(*)
        from sts_availability_history_entry e
        left join sts_availability_history_item i on i.entry_id = e.id and i.station_id = 50
        where e.created_utc between cast('1-May-2017' as date) and cast('2-May-2017' as date)  
          and extract(hour from e.created_utc) between 4 and 21



> 1080

Код: sql
1.
2.
3.
4.
5.
select count(*)
        from sts_availability_history_entry e
        left join sts_availability_history_item i on i.entry_id = e.id -- and i.station_id = 50
        where e.created_utc between cast('1-May-2017' as date) and cast('2-May-2017' as date)  
          and extract(hour from e.created_utc) between 4 and 21



> 20964

Точно-точно у индекса по select_id плохая селективность?
...
Рейтинг: 0 / 0
Использование памяти
    #39473547
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Роман ЯнковскийТочно-точно у индекса по select_id плохая селективность?Планы и статистику выполнения мы увидим ?
...
Рейтинг: 0 / 0
Использование памяти
    #39473555
schi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Роман ЯнковскийНу допустим запрос плохой и индексы не те. Так пусть файрберд жрет ресурсы, чтоб его выполнить. Эти таблицы все целиком 20 раз в память поместятся, оно тупым перебором должно было быстрее работать.

Ты всерьез полагаешь, что он с диска каждый раз нужную страницу читает, потому медленно работает ? Сдается мне, что к моменту выполнения самого запроса сколько можно страниц уже прочитано или они читаются по мере надобности и толку от того, что они будут прочитаны заранее будет немного.
...
Рейтинг: 0 / 0
Использование памяти
    #39473560
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Роман ЯнковскийТак пусть файрберд жрет ресурсы, чтоб его выполнить.
судя по этой фразе, вы не читали статью про железо и фб, которую я вам дал.
...
Рейтинг: 0 / 0
Использование памяти
    #39473563
Роман Янковский
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
С SET PLAN ON/SET STATS ON в ISQL получил такие вещи. Отключил новый индекс по двум полям для наглядности.

План (который в принципе уже был в начале):

PLAN JOIN (E ORDER I_STS_AVAILABILITY_HIST_EN_IDX1 INDEX (I_STS_AVAIL_HIST_ENTRY_I2), I INDEX (FK_STS_AVAILAB_STS_AVAILAB, FK_STS_AVAILABI_STA_STATION))

Статистика:

Current memory = 453891000
Delta memory = 3899800
Max memory = 992638888
Elapsed time= 2.842 sec
Buffers = 50000
Reads = 39023
Writes = 313
Fetches = 664352
...
Рейтинг: 0 / 0
Использование памяти
    #39473568
Роман Янковский
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
То же самое с включенным индексом по двум полям.

Current memory = 456675728
Delta memory = 6607232
Max memory = 992638888
Elapsed time= 1.250 sec
Buffers = 50000
Reads = 13818
Writes = 184
Fetches = 337405
...
Рейтинг: 0 / 0
Использование памяти
    #39473571
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Роман ЯнковскийBuffers = 50000
Reads = 13818
если суперсервер, и 3.0, то можно увеличивать кэш до 200000 тысяч, только тогда надо не забыть и
FileSystemCacheThreshold
тогда увеличить, например до 300к.

база какого размера, какой размер страницы, и сколько RAM на сервере?
...
Рейтинг: 0 / 0
Использование памяти
    #39473587
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Роман ЯнковскийТо же самое с включенным индексом по двум полям.Ты серьёзно считаешь, что кто-то стоит у тебя за спиной и видит эти индексы и поля ? И где план запроса ?
Кроме того, желательно показывать детальную (потабличную) статистику выполнения, IBE в помощь.
И DDL всех затронутых объектов (таблиц и индексов).
...
Рейтинг: 0 / 0
Использование памяти
    #39473588
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kdvесли суперсервер, и 3.0, то можно увеличивать кэш до 200000 тысячЗачем ? Reads и так меньше Buffers, там всё и так попадает в кеш.
Есс-но, не до первого выполнения запроса
...
Рейтинг: 0 / 0
Использование памяти
    #39473609
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvlad,

reads - это то что не влезло в кэш. Если бы оно влезало, reads было бы 0, при повторном выполнении запроса, разумеется. Но вероятно, раз приведены "с индексом и без", то скорее всего запросы можно считать повторными, и видимо, не влезает.
...
Рейтинг: 0 / 0
Использование памяти
    #39473624
Роман Янковский
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladРоман ЯнковскийТо же самое с включенным индексом по двум полям.Ты серьёзно считаешь, что кто-то стоит у тебя за спиной и видит эти индексы и поля ?

Я считаю, что отвечающие читали тему. Мне предложили сделать индекс по условию соединения и я его сделал.

hvladИ где план запроса ?

Не будет плана запроса. Третий раз его постить наверно уже лишнее.
...
Рейтинг: 0 / 0
Использование памяти
    #39473625
Роман Янковский
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kdv,

спасибо, попробую сегодня
...
Рейтинг: 0 / 0
Использование памяти
    #39473633
Роман Янковский
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
[quot kdv]Роман Янковскийбаза какого размера, какой размер страницы, и сколько RAM на сервере?

база 7.5гб (хм, подросла с тех пор, как я в последний раз смотрел, но ram можно увеличить, если это поможет)
ram 16gb
страница 8192
...
Рейтинг: 0 / 0
Использование памяти
    #39473634
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Роман ЯнковскийНе будет плана запроса. Третий раз его постить наверно уже лишнее.Весьма глупое поведение. Мне эти планы, наверное, не очень нужны, так что я как-нибудь переживу этот отказ :)

Подскажу: у запросов с и без использования индексов разные планы.
...
Рейтинг: 0 / 0
Использование памяти
    #39473635
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kdvreads - это то что не влезло в кэшСерьёзно ? :)

kdvскорее всего запросы можно считать повторнымиСлишком много предположений и слишком мало надежды получить минимально необходимую инф-цию
...
Рейтинг: 0 / 0
Использование памяти
    #39473636
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Роман Янковскийбаза 7.5гб (хм, подросла с тех пор, как я в последний раз смотрел, но ram можно увеличить, если это поможет)
статью читайте же. Если база 7 гиг, а памяти 16, вероятно что база уже в памяти. RAMMAP это показывает (на двух последних закладках). Понятно, что смотреть надо при интенсивной работе, а не при выполнении одного тестового запроса.

Дальше, при странице 8к и 50000 страниц кэша кэш получается 400 мегабайт. Так что его можно спокойно увеличить раза в 4, как я и предложил (если ФБ 64битный. Если 32битный, то лучше не надо).
Потом, во время работы вы можете посмотреть, сколько занимает процесс firebird.exe. Вы же не написали - сколько. Вы сообщили "использует память очень экономично".
И 7 гиг 3 раза в 16 гиг не влезет. Влезет только 2 раза. В общем, читайте статью и настраивайте. Там все есть - и рекомендации, и формулы, надо только прочитать внимательно :-)
...
Рейтинг: 0 / 0
Использование памяти
    #39473637
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladСерьёзно ? :)
серьезно. это я к тому, что ты сам выдал то, что "прочитывается неоднозначно". Reads это сколько страниц считано с диска, а не из кэша. Если кэш N страниц, то всего прочитано страниц Reads + (от 0 до N), в зависимости от ситуации - первый запрос после коннекта, второй запрос, классик или супер, есть-ли другие запросы между выполнением "тестовых", и т.д.
Не хочешь неоднозначностей - так сам пиши максимально подробно.
...
Рейтинг: 0 / 0
Использование памяти
    #39473641
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kdvНе хочешь неоднозначностей - так сам пиши максимально подробно.Прочитай второе моё предложение. Всё ещё неоднозначно ?

Я стараюсь писать минимально необходимое кол-во слов. Часто моё понимание минимального не совпадает с другими, согласен :)
Но если их вообще не читать, то и говорить не о чем ? :)
...
Рейтинг: 0 / 0
Использование памяти
    #39473678
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
hvladПрочитай второе моё предложение.
вторым предложением ты отмазался от первого :-)
...
Рейтинг: 0 / 0
Использование памяти
    #39473687
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kdvhvladПрочитай второе моё предложение.
вторым предложением ты отмазался от первого :-)Какое поразительное коварство с моей стороны ! :)
...
Рейтинг: 0 / 0
Использование памяти
    #39473889
fraks
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kdvКроме того, запрос сам по себе прекрасен:

select a, b from t
order by c

то есть, х.з. по какому критерию отсортировано.

Я помню твою нелюбовь к запросам которые не показывают поле сортировки, но IMHO это совершенно нормальная ситуация.
Если я знаю по какому критерию отсортировано, или более того, программист подумал за пользователя в каком порядке он обязан смотреть записи, то почему бы и не да?
...
Рейтинг: 0 / 0
Использование памяти
    #39473893
fraks
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
kdvselect a, b from t
order by c

то есть, х.з. по какому критерию отсортировано.

Собственно, в запросе ТС задана сортировка в хронологическом порядке.
Достаточно просто это знать, ну и в логах такая сортировка по умолчанию - логична. :)
...
Рейтинг: 0 / 0
56 сообщений из 56, показаны все 3 страниц
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Использование памяти
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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