|
Сборка мусора
|
|||
---|---|---|---|
#18+
kdvИ возникает вопрос, кто такое приложение писал, что оно так работает. Сам в шоке! Это БД эмитента топливных карт в Иркутске. У него более 4000 контрагентов, половина из которых работает через личный кабинет. Плюс каждую минуту репликация срабатывает, видимо и она нехилое количество новых транзакций открывает. Также у него несколько десятков АЗС (меньше сотни), каждая их которых каждые 15 секунд выполняет запрос в офис. Плюс еще при выполнении некоторых запросов то ли IBX то ли Firebird стартует для внутренних целей дополнительную короткую транзакцию. И всё это на FB2.1 SuperServer x86. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.11.2018, 13:13 |
|
Сборка мусора
|
|||
---|---|---|---|
#18+
DmSer, неужели суперсервер FB2.1 справляется? Я до 3.0 вообще супер старался не использовать ни где. kdvПримерно в такой же мелкой таблице апдейтами за эти 3 дня нагенерилось 1.5млн версий. Даже если в этой таблице два целочисленных столбца, размер такой записи (с кучей версий) - под 50 мегабайт. мда... Тут по идее 4.0 должен облегчить страдания вот таких программ, но частично ... |
|||
:
Нравится:
Не нравится:
|
|||
26.11.2018, 13:33 |
|
Сборка мусора
|
|||
---|---|---|---|
#18+
Симонов ДенисDmSer, неужели суперсервер FB2.1 справляется? Я до 3.0 вообще супер старался не использовать ни где. Летом они хоть перевели на современный сервер (как раз в тот момент первое повреждение было). А до этого обычная XP-ка стояла с 2 ГБ ОЗУ, причём на виртуалке. Как-то FB и тогда справлялся. А теперь всё летает! :) ... |
|||
:
Нравится:
Не нравится:
|
|||
26.11.2018, 13:41 |
|
Сборка мусора
|
|||
---|---|---|---|
#18+
Стараемся следить, чтобы все запросы исполнялись максимально быстро. Если проблем с запросами нет, то и SS на одном ядре справляется. Если запросы будут тормозить, то и Classic загнётся. При этом в системе громадное количество мелких запросов (по сложности сложности SELECT FIELD FROM RDB$DATABASE). Не факт, что с Classic будет шустрее (хотя везде по возможности пул подключений используется). Сейчас у клиента 16 ГБ ОЗУ, можно попробовать на SuperClassic перевести. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.11.2018, 14:12 |
|
Сборка мусора
|
|||
---|---|---|---|
#18+
Мимопроходящийцепляться нужно было с отключенной сборкой мусора Ээээ... Кстати, не везде это получится. Вот как это сделать из php, к примеру, через стандартное дополнение ibase?! У меня была такая потребность недавно.С использованием клиентских библиотек или с прямым доступом сколько угодно, no_garbage_collect - это хорошо.А вот с ПыхПых проблема. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.11.2018, 14:19 |
|
Сборка мусора
|
|||
---|---|---|---|
#18+
26.11.2018 14:19, o_v_a пишет: > Ээээ... Кстати, не везде это получится. Вот как это сделать из php, к примеру, через стандартное дополнение ibase?! > У меня была такая потребность недавно.С использованием клиентских библиотек или с прямым доступом сколько угодно, no_garbage_collect - это хорошо.А вот с ПыхПых проблема. с BDE тоже не всё в шоколадзЭ Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
26.11.2018, 14:28 |
|
Сборка мусора
|
|||
---|---|---|---|
#18+
o_v_a, у вас в БД только пых пишет? ... |
|||
:
Нравится:
Не нравится:
|
|||
26.11.2018, 14:50 |
|
Сборка мусора
|
|||
---|---|---|---|
#18+
Не, только веб-сервисы. Оффтоп, раз уж заикнулся: У одного клиента на днях после массовой чистки старых данных (удалили несколько десятков миллионов записей из нескольких таблиц) сервер начал помирать - диски не справлялись. Я было захотел упростить ему существование, используя no_garbage_collect. Посрубал все некритичные коннекты, явно натравил на базу gfix -sweep, тот яро вгрызся делать записям expunge. И, думал, сейчас на использование no_garbage_collect переведу всё остальное, что можно, но... Но с локальными коннектами из клиент-серверных приложений я б справился, а тут быстрее и сразу первыми всплыли коннекты от внешних сервисов, с которыми на веб-серверах в скриптах на php ничего сделать не вышло. Ну не умеет php в модуле ibase произвольные параметры использовать при формировании DPB. Потому просто периодически раз в 5-7 часов снимал клиенту лишнюю нагрузку с сервера, прикрывая часть внешних коннектов (нельзя было полностью перекрывать доступ, часть сервисов должна была работать при любых условиях). А gfix лопатил базу (хоть и небольшая, 15 Гигов) 27 часов! Там швах с дисковой подсистемой - база на зеркале на интегрированном в Intel-чипсет контроллере на обычной десктопной материнке, админы местные в курсе, сами такое захотели, но не от хорошей жизни. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.11.2018, 17:13 |
|
Сборка мусора
|
|||
---|---|---|---|
#18+
o_v_aИ, думал, сейчас на использование no_garbage_collect переведу всё остальное, что можно, но... Но с локальными коннектами из клиент-серверных приложений я б справился, а тут быстрее и сразу первыми всплыли коннекты от внешних сервисов, с которыми на веб-серверах в скриптах на php ничего сделать не вышло.Запусти isql, открой в нём тр-цию (не RCRO), просто выполнив любой запрос - и всё. Сборка мусора заблокирована. Но имей в виду - sweep не волшебник, он точно так же не сможет собирать мусор. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.11.2018, 17:29 |
|
Сборка мусора
|
|||
---|---|---|---|
#18+
o_v_a, в индексах ключи мусорных записей удалял. После массовой чистки всегда так. Кстати без индексов сборка мусора прошла бы быстро. o_v_aПосрубал все некритичные коннекты, явно натравил на базу gfix -sweep, тот яро вгрызся делать записям expunge. И, думал, сейчас на использование no_garbage_collect переведу всё остальное, что можно, но... Но с локальными коннектами из клиент-серверных приложений я б справился, а тут быстрее и сразу первыми всплыли коннекты от внешних сервисов, с которыми на веб-серверах в скриптах на php ничего сделать не вышло. На SS можно было на это время перевести чисто на фоновую сборку мусора. Единственное что с рестартом сервиса FB. Впрочем gfix всё равно тормозил бы дисковую. ... |
|||
:
Нравится:
Не нравится:
|
|||
26.11.2018, 17:33 |
|
Сборка мусора
|
|||
---|---|---|---|
#18+
Ну вот, опять проблема с этой базой. Попросил клиента отключить все приложения подключенные к базе данных, затем остановить службу. После этого службу запустили и выполнили gfix -v -full Выдал: Number of record level errors : 1 Кстати, gfix -sweep после этого отработал моментально. Видимо, мусор был собран при первом вызове gfix. Похоже, Firebird 2.1 SS также в шоке от такого количества транзакций :) Firebird 2.1 там один из последних (2.1.5 от 2016г.) ... |
|||
:
Нравится:
Не нравится:
|
|||
26.11.2018, 20:49 |
|
Сборка мусора
|
|||
---|---|---|---|
#18+
DmSerПохоже, Firebird 2.1 SS также в шоке от такого количества транзакций :) не в количестве транзакций дело. Самих транзакций могут быть мульоны, но если в них обновляется мало записей, версий будет тоже мало. А если одна транзакция засандалит апдейт по 10млн записей - так и будет 10млн версий при одной транзакции. А 2.1.5, это, конечно, обалдеть какая свежая версия. Я обычно рекомендую скачать релизноты к действительно последней 2.1, и почитать раздел багфиксов. https://www.firebirdsql.org/file/documentation/release_notes/html/rlsnotes217.html#rnfb210-v217 ... |
|||
:
Нравится:
Не нравится:
|
|||
26.11.2018, 21:52 |
|
Сборка мусора
|
|||
---|---|---|---|
#18+
Глючу наверное. У меня даты файлов для 2.1.5 отображаются 19.07.2016. Странно... ... |
|||
:
Нравится:
Не нравится:
|
|||
26.11.2018, 23:24 |
|
Сборка мусора
|
|||
---|---|---|---|
#18+
Симонов Денисo_v_a, в индексах ключи мусорных записей удалял. После массовой чистки всегда так. Кстати без индексов сборка мусора прошла бы быстро. Дропнуть первичный индекс на живой базе с двумя десятками коннектов, активно работающих с этой таблицей - без шансов скорее всего. Кстати, этот здоровенный индекс так и остался с глубиной 4, а он мне нужен там после чистки с глубиной 3. И тыщи страниц в нём (6 тыщ из 18) с заполнением 0-19%. Ну, се-ля-ви, это поправится только бэкапом-рестором. Абориген-админ (бабушка - божий одуванчик) уже запланировала ночные работы. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2018, 08:31 |
|
Сборка мусора
|
|||
---|---|---|---|
#18+
DmSerГлючу наверное. У меня даты файлов для 2.1.5 отображаются 19.07.2016. Странно... Видимо пару лет назад на компе, где собирался инсталлятор нашего ПО, хозяйничал вирус, затем его лечили, в результате EXE-файлы из каталога FIREBIRD\bin оказались изменены. ... |
|||
:
Нравится:
Не нравится:
|
|||
27.11.2018, 11:02 |
|
Сборка мусора
|
|||
---|---|---|---|
#18+
Симонов Денисo_v_a, в индексах ключи мусорных записей удалял. После массовой чистки всегда так. Кстати без индексов сборка мусора прошла бы быстро. Подскажите, в такой ситуации - было бы быстрее отключить индексы, провести сборку и включить индексы обратно? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2018, 10:22 |
|
Сборка мусора
|
|||
---|---|---|---|
#18+
Cobalt747, PK, FK всё равно не отключишь ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2018, 10:25 |
|
Сборка мусора
|
|||
---|---|---|---|
#18+
Симонов ДенисCobalt747, PK, FK всё равно не отключишь Я что-то смутно вспоминаю про прямой апдейт rdb$index_inactive. Склерозничаю или раньше прокатывало, а теперь нет? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2018, 13:32 |
|
Сборка мусора
|
|||
---|---|---|---|
#18+
Старый плюшевый мишкаЯ что-то смутно вспоминаю про прямой апдейт rdb$index_inactive. В трёшке такие трюки запретили. И я сомневаюсь что раньше они работали. Да и сборка мусора в индексах хитро выполняется. Но тут пожалуй что Влад может прояснить. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2018, 13:44 |
|
Сборка мусора
|
|||
---|---|---|---|
#18+
Зато всегда (и тогда, и сейчас) их можно удалить, а потом заново создать. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2018, 14:25 |
|
Сборка мусора
|
|||
---|---|---|---|
#18+
o_v_a, слишком много геморроя. Базу надо остановить. Работать в ней всё это время нельзя. А если ещё и ошибка при этом произойдёт, то база запорота будет. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2018, 16:34 |
|
Сборка мусора
|
|||
---|---|---|---|
#18+
Так то по обстоятельствам. Если очень надо, то пути решения имеются. Главное - это знать, где инструмент сельхозназначения разбросан. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.12.2018, 16:51 |
|
Сборка мусора
|
|||
---|---|---|---|
#18+
19.12.2018 13:44, Симонов Денис пишет: > В трёшке такие трюки запретили. И я сомневаюсь что раньше они работали. не сумлевайся. нормально всё отключается, и ПК и ФК. но вот взыграл "синдром вахтёра" и лавочку прикрыли. не пущать и воспрещать! ога. > Да и сборка мусора в индексах хитро выполняется. Но тут пожалуй что Влад может прояснить. не знаю как сейчас, а в полуторке после массовых операций насилия над таблицей отключение индексов помогало даже тогда, когда процесс сборки мусора уже стартовал. причем эффект был значительный. Posted via ActualForum NNTP Server 1.5 ... |
|||
:
Нравится:
Не нравится:
|
|||
20.12.2018, 11:45 |
|
Сборка мусора
|
|||
---|---|---|---|
#18+
Мимопроходящий, в полуторке сборка мусора в индексах с хреновой селективностью вообще была печальной. В двушке это правили и теперь стало намного лучше. Но тем не менее сборку мусора в индексах всё равно быстрой назвать нельзя. ИХМО. Ситуацию в ряде случаев могли бы улучшать частичные индексы, секционирование и табличные пространства. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.12.2018, 12:38 |
|
Сборка мусора
|
|||
---|---|---|---|
#18+
Симонов ДенисИ я сомневаюсь что раньше они работали. там магическое число в столбце активности использовалось. не 0 или 1, а 3. При ресторе так делается. В метаданных пишется активность 3, заливаются данные, а в конце уже индексы переводятся в активное состояние. Так что, для PK, FK и UNIQUE можно было троечку поставить, коммит, а потом опять 1 (или что там) и коммит. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.12.2018, 13:26 |
|
|
start [/forum/topic.php?fid=40&gotonew=1&tid=1560869]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
161ms |
get topic data: |
11ms |
get first new msg: |
9ms |
get forum data: |
3ms |
get page messages: |
68ms |
get tp. blocked users: |
1ms |
others: | 11ms |
total: | 294ms |
0 / 0 |