SASGIS - SAS.Планета
View Issue Details
0001938SAS.Планета[All Projects] Хотелкаpublic28-05-2013 12:2920-06-2013 06:59
Parasite 
zed 
normalmajoralways
resolvedfixed 
WindowsServer2003
121010 
131111131111 
0001938: Беркли: При переключении на другую карту - снимать локи и делать Detach предыдущей
Возможно, это фича - но очень мешает жить.

При наличии нескольких карт в Беркли и активном переключении между ними - САС "забывает" демонтировать предыдущий используемый кэш при открытии нового. В итоге все единожды используемые (даже на чтение) карты висят открытыми\залоченными под использование САСом, и висят они ровно до рестарта САСа.

Это мало того что пожирает память и хэндлеры, так еще и мешает производить какие-либо операции с неиспользуемым в настоящее время кэшем (например, полностью его убить), так еще и, внимание - при малейшем сбое САСа\Беркли\системы - портятся все уже открытые карты, даже если мы с ними уже давно не работаем. Портятся потому, что базовод их все не закрывает их так как положено. Это причина, по которой я поставил "Серъезность: высокая" данному тикету.
1. Поиметь 2 любых кэша в Беркли.
2. Поработать с одним, даже на просмотр. Всё ОК, всё работает.
3. Не выходя из САСа, переключиться на вторую карту. Всё ОК, все работает.
4. Посмотреть открытые хэндлеры на папку с 1й картой (например, через Unlocker).
5. Поразиться тому, что там около десятка открытых файлов - причем открытых как R\W.

