|
Notes |
|
|
|
|
Ну, сразу отмонтировать и сбрасывать все кэши перебор, а вот отрубанине секунд через 30 после последнего использования вполне можно было бы реализовать, если оно еще не реализовано. |
|
|
|
(0011429)
|
|
zed
|
|
28-05-2013 14:44
|
|
|
Давно были такие мысли, но не сообразил, как сообщить хранилищу, что его уже не используют, а переключились на другую карту. |
|
|
|
|
|
А никак ему сообщать не нужно. Только по таймауту с последнего обращения. |
|
|
|
|
>сразу отмонтировать и сбрасывать все кэши перебор, а вот отрубанине секунд через 30 после последнего использования вполне можно было бы реализовать
Не все, а только тот с которого и переключаемся. То есть - всегда один за раз.
То есть, по событию "Карта\слой переключены\отключены" - проверять\форсировать полное закрытие предыдущего хранилища перед открытием нового, да и всё.
Ну, по крайней мере я это так вижу. :)
>Только по таймауту с последнего обращения.
Тогда будем получать Detach кэша даже если карту не меняли - а просто отошли покурить. |
|
|
|
(0011433)
|
|
zed
|
|
29-05-2013 04:43
|
|
>>Только по таймауту с последнего обращения.
>Тогда будем получать Detach кэша даже если карту не меняли - а просто отошли покурить.
Вот-вот. Нужно более продуманное поведение, а не тупо по таймауту. |
|
|
|
|
Более продуманное будет на порядок сложнее и менее надежным. Просто обращаться к карте быть не только тогда когда она отображается в основном окне, но и тогда когда она открыта в миникарте, или когда идет закачка по региону, или когда идет склейка, или экспорт и еще куча случаев, которые можно забыть или которые появятся позже.
А закрытие файлов по вменяемому таймауту вполне себе хорошая штука. Ну будет пауза в пол секунды после возвращения с перекура и что? Это будет не баг, а фитча, зато если в это время комп помрет, то кэш не попортится даже если карта была включена. |
|
|
|
(0011435)
|
|
zed
|
|
29-05-2013 05:29
|
|
> или когда идет закачка по региону, или когда идет склейка, или экспорт и еще куча случаев
В этих случаях как раз-таки задержка не критична и можно закрывать по таймауту, если юзер не юзает в гуе данную карту. Т.е. по хорошему, в хранилище нужно слать евент "юзер включил/выключил карту", а дальше оно уже пускай само думает.
>А закрытие файлов по вменяемому таймауту вполне себе хорошая штука.
Ну, минут через 30-60 да, можно закрывать. Но никак не через 30 сек. |
|
|
|
(0011436)
|
|
vdemidov
|
29-05-2013 05:57
(edited on: 29-05-2013 06:00) |
|
>>А закрытие файлов по вменяемому таймауту вполне себе хорошая штука.
> Ну, минут через 30-60 да, можно закрывать. Но никак не через 30 сек.
Та ну ладно. Сколько открытие базы занимает? Максимум пару секунд. Таймаут 30 секунд конечно перебор, а пара минут полного бездействия вполне себе повод закрыть все открытые файлы.
PS: То что ты хочешь сделать может где-то и будет чуток эффективнее, но очень редко и дофига мороки, а простой таймаут закроет 95% проблем и делаетася практически элементарно. Но я не настаиваю. Можно оставить как есть. Меня это не напрягает.
|
|
|
|
|
>Ну, минут через 30-60 да, можно закрывать. Но никак не через 30 сек.
Цимес момента в данном конкретном тикете в том, чтобы отключать неиспользуемую карту по возможности МОМЕНТАЛЬНО. Толку от введения отключения через час - если еще час оно будет висеть в памяти, со всеми своими последствиями при случайном крэше за тот самый час? И уже не используемый кэш с диска я еще целый час не смогу убить иначе, кроме как выйдя с саса?
То есть, будет то же самое что в шапке тикета и так. Если нельзя ввести цивилизованными методами с передачей в хранилище - тогда имхо лучше короткий таймаут имени вдемидова, чем часовой имени зеда. 30 сек это конечно сильно круто, посему предлагаю 3 минуты (как на сетевые операции) или 5.
Либо, сугубо на правах маразма - вообще открывать любой беркли по умолчанию как R\O и держать его так ровно до тех пор, пока не приспичит вносить изменения (и там - таймаут на R\W режим). Имею мнение, что 99% времени юзания любого кэша как раз на чтение - ну так и открывать его именно в нем, и пускай себе сас крешится сколько угодно. |
|
|
|
|
>а пара минут полного бездействия вполне себе повод закрыть все открытые файлы.
Вопрос: как будет отрабатываться ситуация "активно работаем (таймаута по САСу нет и не планируется), а карту уже переключили и работаем с другой"?
С первой локи кто снимет-то при этом, НЕ ТРОГАЯ вторую?
|
|
|
|
(0011439)
|
|
zed
|
|
29-05-2013 06:30
|
|
>Сколько открытие базы занимает?
Зависит от скорости носителя. Но лаг таки присутствует в любом случае.
>С первой локи кто снимет-то при этом, НЕ ТРОГАЯ вторую?
Файлы БД закроются через 5 минут, а env и его ram-кэш будет жить до упора. В зависимости от настроек env, при закрытии БД данные могут как полностью записываться, так и оставаться в логе (а лог ещё и сам может быть по большей части в памяти и запишется только при закрытии env). |
|
|
|
|
>Файлы БД закроются через 5 минут, а env и его ram-кэш будет жить до упора.
Кем они закроются, если юзер сидит за САСом и ворочает мышкой - но уже по ДРУГОЙ карте? Глобального таймаута ж не случится.
Или предлагается ввести разные таймауты по каждой отдельной карте? |
|
|
|
|
Я предлагал таймауты по каждой отдельной карте, но я не в курсе таких особенностей беркли как:
> Файлы БД закроются через 5 минут, а env и его ram-кэш будет жить до упора. В зависимости от настроек env, при закрытии БД данные могут как полностью записываться, так и оставаться в логе (а лог ещё и сам может быть по большей части в памяти и запишется только при закрытии env).
ИМХО Env должен быть привязан к карте, а не быть общим на все карты. |
|
|
|
(0011443)
|
|
zed
|
29-05-2013 06:55
(edited on: 29-05-2013 06:56) |
|
>Кем они закроются, если юзер сидит за САСом и ворочает мышкой - но уже по ДРУГОЙ карте?
Внутренним САС-овским механизмом. Каждому файлу БД задаётся TTL (=5мин), по которому они закрываются. В конце концов, можно назначить TTL и для env, с тем же интервалом, но в env, помимо прочего, хранится свой RAM-кэш, который при этом будет сбрасываться на диск, а потом (при открытии) опять подгружаться. Отсюда и лаг.
>ИМХО Env должен быть привязан к карте, а не быть общим на все карты.
Ну так оно так и есть. С единственной оговоркой, что если у юзера несколько карт используют один и тот же кэш, то у этих карт будет общий env.
|
|
|
|
(0011444)
|
|
Parasite
|
29-05-2013 06:57
(edited on: 29-05-2013 07:03) |
|
>Я предлагал таймауты по каждой отдельной карте
Ага. Тогда - да, сработает. Но зато придется вводить кучку таймеров по числу установленных у юзера карт, и тикать их таки все оптом... Впрочем, это уже на усмотрение программеров.
>Файлы БД закроются через 5 минут, а env и его ram-кэш будет жить до упора. В зависимости от настроек env, при закрытии БД данные могут как полностью записываться, так и оставаться в логе (а лог ещё и сам может быть по большей части в памяти и запишется только при закрытии env).
Вот по таймауту и делать полную выгрузку этого всего. А там - пускай САС крешится, абсолютно ничего не будет потеряно даже если он так под таймаутом месяц стоять будет.
Главное, чтобы таймаут не срабатывал когда закачка в карты ночами идет (при отсутствии юзера и его активности по карте). :)
|
|
|
|
|
>Каждому файлу БД задаётся TTL (=5мин), по которому они закрываются.
=наверное будет безбожно тормозить на больших кэшах (лично у меня тысячи и тысячи файлов баз под одним САСом например).
>Отсюда и лаг.
Некоторый лаг, разумеется, будет. Никто не спорит. Ну и пусть его - это маленькая цена, когда весь кэш по всем картам может накрыться медным тазом если свет случайно мигнул.
Можно вообще САСовый экран бланковать черным и писать "Тут был скринсейвер", и перерисовывать когда уже всё подчитано с диска. Но это погремушки конечно - лично я согласен и на лаг. :) |
|
|
|
(0011447)
|
|
zed
|
|
29-05-2013 07:10
|
|
>наверное будет безбожно тормозить на больших кэшах
C чего-бы? Тем более, что я описываю реализованное поведение кэша, которое ты можешь наблюдать на своих "тысячах тысяч" файлов баз. |
|
|
|
|
>C чего-бы? Тем более, что я описываю реализованное поведение кэша
Так я ж не утверждал - я спрашивал. Раз не будет, то и отлично. |
|
|
|
|
Ну ИМХО через минуту после отстрела последней базы тайлохранилища по TTL можно и env отстреливать.
А при закачке оно точно не отстрелит, так как будут постоянные обращения к кэшу
|
|
|
|
|
>при закачке оно точно не отстрелит, так как будут постоянные обращения к кэшу
значит должно быть больше чем таймаут на сетевые операции |
|
|
|
|
>>при закачке оно точно не отстрелит, так как будут постоянные обращения к кэшу
> значит должно быть больше чем таймаут на сетевые операции
Если сетевая операция будет дольше 5 минут, то пару секунд на открытие уже закрытой базы погоды не сделают. |
|
|
|
|
>Если сетевая операция будет дольше 5 минут, то пару секунд на открытие уже закрытой базы погоды не сделают.
Может быть например 50 одновременных закачек по медленному каналу с тормознутого сервиса. Тогда погода будет. |
|
|
|
|
>>Если сетевая операция будет дольше 5 минут, то пару секунд на открытие уже закрытой базы погоды не сделают.
> Может быть например 50 одновременных закачек по медленному каналу с тормознутого сервиса. Тогда погода будет.
Тогда таймаута в 5 минут между записями не будет и соответственно вообще разницы не будет. |
|
|
|
|
>и соответственно вообще разницы не будет
Видимо пока не налетишь сам - не поймёшь, что возможен весь промежуточный спектр значений.
Суть в том, что отрубание будет раз в минуту, и раз в 70сек будут тайлы например прилетать при таймауте в 5 минут - и в итоге перед каждым тайлом будет переоткрытие базы. |
|
|
|
|
|
Не уловил причины, по которой тайлохранилище будет отрубатьтся через минуту если речь шла об отключении через минуту после таймаута последней базы, которые отключаются через 5 минут. И не забываем что перед скачкой каждого тайла проверяется его наличие в базе, тоесть будет обращение, которое не даст отстрелить базу. |
|
|
|
|
>после таймаута последней базы, которые отключаются через 5 минут
Так тут вроде как речь шла об уменьшении 5-минутного интервала? |
|
|
|
(0011482)
|
|
zed
|
|
03-06-2013 08:29
|
|
|
Если я буду делать этот тикет, то только как изначально и было описано - при отключении карты в гуе + таймаут в несколько минут после отключения. А просто так, по таймауту, я не хочу чтобы у меня карта отваливалась каждые 5 минут бездействия. |
|
|
|
|
|
Тогда сразу ставь won't fix, так как тайлохранилище не должно знать кто его использует, не его это дело. |
|
|
|
(0011484)
|
|
zed
|
|
03-06-2013 09:29
|
|
>не его это дело
Зашибись. Походу надо сворачиваться и уходить в SACS с концами. |
|
|
|
(0011486)
|
|
vasketsov
|
03-06-2013 09:48
(edited on: 03-06-2013 09:49) |
|
>так как тайлохранилище не должно знать кто его использует
Мсье видимо имел в виду, что тайлохранилище не должно знать, кто будет дёргать его Sync? Ну тогда имеет смысл добавить Payload в Sync.
>не хочу чтобы у меня карта отваливалась каждые 5 минут бездействия
Соответственно, можно решить опцией, тушить включённые карты и слои по какому-то времени, или нет.
|
|
|
|
(0011488)
|
|
zed
|
|
03-06-2013 10:31
|
|
>Мсье видимо имел в виду
Самое интересное, что о том, как это может быть реализовано ещё небыло сказано ни слова, а уже предлагается закрыть тикет без обсуждений. |
|
|
|
|
>Мсье видимо имел в виду, что тайлохранилище не должно знать, кто будет дёргать его Sync? Ну тогда имеет смысл добавить Payload в Sync.
Что за Sync и что за Payload?
>Зашибись. Походу надо сворачиваться и уходить в SACS с концами.
Это будет печально.
ИМХО тайлохранилище не должно знать кто и как его использует. Поэтому получается два варианта:
1. вводить пару методов StartUsing/FinshUsing и везде где начинаем работу с каким-то тайлохранилищем дергать первый, а по завершении второй. И в тайлохранилище вести подсчет вызовов и допускать таймаут только если никто не пользует.
2. вводить для ГУЯ отдельную пинговалку которая будет дергать тайлохранилища открытых на экране карт не двавая им отвалится по таймауту.
Оба варианта на мой взгляд сопряжены с большой морокой, но первый более подвержен ошибкам. |
|
|
|
(0011490)
|
|
zed
|
|
03-06-2013 10:44
|
|
>Это будет печально.
Ну так нефиг любую творческую мысль рубить на корню.
>Поэтому получается два варианта
О, уже оказывается и аж два приемлемых варианта нашлись. И это сходу. |
|
|
|
|
>>Это будет печально.
> Ну так нефиг любую творческую мысль рубить на корню.
Так нефиг на любую фразу обижаться. Обзови придурком и агрументируй свою позицию - я не обижусь, но толькое если позиция будет аргументированной. :)
>О, уже оказывается и аж два приемлемых варианта нашлись. И это сходу.
И первый из этих двух захламляет код использования тайлохранилища, а второй все равно добавлять потом, после того как сделать простое отстреливаение по таймауту. И все это ради пары секунд после 5 минутного перекура? Зачем? Неужели у тебя есть тайлохранилища которые открываются первый раз больше пары секунд? |
|
|
|
(0011492)
|
|
zed
|
|
03-06-2013 11:12
|
|
>И первый из этих двух
Вообще-то у меня есть свой вариант - сделать ленивое создание и соответствующее удаление хранилища целиком. У нас хранилище сидит в TMapType и все обращения к нему идут через карту. Так вот именно тут, мы можем легко управлять временем жизни хранилища, не создавать его при создании карты, а только по запросу, удалять исходя из активность карты (не кэша) и тому подобное. Причём, польза будет не только для Беркли.
>Неужели у тебя есть тайлохранилища которые открываются первый раз больше пары секунд?
Просто я не хочу лагов даже в секунду. |
|
|
|
|
>У нас хранилище сидит в TMapType и все обращения к нему идут через карту. Так вот именно тут, мы можем легко управлять временем жизни хранилища, не создавать его при создании карты, а только по запросу, удалять исходя из активность карты (не кэша) и тому подобное.
Но карта тоже не знает и знать не должна активна ли она сейчас в пользовательском интерфейсе, поэтому опять приходим к тем двум вариантам, которые я уже озувучил.
>Просто я не хочу лагов даже в секунду.
Тебе жалко пары секунд после пятиминутной паузы? Да экран дольше включается после скринсейвера. Давай поспорим, что никто разницы не заметит? |
|
|
|
|
>Неужели у тебя есть тайлохранилища которые открываются первый раз больше пары секунд?
Ну вообще говоря да, коннект к СУБД может быть и пару секунд и больше, а потом работа быстрая, зависит от особенностей работы и настройки (например, пока нет в кэше DSN или ARP будет дольше на разрешение соответствующего адреса).
>Что за Sync и что за Payload?
Sync - проца в тайлохранилище.
Payload - буквально - полезная нагрузка (параметр). В простейшем случае Boolean. В более сложном - IInterface и прочие извращения.
>второй все равно добавлять потом
Ну собственно да, поэтому я и предложил Sync по активным картам и слоям.
Фабрика SyncPayload может генерить Payload на основании в том числе информации об активных картах. Программной опцией на неё можно влиять, генерить ей всегда False, или же True если карта активна (если тип будет Boolean, сюда же можно и время вырубания даже активной карты пропихнуть). Соответственно в хранилище этот Payload воспринимается как запрет вырубать карту (ну или с точностью до наоборот). Логика чуть более чем тривиальная, кодится тоже несложно. |
|
|
|
|
>Ну собственно да, поэтому я и предложил Sync по активным картам и слоям.
> Фабрика SyncPayload может генерить Payload на основании в том числе информации об активных картах. Программной опцией на неё можно влиять, генерить ей всегда False, или же True если карта активна (если тип будет Boolean, сюда же можно и время вырубания даже активной карты пропихнуть). Соответственно в хранилище этот Payload воспринимается как запрет вырубать карту (ну или с точностью до наоборот). Логика чуть более чем тривиальная, кодится тоже несложно.
Ну в общем, я тоже склоняюсь к варианту с пинговалкой. А он вполне себе ортогонален к реализации данной хотелки. |
|
|
|
(0011625)
|
|
zed
|
10-06-2013 17:47
(edited on: 10-06-2013 17:50) |
|
Сейчас будет логика такая: каждые 5 минут или каждые 1000 коммитов (операции Write и Delete) будет выполняться проверка TTL файлов БД. Если к БД обращались более 1 минуты назад (тот самый TTL), она считается не нужной и закрывается. Если все БД оказались не нужными и закрылись, то тут же закрывается и env. Если хотя бы одна БД ещё живая - ждём ещё 5 мин или 1000 коммитов и проверяем опять. И что ещё важно, при каждой такой синхронизации инициализируется сброс данных из лога транзакций в БД (поэтому синхронизация и завязана дополнительно на коммиты). При активной записи в кэш, через тот же Менеджер кэша, если не мониторить коммиты, то логи распухают моментально до сотен мегобайт.
Посмотрим, как кэш будет вести себя в таком режиме, и если что, озаботимся пинговалгой, чтобы env у активной карты не умирал.
|
|
|
|
|
>Если к БД обращались более 1 минуты назад (тот самый TTL), она считается не нужной и закрывается.
Имхо, 1 минута - весьма мало. Будет постоянно переоткрываться\перезакрываться даже если юзер просто внимательно на экране что-то рассматривает - или, например, ставит новую метку...
Предлагаю 3 или даже 5 минут, и сразу с env (ниже).
>Если все БД оказались не нужными и закрылись, то тут же закрывается и env.
А разве env у нас не отдельный к каждой карте? Зачем ждать закрытия всех карт - для закрытия конкретного env?
|
|
|
|
|
> Предлагаю 3 или даже 5 минут, и сразу с env (ниже).
Мне тоже кажется, что 1 минута маловато, а то что этот период гораздо меньше периода проверки вобще сделает его слегка непредсказуемым. Может наоборот, проверять раз в минуту, а время жизни минут 5 поставить?
>А разве env у нас не отдельный к каждой карте? Зачем ждать закрытия всех карт - для закрытия конкретного env?
При чем тут все карты, речь про закрытие всех баз одной карты. |
|
|
|
|
>При чем тут все карты, речь про закрытие всех баз одной карты.
Фразу "Если все БД оказались не нужными и закрылись, то тут же закрывается и env" я понял в ключе "ВООБЩЕ ВСЕ БД".
Если имелась ввиду только одна карта - то ОК. |
|
|
|
(0011635)
|
|
zed
|
|
11-06-2013 08:34
|
|
Вообще, я хочу вынести все эти интервалы в конфиг, вместе с настройкой ReadOnly доступа (см. 0001874), тогда можно будет экспериментировать и подбирать оптимальные значения при желании.
>Имхо, 1 минута - весьма мало.
А там так и было. Фраза "Сейчас будет логика такая" не обязательно означает, что до этого логика была какая-то принципиально другая. По сути, всё что я добавил - закрытие env, если закрыты все БД (данной карты). А интервалы синхронизации я не трогал.
>Может наоборот, проверять раз в минуту, а время жизни минут 5 поставить?
Не, синхронизация ж кроме всего прочего инициализирует сброс кэша. А минута это довольно часто. Хотя, если часто сбрасывать кэш, то и операция эта будет достаточно быстрой, ввиду малого объёма закэшированных данных.
Ситуация с частым закрытием/открытием БД сглаживается тем, что у нас ещё есть кэш в env. Так что, теоретически (хотя, может я и ошибаюсь), файл БД может быть ещё не закрыт, даже если из САСа мы вдруг отключились от этой БД. Но с уверенностью могу сказать, что даже если файл БД закрывается и из env, в кэше всё равно остаются страницы из того файла, вплоть до закрытия/открытия самого env. Исходя из этого, я и озаботился увеличением кэша env через DB_CONFIG |
|
|
|
|
>>Имхо, 1 минута - весьма мало.
>А там так и было. Фраза "Сейчас будет логика такая" не обязательно означает, что до этого логика была какая-то принципиально другая.
Как показывает практика, "до этого" (то есть - вот прямо сейчас) при крэше САСа файлы БД бились даже у той карты, отключение от которой было (на момент крэша) довольно давно. Скажем - час. Если бы оно [сейчас] закрывалось через минуту - при крэше через час бился бы только env. Я неправ?
>я хочу вынести все эти интервалы в конфиг
Это было бы идеальным. |
|
|
|
(0011638)
|
|
zed
|
|
11-06-2013 08:57
|
|
>Если бы оно [сейчас] закрывалось через минуту - при крэше через час бился бы только env. Я неправ?
В кэше Беркли, env - всему голова. И эта "голова" сидит в RAM и по возможности держит там страницы когда-либо открываемых БД. В том числе держит и изменения этих страниц, и в зависимости от настроек, закрывая БД из САС нет гарантии, что все изменения тут же залетят в БД. Оно может там всё так же висеть в RAM до второго пришествия. Поэтому при крэше env, может всё полететь к чертям.
Вот тут я постарался подробно расписать настройки env, которые могут влиять на то, с какой скоростью всё может полететь к чертям, при крэше чего-либо. |
|
|
|
|
>Оно может там всё так же висеть в RAM до второго пришествия. Поэтому при крэше env, может всё полететь к чертям.
Вот именно поэтому я и предлагаю закрывать беркли вместе с env через 3..5 мин, а не ступенчато (сперва - файлы, а потом - env). Ибо если оно скрэшится на этом промежутке - еррор все равно будет (env не закрыт) независимо от того, закрыты были уже файлы к тому времени или нет.
В общем - ждем реализации, а там тайминги уже оттюним как надо. |
|
|
|
(0011640)
|
|
zed
|
|
11-06-2013 09:25
|
|
>В общем - ждем реализации
Так реализовано уже. Через 5 минут бездействия, гарантированно закрываются все БД и env. |
|
|
|
|
>Так реализовано уже.
В сегодняшней ночнушке? ОК, будем покачать и попробовать. :) |
|
|
|
(0011664)
|
|
zed
|
|
14-06-2013 12:20
|
|
|
В завтрашней ночнушке можно будет пробовать изменять интервалы синхронизации через ini файл: http://sasgis.org/mantis/view.php?id=1874#c11663 |
|
|
|
|
>Через 5 минут бездействия, гарантированно закрываются все БД и env.
Вроде работает так как надо. При "просыпании" карты - наблюдается предсказуемый, но вполне терпимый лаг ~1сек.
Спасибо. |
|