Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Использование памяти
|
|||
|---|---|---|---|
|
#18+
У меня на сервере относительно небольшая БД файрберда и относительно много свободной оперативной памяти. Эту БД туда можно загрузить раза 3 целиком и еще место останется. Но файрберд почему-то использует память очень экономично. Какие бы настройки подкрутить, чтобы он стал попрожорливее и интенсивнее использовал память? Явно же на скорости работы это положительно скажется. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2017, 11:00 |
|
||
|
Использование памяти
|
|||
|---|---|---|---|
|
#18+
Роман Янковский, А версия ФБ какая? SS или Classic? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2017, 11:07 |
|
||
|
Использование памяти
|
|||
|---|---|---|---|
|
#18+
KreatorXXI, Версия 3.0 ServerMode = Super ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2017, 11:10 |
|
||
|
Использование памяти
|
|||
|---|---|---|---|
|
#18+
Роман ЯнковскийЯвно же на скорости работы это положительно скажется.Будет пример тормозящего запроса со статистикой исполнения? А то как-то голословно все. Может серверу и не надо больше памяти? Крутить настройки надо осмысленно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2017, 11:20 |
|
||
|
Использование памяти
|
|||
|---|---|---|---|
|
#18+
Ivan_Pisarevsky, ну настройки страничного кеша по умолчанию для SS в 3.0 тоже смехатворны. Роман Янковский, для начала Код: plaintext 1. если быстродействие устраивает дальше не крути. Я ставлю эти настройки в databases.conf под конкретную БД ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2017, 11:25 |
|
||
|
Использование памяти
|
|||
|---|---|---|---|
|
#18+
Роман Янковский, Я, кстати, поднимал типа такого же вопроса. У нас небольшая БД, вполне вся может влезть в оперативку. Казалось бы скорость при этом должна увеличится существенно. Но ФБ так не работает. А народ требует тестов, которые покажут провалы по быстродействию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2017, 14:17 |
|
||
|
Использование памяти
|
|||
|---|---|---|---|
|
#18+
Ivan_PisarevskyРоман ЯнковскийЯвно же на скорости работы это положительно скажется.Будет пример тормозящего запроса со статистикой исполнения? А то как-то голословно все. Может серверу и не надо больше памяти? Крутить настройки надо осмысленно. Ну вот например см скриншот. Полторы секунды на сущую ерунду. Пара сотен таких запросов уже проблема. Если бы файрберд работал медленнее чем я хочу, выедая все доступные ресурсы, я бы понял в чем дело. Но и память, и CPU почти не использует. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2017, 15:27 |
|
||
|
Использование памяти
|
|||
|---|---|---|---|
|
#18+
Рома, чем тебя не устроил Оракл? чего ты с него слез? Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2017, 15:39 |
|
||
|
Использование памяти
|
|||
|---|---|---|---|
|
#18+
Роман Янковский, А статистику выполнения таки можно глянуть? Очень хочется увидеть как на полутора тысячах записей можно получить полторы секунды. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2017, 16:20 |
|
||
|
Использование памяти
|
|||
|---|---|---|---|
|
#18+
Роман Янковский, http://www.ibase.ru/files/firebird/Firebird_Hardware_Guide_2015_rus.pdf Роман ЯнковскийЭту БД туда можно загрузить раза 3 целиком операционная система БД в кэш и грузит. В общем, читайте документ. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2017, 16:27 |
|
||
|
Использование памяти
|
|||
|---|---|---|---|
|
#18+
Роман Янковский, до кучи - смотреть надо page reads и fetches from cache. А то что на экране - ерунда. Кроме того, запрос сам по себе прекрасен: select a, b from t order by c то есть, х.з. по какому критерию отсортировано. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2017, 16:33 |
|
||
|
Использование памяти
|
|||
|---|---|---|---|
|
#18+
Роман Янковский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 | +-------------------------------+-----------+-----------+-------------+---------+---------+---------+----------+----------+----------+ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2017, 16:40 |
|
||
|
Использование памяти
|
|||
|---|---|---|---|
|
#18+
kdv...запрос сам по себе прекрасен: select a, b from t order by c то есть, х.з. по какому критерию отсортировано. И что тут не так? Во многих случаях значение критерия сортировки или фильтрации юзеру видеть не нужно. Или не сразу нужно. К примеру, нужно просмотреть всю номенклатуру: вытягиваешь список 10 000 000 id's, отсортированных по типу товара и наименованию, затем, сканируя список id's, подтягиваешь по мере надобности остальные поля. И юзеру хорошо (10 000 000 позиций на экране видит), и железо не дохнет от перегрузки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2017, 16:43 |
|
||
|
Использование памяти
|
|||
|---|---|---|---|
|
#18+
тот же запрос без order by сколько работает? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2017, 16:44 |
|
||
|
Использование памяти
|
|||
|---|---|---|---|
|
#18+
Ivan_Pisarevskyтот же запрос без order by сколько работает? Столько же. Запрос резко ускоряется до 0.03сек, если убрать условие "and i.station_id = 50". Предупреждая вопросы - индекс по этому полю имеется. Дело-то не в одном запросе. В принципе есть ощущение, что что-то не так. Тут полсекунды, там полторы, тут еще чуть-чуть. Вроде немного, но в итоге накапливается большое время. Это нехорошо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2017, 18:14 |
|
||
|
Использование памяти
|
|||
|---|---|---|---|
|
#18+
pastorА статистику выполнения таки можно глянуть? Очень хочется увидеть как на полутора тысячах записей можно получить полторы секунды. Я не большой специалист по firebird. Я с удовольствием покажу статистику, если мне намекнут как ее посмотреть. Я показал окошко Statistics. Глупо, понимаю, но что есть)) Так что, пожалуйста, подскажите. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2017, 18:16 |
|
||
|
Использование памяти
|
|||
|---|---|---|---|
|
#18+
МимопроходящийРома, чем тебя не устроил Оракл? чего ты с него слез? Не я такой, жизнь такая. В этом проекте файрберд давно уже, не менять же его. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2017, 18:16 |
|
||
|
Использование памяти
|
|||
|---|---|---|---|
|
#18+
Роман ЯнковскийВ принципе есть ощущение, что что-то не так. Смотреть планы и статистику тебе уже предлагали. Чтобы не казалось. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2017, 18:16 |
|
||
|
Использование памяти
|
|||
|---|---|---|---|
|
#18+
kdvРоман Янковский, до кучи - смотреть надо page reads и fetches from cache. А то что на экране - ерунда. Кроме того, запрос сам по себе прекрасен: select a, b from t order by c то есть, х.з. по какому критерию отсортировано. Что значит х.з.? Чтобы сортировать по полю нужно обязательно добавлять его в select? Это какие-то новости sql? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2017, 18:21 |
|
||
|
Использование памяти
|
|||
|---|---|---|---|
|
#18+
Роман ЯнковскийЗапрос резко ускоряется до 0.03сек, если убрать условие "and i.station_id = 50" напиши and i.station_id+0 = 50 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2017, 18:22 |
|
||
|
Использование памяти
|
|||
|---|---|---|---|
|
#18+
хотя гораздо лучше было бы если условие соединения все бы сидело в одном композитном индексе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2017, 18:25 |
|
||
|
Использование памяти
|
|||
|---|---|---|---|
|
#18+
Ivan_PisarevskyРоман ЯнковскийЗапрос резко ускоряется до 0.03сек, если убрать условие "and i.station_id = 50" напиши and i.station_id+0 = 50 Стало выполнятся за 0.05сек. Это что за магия такая? :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2017, 18:25 |
|
||
|
Использование памяти
|
|||
|---|---|---|---|
|
#18+
Роман ЯнковскийЯ с удовольствием покажу статистику, если мне намекнут как ее посмотреть. Я показал окошко Statistics. Глупо, понимаю, но что есть)) Используй isql, SET STATS ON, SET PLAN ON. Posted via ActualForum NNTP Server 1.5 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2017, 18:29 |
|
||
|
Использование памяти
|
|||
|---|---|---|---|
|
#18+
Роман ЯнковскийIvan_Pisarevskyпропущено... напиши and i.station_id+0 = 50 Стало выполнятся за 0.05сек. Это что за магия такая? :) Таким способом ты отключил использование "плохого" индекса по station_id . Сие тайное знание имхо, специально нигде не описано, но можно поискать здесь по совокупности слов "хинт" и "индекс". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2017, 18:47 |
|
||
|
Использование памяти
|
|||
|---|---|---|---|
|
#18+
Роман ЯнковскийЧто значит х.з.? Чтобы сортировать по полю нужно обязательно добавлять его в select? Это какие-то новости sql? я понимаю, что бывает всякая специфика, и конкретная реализация SQL не запрещает, но вот например - вижу я в результате запроса фамилии людей. Которые идут в каком-то порядке. Каком - я не вижу. А они - сюрприз! - отсортированы по номеру паспорта. Или по дате рождения. То есть, оценить, по какому критерию конкретные записи идут одна за другой, я не могу. Роман ЯнковскийЭто что за магия такая? :) вполне может быть, что у вас там много лишних индексов создано. Чччдпросмотреть всю номенклатуру: вытягиваешь список 10 000 000 id's, с этим я не спорю. К тому же у автора выдается какой-то лог, вероятно, время не важно, важна последовательность. Но спросить-то все равно надо было :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2017, 18:49 |
|
||
|
Использование памяти
|
|||
|---|---|---|---|
|
#18+
чччДТаким способом ты отключил использование "плохого" индекса по station_id . . Эээ... а можно для нубов: чем он плохой и как вообще определить что индекс - плохой? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2017, 20:19 |
|
||
|
Использование памяти
|
|||
|---|---|---|---|
|
#18+
alekcvp, "плохой" индекс - индекс с плохой избирательностью (селективностью), т.е. большим количеством дубликатов ключей. Классический пример - в таблице 1000 записей, по столбцу построен индекс, в столбце 2 значения (м и ж, 1 и 2, и т.д.). Одно значение ключа - 990 записей, другое - 10. Поиск по первому значению приводит к чтению почти всех страниц с диска, т.е. к лишним операциям ввода-вывода, т.к. все равно выберется 990 записей (почти все). Поиск на второе значение - очень выгоден, т.к. выберет всего 10 записей. Но оптимизатор не знает, поиск какого значения будет производиться, поэтому индекс в плане скорее всего будет использоваться. Так что тут все зависит от ситуации, поиск каких значений идет по индексу, и сколько их. Еще "качество" индекса, если он по нескольким столбцам, зависит от порядка столбцов в индексе, и их селективности. В общем, создавать индексы вручную (кроме ПК и ФК) нужно только если они явно ускоряют производительность конкретного запроса. Бывает что разработчик наоборот, сначала нафигачит индексов на все случаи жизни, а потом удивляется почему "убирание" индекса ускоряет запрос. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2017, 20:28 |
|
||
|
Использование памяти
|
|||
|---|---|---|---|
|
#18+
Ага, спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2017, 21:38 |
|
||
|
Использование памяти
|
|||
|---|---|---|---|
|
#18+
kdvРоман ЯнковскийЧто значит х.з.? Чтобы сортировать по полю нужно обязательно добавлять его в select? Это какие-то новости sql? я понимаю, что бывает всякая специфика, и конкретная реализация SQL не запрещает, но вот например - вижу я в результате запроса фамилии людей. Которые идут в каком-то порядке. Каком - я не вижу. А они - сюрприз! - отсортированы по номеру паспорта. Или по дате рождения. То есть, оценить, по какому критерию конкретные записи идут одна за другой, я не могу. Этот конкретный запрос используется в хранимой процедуре, где важно обрабатывать записи в хронологическом порядке. При этом сама дата не важна. Только порядок. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2017, 22:48 |
|
||
|
Использование памяти
|
|||
|---|---|---|---|
|
#18+
Я так и подумал сначала, что этот трюк отключает индекс. Но потом я вообще задисейблил этот индекс и быстрее не стало. Поэтому засомневался. А потом уже после того как запостил вопрос, увидел, что на это поле есть еще и внешний ключ и в когда я дисейблю индекс, в план попадает он. Индекс я прибить могу, нафиг он нужен, а вот внешний ключ отключать стремно как-то. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.06.2017, 22:55 |
|
||
|
Использование памяти
|
|||
|---|---|---|---|
|
#18+
kdvalekcvp, "плохой" индекс - индекс с плохой избирательностью (селективностью), т.е. большим количеством дубликатов ключей. Классический пример - в таблице 1000 записей, по столбцу построен индекс, в столбце 2 значения (м и ж, 1 и 2, и т.д.). Одно значение ключа - 990 записей, другое - 10. Поиск по первому значению приводит к чтению почти всех страниц с диска, т.е. к лишним операциям ввода-вывода, т.к. все равно выберется 990 записей (почти все). Поиск на второе значение - очень выгоден, т.к. выберет всего 10 записей. Но оптимизатор не знает, поиск какого значения будет производиться, поэтому индекс в плане скорее всего будет использоваться. Так что тут все зависит от ситуации, поиск каких значений идет по индексу, и сколько их.. Это кстати не объясняет почему с индексом значительно медленнее, чем без индекса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2017, 00:50 |
|
||
|
Использование памяти
|
|||
|---|---|---|---|
|
#18+
Роман ЯнковскийIvan_Pisarevskyпропущено... напиши and i.station_id+0 = 50 Стало выполнятся за 0.05сек. Это что за магия такая? :) Это отсутствие реального оптимизатора в ФБ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2017, 00:53 |
|
||
|
Использование памяти
|
|||
|---|---|---|---|
|
#18+
Сделал индекс по двум полям, нормально стало. Спасибо огромное! Но это не объясняет мое изначальное недоумение. Ну допустим запрос плохой и индексы не те. Так пусть файрберд жрет ресурсы, чтоб его выполнить. Эти таблицы все целиком 20 раз в память поместятся, оно тупым перебором должно было быстрее работать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2017, 01:01 |
|
||
|
Использование памяти
|
|||
|---|---|---|---|
|
#18+
На всякий случай еще старую медленную статистику запосчу. Завтра. Извиняюсь за много постов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2017, 01:03 |
|
||
|
Использование памяти
|
|||
|---|---|---|---|
|
#18+
И еще. Такое вот: Код: sql 1. 2. 3. 4. 5. > 1080 Код: sql 1. 2. 3. 4. 5. > 20964 Точно-точно у индекса по select_id плохая селективность? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2017, 04:16 |
|
||
|
Использование памяти
|
|||
|---|---|---|---|
|
#18+
Роман ЯнковскийТочно-точно у индекса по select_id плохая селективность?Планы и статистику выполнения мы увидим ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2017, 10:05 |
|
||
|
Использование памяти
|
|||
|---|---|---|---|
|
#18+
Роман ЯнковскийНу допустим запрос плохой и индексы не те. Так пусть файрберд жрет ресурсы, чтоб его выполнить. Эти таблицы все целиком 20 раз в память поместятся, оно тупым перебором должно было быстрее работать. Ты всерьез полагаешь, что он с диска каждый раз нужную страницу читает, потому медленно работает ? Сдается мне, что к моменту выполнения самого запроса сколько можно страниц уже прочитано или они читаются по мере надобности и толку от того, что они будут прочитаны заранее будет немного. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2017, 10:38 |
|
||
|
Использование памяти
|
|||
|---|---|---|---|
|
#18+
Роман ЯнковскийТак пусть файрберд жрет ресурсы, чтоб его выполнить. судя по этой фразе, вы не читали статью про железо и фб, которую я вам дал. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2017, 11:35 |
|
||
|
Использование памяти
|
|||
|---|---|---|---|
|
#18+
С 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 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2017, 11:47 |
|
||
|
Использование памяти
|
|||
|---|---|---|---|
|
#18+
То же самое с включенным индексом по двум полям. Current memory = 456675728 Delta memory = 6607232 Max memory = 992638888 Elapsed time= 1.250 sec Buffers = 50000 Reads = 13818 Writes = 184 Fetches = 337405 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2017, 12:02 |
|
||
|
Использование памяти
|
|||
|---|---|---|---|
|
#18+
Роман ЯнковскийBuffers = 50000 Reads = 13818 если суперсервер, и 3.0, то можно увеличивать кэш до 200000 тысяч, только тогда надо не забыть и FileSystemCacheThreshold тогда увеличить, например до 300к. база какого размера, какой размер страницы, и сколько RAM на сервере? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2017, 12:15 |
|
||
|
Использование памяти
|
|||
|---|---|---|---|
|
#18+
Роман ЯнковскийТо же самое с включенным индексом по двум полям.Ты серьёзно считаешь, что кто-то стоит у тебя за спиной и видит эти индексы и поля ? И где план запроса ? Кроме того, желательно показывать детальную (потабличную) статистику выполнения, IBE в помощь. И DDL всех затронутых объектов (таблиц и индексов). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2017, 13:47 |
|
||
|
Использование памяти
|
|||
|---|---|---|---|
|
#18+
kdvесли суперсервер, и 3.0, то можно увеличивать кэш до 200000 тысячЗачем ? Reads и так меньше Buffers, там всё и так попадает в кеш. Есс-но, не до первого выполнения запроса ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2017, 13:48 |
|
||
|
Использование памяти
|
|||
|---|---|---|---|
|
#18+
hvlad, reads - это то что не влезло в кэш. Если бы оно влезало, reads было бы 0, при повторном выполнении запроса, разумеется. Но вероятно, раз приведены "с индексом и без", то скорее всего запросы можно считать повторными, и видимо, не влезает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2017, 15:37 |
|
||
|
Использование памяти
|
|||
|---|---|---|---|
|
#18+
hvladРоман ЯнковскийТо же самое с включенным индексом по двум полям.Ты серьёзно считаешь, что кто-то стоит у тебя за спиной и видит эти индексы и поля ? Я считаю, что отвечающие читали тему. Мне предложили сделать индекс по условию соединения и я его сделал. hvladИ где план запроса ? Не будет плана запроса. Третий раз его постить наверно уже лишнее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2017, 16:47 |
|
||
|
Использование памяти
|
|||
|---|---|---|---|
|
#18+
kdv, спасибо, попробую сегодня ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2017, 16:47 |
|
||
|
Использование памяти
|
|||
|---|---|---|---|
|
#18+
[quot kdv]Роман Янковскийбаза какого размера, какой размер страницы, и сколько RAM на сервере? база 7.5гб (хм, подросла с тех пор, как я в последний раз смотрел, но ram можно увеличить, если это поможет) ram 16gb страница 8192 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2017, 17:02 |
|
||
|
Использование памяти
|
|||
|---|---|---|---|
|
#18+
Роман ЯнковскийНе будет плана запроса. Третий раз его постить наверно уже лишнее.Весьма глупое поведение. Мне эти планы, наверное, не очень нужны, так что я как-нибудь переживу этот отказ :) Подскажу: у запросов с и без использования индексов разные планы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2017, 17:22 |
|
||
|
Использование памяти
|
|||
|---|---|---|---|
|
#18+
kdvreads - это то что не влезло в кэшСерьёзно ? :) kdvскорее всего запросы можно считать повторнымиСлишком много предположений и слишком мало надежды получить минимально необходимую инф-цию ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2017, 17:24 |
|
||
|
Использование памяти
|
|||
|---|---|---|---|
|
#18+
Роман Янковскийбаза 7.5гб (хм, подросла с тех пор, как я в последний раз смотрел, но ram можно увеличить, если это поможет) статью читайте же. Если база 7 гиг, а памяти 16, вероятно что база уже в памяти. RAMMAP это показывает (на двух последних закладках). Понятно, что смотреть надо при интенсивной работе, а не при выполнении одного тестового запроса. Дальше, при странице 8к и 50000 страниц кэша кэш получается 400 мегабайт. Так что его можно спокойно увеличить раза в 4, как я и предложил (если ФБ 64битный. Если 32битный, то лучше не надо). Потом, во время работы вы можете посмотреть, сколько занимает процесс firebird.exe. Вы же не написали - сколько. Вы сообщили "использует память очень экономично". И 7 гиг 3 раза в 16 гиг не влезет. Влезет только 2 раза. В общем, читайте статью и настраивайте. Там все есть - и рекомендации, и формулы, надо только прочитать внимательно :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2017, 17:28 |
|
||
|
Использование памяти
|
|||
|---|---|---|---|
|
#18+
hvladСерьёзно ? :) серьезно. это я к тому, что ты сам выдал то, что "прочитывается неоднозначно". Reads это сколько страниц считано с диска, а не из кэша. Если кэш N страниц, то всего прочитано страниц Reads + (от 0 до N), в зависимости от ситуации - первый запрос после коннекта, второй запрос, классик или супер, есть-ли другие запросы между выполнением "тестовых", и т.д. Не хочешь неоднозначностей - так сам пиши максимально подробно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2017, 17:34 |
|
||
|
Использование памяти
|
|||
|---|---|---|---|
|
#18+
kdvНе хочешь неоднозначностей - так сам пиши максимально подробно.Прочитай второе моё предложение. Всё ещё неоднозначно ? Я стараюсь писать минимально необходимое кол-во слов. Часто моё понимание минимального не совпадает с другими, согласен :) Но если их вообще не читать, то и говорить не о чем ? :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2017, 17:48 |
|
||
|
Использование памяти
|
|||
|---|---|---|---|
|
#18+
hvladПрочитай второе моё предложение. вторым предложением ты отмазался от первого :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2017, 22:33 |
|
||
|
Использование памяти
|
|||
|---|---|---|---|
|
#18+
kdvhvladПрочитай второе моё предложение. вторым предложением ты отмазался от первого :-)Какое поразительное коварство с моей стороны ! :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 17.06.2017, 23:08 |
|
||
|
Использование памяти
|
|||
|---|---|---|---|
|
#18+
kdvКроме того, запрос сам по себе прекрасен: select a, b from t order by c то есть, х.з. по какому критерию отсортировано. Я помню твою нелюбовь к запросам которые не показывают поле сортировки, но IMHO это совершенно нормальная ситуация. Если я знаю по какому критерию отсортировано, или более того, программист подумал за пользователя в каком порядке он обязан смотреть записи, то почему бы и не да? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.06.2017, 04:20 |
|
||
|
Использование памяти
|
|||
|---|---|---|---|
|
#18+
kdvselect a, b from t order by c то есть, х.з. по какому критерию отсортировано. Собственно, в запросе ТС задана сортировка в хронологическом порядке. Достаточно просто это знать, ну и в логах такая сортировка по умолчанию - логична. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.06.2017, 05:17 |
|
||
|
|

start [/forum/topic.php?all=1&fid=40&tid=1561529]: |
0ms |
get settings: |
8ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
69ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
75ms |
get tp. blocked users: |
2ms |
| others: | 279ms |
| total: | 470ms |

| 0 / 0 |