6. Опционально: скрэшить САСа и проверить оба кэша на ошибки. Убедиться, что они там есть как пинимум по ENV+LSN. :(
Хотелка 1874 растет как раз из-за порчи кэша Беркли при малейшем сбое, даже если записи в него не планируется. Если разрабы посчитают, что эти оба два тикета как-то связаны - пускай прилинкуют.
No tags attached.
Issue History
28-05-2013 12:29ParasiteNew Issue
28-05-2013 13:28vdemidovNote Added: 0011428
28-05-2013 14:44zedNote Added: 0011429
28-05-2013 16:52vdemidovNote Added: 0011430
29-05-2013 02:44ParasiteNote Added: 0011432
29-05-2013 04:43zedNote Added: 0011433
29-05-2013 05:21vdemidovNote Added: 0011434
29-05-2013 05:29zedNote Added: 0011435
29-05-2013 05:57vdemidovNote Added: 0011436
29-05-2013 06:00vdemidovNote Edited: 0011436bug_revision_view_page.php?bugnote_id=11436#r5391
29-05-2013 06:02ParasiteNote Added: 0011437
29-05-2013 06:08ParasiteNote Added: 0011438
29-05-2013 06:08ParasiteNote Edited: 0011438bug_revision_view_page.php?bugnote_id=11438#r5393
29-05-2013 06:30zedNote Added: 0011439
29-05-2013 06:35ParasiteNote Added: 0011440
29-05-2013 06:40vdemidovNote Added: 0011442
29-05-2013 06:55zedNote Added: 0011443
29-05-2013 06:56zedNote Edited: 0011443bug_revision_view_page.php?bugnote_id=11443#r5395
29-05-2013 06:57ParasiteNote Added: 0011444
29-05-2013 07:03ParasiteNote Added: 0011445
29-05-2013 07:03ParasiteNote Edited: 0011444bug_revision_view_page.php?bugnote_id=11444#r5397
29-05-2013 07:10zedNote Added: 0011447
29-05-2013 07:13ParasiteNote Added: 0011448
29-05-2013 07:58vdemidovNote Added: 0011449
29-05-2013 07:58vdemidovNote Edited: 0011449bug_revision_view_page.php?bugnote_id=11449#r5399
29-05-2013 10:01vasketsovNote Added: 0011450
29-05-2013 10:20vdemidovNote Added: 0011451
29-05-2013 19:53vdemidovAssigned To => zed
29-05-2013 19:53vdemidovStatusnew => assigned
29-05-2013 19:54vdemidovProduct Version.Nightly => 121010
29-05-2013 19:54vdemidovTarget Version => 22xxxx
29-05-2013 22:03vasketsovNote Added: 0011461
30-05-2013 05:17vdemidovNote Added: 0011462
30-05-2013 21:01vasketsovNote Added: 0011469
31-05-2013 05:25vdemidovNote Added: 0011470
31-05-2013 07:37vasketsovNote Added: 0011471
31-05-2013 18:17zedCategoryБаг => Хотелка
03-06-2013 08:29zedNote Added: 0011482
03-06-2013 09:24vdemidovNote Added: 0011483
03-06-2013 09:29zedNote Added: 0011484
03-06-2013 09:48vasketsovNote Added: 0011486
03-06-2013 09:49vasketsovNote Edited: 0011486bug_revision_view_page.php?bugnote_id=11486#r5410
03-06-2013 10:31zedNote Added: 0011488
03-06-2013 10:36vdemidovNote Added: 0011489
03-06-2013 10:44zedNote Added: 0011490
03-06-2013 11:03vdemidovNote Added: 0011491
03-06-2013 11:12zedNote Added: 0011492
03-06-2013 11:38vdemidovNote Added: 0011493
03-06-2013 11:56vasketsovNote Added: 0011494
03-06-2013 14:48vdemidovNote Added: 0011495
10-06-2013 17:47zedNote Added: 0011625
10-06-2013 17:47zedStatusassigned => feedback
10-06-2013 17:50zedNote Edited: 0011625bug_revision_view_page.php?bugnote_id=11625#r5447
11-06-2013 02:40ParasiteNote Added: 0011629
11-06-2013 02:40ParasiteStatusfeedback => assigned
11-06-2013 02:40ParasiteNote Edited: 0011629bug_revision_view_page.php?bugnote_id=11629#r5449
11-06-2013 07:12vdemidovNote Added: 0011632
11-06-2013 07:23ParasiteNote Added: 0011633
11-06-2013 08:34zedNote Added: 0011635
11-06-2013 08:41ParasiteNote Added: 0011636
11-06-2013 08:57zedNote Added: 0011638
11-06-2013 09:20ParasiteNote Added: 0011639
11-06-2013 09:25zedNote Added: 0011640
11-06-2013 09:30ParasiteNote Added: 0011641
14-06-2013 12:20zedNote Added: 0011664
15-06-2013 15:56zedStatusassigned => resolved
15-06-2013 15:56zedFixed in Version => 131111
15-06-2013 15:56zedResolutionopen => fixed
17-06-2013 04:56ParasiteNote Added: 0011675
20-06-2013 06:59vdemidovTarget Version22xxxx => 131111

Notes
(0011428)
vdemidov   
28-05-2013 13:28   
Ну, сразу отмонтировать и сбрасывать все кэши перебор, а вот отрубанине секунд через 30 после последнего использования вполне можно было бы реализовать, если оно еще не реализовано.
(0011429)
zed   
28-05-2013 14:44   
Давно были такие мысли, но не сообразил, как сообщить хранилищу, что его уже не используют, а переключились на другую карту.
(0011430)
vdemidov   
28-05-2013 16:52   
А никак ему сообщать не нужно. Только по таймауту с последнего обращения.
(0011432)
Parasite   
29-05-2013 02:44   
>сразу отмонтировать и сбрасывать все кэши перебор, а вот отрубанине секунд через 30 после последнего использования вполне можно было бы реализовать
Не все, а только тот с которого и переключаемся. То есть - всегда один за раз.
То есть, по событию "Карта\слой переключены\отключены" - проверять\форсировать полное закрытие предыдущего хранилища перед открытием нового, да и всё.
Ну, по крайней мере я это так вижу. :)

>Только по таймауту с последнего обращения.
Тогда будем получать Detach кэша даже если карту не меняли - а просто отошли покурить.
(0011433)
zed   
29-05-2013 04:43   
>>Только по таймауту с последнего обращения.
>Тогда будем получать Detach кэша даже если карту не меняли - а просто отошли покурить.
Вот-вот. Нужно более продуманное поведение, а не тупо по таймауту.
(0011434)
vdemidov   
29-05-2013 05:21   
Более продуманное будет на порядок сложнее и менее надежным. Просто обращаться к карте быть не только тогда когда она отображается в основном окне, но и тогда когда она открыта в миникарте, или когда идет закачка по региону, или когда идет склейка, или экспорт и еще куча случаев, которые можно забыть или которые появятся позже.
А закрытие файлов по вменяемому таймауту вполне себе хорошая штука. Ну будет пауза в пол секунды после возвращения с перекура и что? Это будет не баг, а фитча, зато если в это время комп помрет, то кэш не попортится даже если карта была включена.
(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% проблем и делаетася практически элементарно. Но я не настаиваю. Можно оставить как есть. Меня это не напрягает.

(0011437)
Parasite   
29-05-2013 06:02   
>Ну, минут через 30-60 да, можно закрывать. Но никак не через 30 сек.
Цимес момента в данном конкретном тикете в том, чтобы отключать неиспользуемую карту по возможности МОМЕНТАЛЬНО. Толку от введения отключения через час - если еще час оно будет висеть в памяти, со всеми своими последствиями при случайном крэше за тот самый час? И уже не используемый кэш с диска я еще целый час не смогу убить иначе, кроме как выйдя с саса?

То есть, будет то же самое что в шапке тикета и так. Если нельзя ввести цивилизованными методами с передачей в хранилище - тогда имхо лучше короткий таймаут имени вдемидова, чем часовой имени зеда. 30 сек это конечно сильно круто, посему предлагаю 3 минуты (как на сетевые операции) или 5.

Либо, сугубо на правах маразма - вообще открывать любой беркли по умолчанию как R\O и держать его так ровно до тех пор, пока не приспичит вносить изменения (и там - таймаут на R\W режим). Имею мнение, что 99% времени юзания любого кэша как раз на чтение - ну так и открывать его именно в нем, и пускай себе сас крешится сколько угодно.
(0011438)
Parasite   
29-05-2013 06:08   
>а пара минут полного бездействия вполне себе повод закрыть все открытые файлы.
Вопрос: как будет отрабатываться ситуация "активно работаем (таймаута по САСу нет и не планируется), а карту уже переключили и работаем с другой"?
С первой локи кто снимет-то при этом, НЕ ТРОГАЯ вторую?

(0011439)
zed   
29-05-2013 06:30   
>Сколько открытие базы занимает?
Зависит от скорости носителя. Но лаг таки присутствует в любом случае.

>С первой локи кто снимет-то при этом, НЕ ТРОГАЯ вторую?
Файлы БД закроются через 5 минут, а env и его ram-кэш будет жить до упора. В зависимости от настроек env, при закрытии БД данные могут как полностью записываться, так и оставаться в логе (а лог ещё и сам может быть по большей части в памяти и запишется только при закрытии env).
(0011440)
Parasite   
29-05-2013 06:35   
>Файлы БД закроются через 5 минут, а env и его ram-кэш будет жить до упора.
Кем они закроются, если юзер сидит за САСом и ворочает мышкой - но уже по ДРУГОЙ карте? Глобального таймаута ж не случится.

Или предлагается ввести разные таймауты по каждой отдельной карте?
(0011442)
vdemidov   
29-05-2013 06:40   
Я предлагал таймауты по каждой отдельной карте, но я не в курсе таких особенностей беркли как:
> Файлы БД закроются через 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).
Вот по таймауту и делать полную выгрузку этого всего. А там - пускай САС крешится, абсолютно ничего не будет потеряно даже если он так под таймаутом месяц стоять будет.
Главное, чтобы таймаут не срабатывал когда закачка в карты ночами идет (при отсутствии юзера и его активности по карте). :)

(0011445)
Parasite   
29-05-2013 07:03   
>Каждому файлу БД задаётся TTL (=5мин), по которому они закрываются.
=наверное будет безбожно тормозить на больших кэшах (лично у меня тысячи и тысячи файлов баз под одним САСом например).

>Отсюда и лаг.
Некоторый лаг, разумеется, будет. Никто не спорит. Ну и пусть его - это маленькая цена, когда весь кэш по всем картам может накрыться медным тазом если свет случайно мигнул.
Можно вообще САСовый экран бланковать черным и писать "Тут был скринсейвер", и перерисовывать когда уже всё подчитано с диска. Но это погремушки конечно - лично я согласен и на лаг. :)
(0011447)
zed   
29-05-2013 07:10   
>наверное будет безбожно тормозить на больших кэшах
C чего-бы? Тем более, что я описываю реализованное поведение кэша, которое ты можешь наблюдать на своих "тысячах тысяч" файлов баз.
(0011448)
Parasite   
29-05-2013 07:13   
>C чего-бы? Тем более, что я описываю реализованное поведение кэша
Так я ж не утверждал - я спрашивал. Раз не будет, то и отлично.
(0011449)
vdemidov   
29-05-2013 07:58   
Ну ИМХО через минуту после отстрела последней базы тайлохранилища по TTL можно и env отстреливать.
А при закачке оно точно не отстрелит, так как будут постоянные обращения к кэшу

(0011450)
vasketsov   
29-05-2013 10:01   
>при закачке оно точно не отстрелит, так как будут постоянные обращения к кэшу
значит должно быть больше чем таймаут на сетевые операции
(0011451)
vdemidov   
29-05-2013 10:20   
>>при закачке оно точно не отстрелит, так как будут постоянные обращения к кэшу
> значит должно быть больше чем таймаут на сетевые операции
Если сетевая операция будет дольше 5 минут, то пару секунд на открытие уже закрытой базы погоды не сделают.
(0011461)
vasketsov   
29-05-2013 22:03   
>Если сетевая операция будет дольше 5 минут, то пару секунд на открытие уже закрытой базы погоды не сделают.
Может быть например 50 одновременных закачек по медленному каналу с тормознутого сервиса. Тогда погода будет.
(0011462)
vdemidov   
30-05-2013 05:17   
>>Если сетевая операция будет дольше 5 минут, то пару секунд на открытие уже закрытой базы погоды не сделают.
> Может быть например 50 одновременных закачек по медленному каналу с тормознутого сервиса. Тогда погода будет.
Тогда таймаута в 5 минут между записями не будет и соответственно вообще разницы не будет.
(0011469)
vasketsov   
30-05-2013 21:01   
>и соответственно вообще разницы не будет
Видимо пока не налетишь сам - не поймёшь, что возможен весь промежуточный спектр значений.
Суть в том, что отрубание будет раз в минуту, и раз в 70сек будут тайлы например прилетать при таймауте в 5 минут - и в итоге перед каждым тайлом будет переоткрытие базы.
(0011470)
vdemidov   
31-05-2013 05:25   
Не уловил причины, по которой тайлохранилище будет отрубатьтся через минуту если речь шла об отключении через минуту после таймаута последней базы, которые отключаются через 5 минут. И не забываем что перед скачкой каждого тайла проверяется его наличие в базе, тоесть будет обращение, которое не даст отстрелить базу.
(0011471)
vasketsov   
31-05-2013 07:37   
>после таймаута последней базы, которые отключаются через 5 минут
Так тут вроде как речь шла об уменьшении 5-минутного интервала?
(0011482)
zed   
03-06-2013 08:29   
Если я буду делать этот тикет, то только как изначально и было описано - при отключении карты в гуе + таймаут в несколько минут после отключения. А просто так, по таймауту, я не хочу чтобы у меня карта отваливалась каждые 5 минут бездействия.
(0011483)
vdemidov   
03-06-2013 09:24   
Тогда сразу ставь 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   
>Мсье видимо имел в виду
Самое интересное, что о том, как это может быть реализовано ещё небыло сказано ни слова, а уже предлагается закрыть тикет без обсуждений.
(0011489)
vdemidov   
03-06-2013 10:36   
>Мсье видимо имел в виду, что тайлохранилище не должно знать, кто будет дёргать его Sync? Ну тогда имеет смысл добавить Payload в Sync.
Что за Sync и что за Payload?

>Зашибись. Походу надо сворачиваться и уходить в SACS с концами.
Это будет печально.

ИМХО тайлохранилище не должно знать кто и как его использует. Поэтому получается два варианта:
1. вводить пару методов StartUsing/FinshUsing и везде где начинаем работу с каким-то тайлохранилищем дергать первый, а по завершении второй. И в тайлохранилище вести подсчет вызовов и допускать таймаут только если никто не пользует.
2. вводить для ГУЯ отдельную пинговалку которая будет дергать тайлохранилища открытых на экране карт не двавая им отвалится по таймауту.
Оба варианта на мой взгляд сопряжены с большой морокой, но первый более подвержен ошибкам.
(0011490)
zed   
03-06-2013 10:44   
>Это будет печально.
Ну так нефиг любую творческую мысль рубить на корню.

>Поэтому получается два варианта
О, уже оказывается и аж два приемлемых варианта нашлись. И это сходу.
(0011491)
vdemidov   
03-06-2013 11:03   
>>Это будет печально.
> Ну так нефиг любую творческую мысль рубить на корню.
Так нефиг на любую фразу обижаться. Обзови придурком и агрументируй свою позицию - я не обижусь, но толькое если позиция будет аргументированной. :)

>О, уже оказывается и аж два приемлемых варианта нашлись. И это сходу.
И первый из этих двух захламляет код использования тайлохранилища, а второй все равно добавлять потом, после того как сделать простое отстреливаение по таймауту. И все это ради пары секунд после 5 минутного перекура? Зачем? Неужели у тебя есть тайлохранилища которые открываются первый раз больше пары секунд?
(0011492)
zed   
03-06-2013 11:12   
>И первый из этих двух
Вообще-то у меня есть свой вариант - сделать ленивое создание и соответствующее удаление хранилища целиком. У нас хранилище сидит в TMapType и все обращения к нему идут через карту. Так вот именно тут, мы можем легко управлять временем жизни хранилища, не создавать его при создании карты, а только по запросу, удалять исходя из активность карты (не кэша) и тому подобное. Причём, польза будет не только для Беркли.

>Неужели у тебя есть тайлохранилища которые открываются первый раз больше пары секунд?
Просто я не хочу лагов даже в секунду.
(0011493)
vdemidov   
03-06-2013 11:38   
>У нас хранилище сидит в TMapType и все обращения к нему идут через карту. Так вот именно тут, мы можем легко управлять временем жизни хранилища, не создавать его при создании карты, а только по запросу, удалять исходя из активность карты (не кэша) и тому подобное.
Но карта тоже не знает и знать не должна активна ли она сейчас в пользовательском интерфейсе, поэтому опять приходим к тем двум вариантам, которые я уже озувучил.


>Просто я не хочу лагов даже в секунду.
Тебе жалко пары секунд после пятиминутной паузы? Да экран дольше включается после скринсейвера. Давай поспорим, что никто разницы не заметит?
(0011494)
vasketsov   
03-06-2013 11:56   
>Неужели у тебя есть тайлохранилища которые открываются первый раз больше пары секунд?
Ну вообще говоря да, коннект к СУБД может быть и пару секунд и больше, а потом работа быстрая, зависит от особенностей работы и настройки (например, пока нет в кэше DSN или ARP будет дольше на разрешение соответствующего адреса).

>Что за Sync и что за Payload?
Sync - проца в тайлохранилище.
Payload - буквально - полезная нагрузка (параметр). В простейшем случае Boolean. В более сложном - IInterface и прочие извращения.

>второй все равно добавлять потом
Ну собственно да, поэтому я и предложил Sync по активным картам и слоям.
Фабрика SyncPayload может генерить Payload на основании в том числе информации об активных картах. Программной опцией на неё можно влиять, генерить ей всегда False, или же True если карта активна (если тип будет Boolean, сюда же можно и время вырубания даже активной карты пропихнуть). Соответственно в хранилище этот Payload воспринимается как запрет вырубать карту (ну или с точностью до наоборот). Логика чуть более чем тривиальная, кодится тоже несложно.
(0011495)
vdemidov   
03-06-2013 14:48   
>Ну собственно да, поэтому я и предложил 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 у активной карты не умирал.

(0011629)
Parasite   
11-06-2013 02:40   
>Если к БД обращались более 1 минуты назад (тот самый TTL), она считается не нужной и закрывается.
Имхо, 1 минута - весьма мало. Будет постоянно переоткрываться\перезакрываться даже если юзер просто внимательно на экране что-то рассматривает - или, например, ставит новую метку...
Предлагаю 3 или даже 5 минут, и сразу с env (ниже).

>Если все БД оказались не нужными и закрылись, то тут же закрывается и env.
А разве env у нас не отдельный к каждой карте? Зачем ждать закрытия всех карт - для закрытия конкретного env?

(0011632)
vdemidov   
11-06-2013 07:12   
> Предлагаю 3 или даже 5 минут, и сразу с env (ниже).
Мне тоже кажется, что 1 минута маловато, а то что этот период гораздо меньше периода проверки вобще сделает его слегка непредсказуемым. Может наоборот, проверять раз в минуту, а время жизни минут 5 поставить?

>А разве env у нас не отдельный к каждой карте? Зачем ждать закрытия всех карт - для закрытия конкретного env?
При чем тут все карты, речь про закрытие всех баз одной карты.
(0011633)
Parasite   
11-06-2013 07:23   
>При чем тут все карты, речь про закрытие всех баз одной карты.
Фразу "Если все БД оказались не нужными и закрылись, то тут же закрывается и env" я понял в ключе "ВООБЩЕ ВСЕ БД".
Если имелась ввиду только одна карта - то ОК.
(0011635)
zed   
11-06-2013 08:34   
Вообще, я хочу вынести все эти интервалы в конфиг, вместе с настройкой ReadOnly доступа (см. 0001874), тогда можно будет экспериментировать и подбирать оптимальные значения при желании.

>Имхо, 1 минута - весьма мало.
А там так и было. Фраза "Сейчас будет логика такая" не обязательно означает, что до этого логика была какая-то принципиально другая. По сути, всё что я добавил - закрытие env, если закрыты все БД (данной карты). А интервалы синхронизации я не трогал.

>Может наоборот, проверять раз в минуту, а время жизни минут 5 поставить?
Не, синхронизация ж кроме всего прочего инициализирует сброс кэша. А минута это довольно часто. Хотя, если часто сбрасывать кэш, то и операция эта будет достаточно быстрой, ввиду малого объёма закэшированных данных.

Ситуация с частым закрытием/открытием БД сглаживается тем, что у нас ещё есть кэш в env. Так что, теоретически (хотя, может я и ошибаюсь), файл БД может быть ещё не закрыт, даже если из САСа мы вдруг отключились от этой БД. Но с уверенностью могу сказать, что даже если файл БД закрывается и из env, в кэше всё равно остаются страницы из того файла, вплоть до закрытия/открытия самого env. Исходя из этого, я и озаботился увеличением кэша env через DB_CONFIG
(0011636)
Parasite   
11-06-2013 08:41   
>>Имхо, 1 минута - весьма мало.
>А там так и было. Фраза "Сейчас будет логика такая" не обязательно означает, что до этого логика была какая-то принципиально другая.
Как показывает практика, "до этого" (то есть - вот прямо сейчас) при крэше САСа файлы БД бились даже у той карты, отключение от которой было (на момент крэша) довольно давно. Скажем - час. Если бы оно [сейчас] закрывалось через минуту - при крэше через час бился бы только env. Я неправ?

>я хочу вынести все эти интервалы в конфиг
Это было бы идеальным.
(0011638)
zed   
11-06-2013 08:57   
>Если бы оно [сейчас] закрывалось через минуту - при крэше через час бился бы только env. Я неправ?
В кэше Беркли, env - всему голова. И эта "голова" сидит в RAM и по возможности держит там страницы когда-либо открываемых БД. В том числе держит и изменения этих страниц, и в зависимости от настроек, закрывая БД из САС нет гарантии, что все изменения тут же залетят в БД. Оно может там всё так же висеть в RAM до второго пришествия. Поэтому при крэше env, может всё полететь к чертям.

Вот тут я постарался подробно расписать настройки env, которые могут влиять на то, с какой скоростью всё может полететь к чертям, при крэше чего-либо.
(0011639)
Parasite   
11-06-2013 09:20   
>Оно может там всё так же висеть в RAM до второго пришествия. Поэтому при крэше env, может всё полететь к чертям.
Вот именно поэтому я и предлагаю закрывать беркли вместе с env через 3..5 мин, а не ступенчато (сперва - файлы, а потом - env). Ибо если оно скрэшится на этом промежутке - еррор все равно будет (env не закрыт) независимо от того, закрыты были уже файлы к тому времени или нет.

В общем - ждем реализации, а там тайминги уже оттюним как надо.
(0011640)
zed   
11-06-2013 09:25   
>В общем - ждем реализации
Так реализовано уже. Через 5 минут бездействия, гарантированно закрываются все БД и env.
(0011641)
Parasite   
11-06-2013 09:30   
>Так реализовано уже.
В сегодняшней ночнушке? ОК, будем покачать и попробовать. :)
(0011664)
zed   
14-06-2013 12:20   
В завтрашней ночнушке можно будет пробовать изменять интервалы синхронизации через ini файл: http://sasgis.org/mantis/view.php?id=1874#c11663
(0011675)
Parasite   
17-06-2013 04:56   
>Через 5 минут бездействия, гарантированно закрываются все БД и env.
Вроде работает так как надо. При "просыпании" карты - наблюдается предсказуемый, но вполне терпимый лаг ~1сек.
Спасибо.