SASGIS - SAS.Планета
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0002495SAS.Планета[All Projects] Багpublic09-09-2014 07:3310-09-2014 07:18
Reporteryava88 
Assigned To 
PrioritynormalSeverityminorReproducibilityhave not tried
StatusclosedResolutionno change required 
PlatformWindowsOSXPOS VersionSP3
Product Version140505 
Target VersionFixed in Version 
Summary0002495: При прерывании удаления тайлов не освобождается место (СУБД)
DescriptionПри удалении тайлов из кэша при прерывании операции удаления тайлы находятся в БД.

Используется тип кэша - СУБД (http://sasgis.org/mantis/view.php?id=1113)
Steps To Reproduce1. Запускаем ПЕРЕД экспериментом Garbage collector:
postgresql35w=# VACUUM;
VACUUM

2. Измерим размер БД до:

postgresql35w=# select pg_database_size('postgresql35w');
 pg_database_size
------------------
      12811215364
(1 row)

3. Запустим удаление тайлов в большой выделеной области. После удаления около 5000 тайлов прервем - нажмем на крестик в окне удаления.

4. Запускаем Garbage collector, измеряем размер БД после:

postgresql35w=# VACUUM;
VACUUM
postgresql35w=# select pg_database_size('postgresql35w');
 pg_database_size
------------------
      12811289092
(1 row)


12811215364 < 12811289092

Размер БД не уменьшился, а даже вырос.

С БД работал один, других загрузок не было.


Additional InformationAUTOVACUUM настроил (http://sasgis.org/mantis/view.php?id=2494). Спасибо, zed.

С сожалению найти конкретный тайл через PgAdmin не могу, тк не понимаю принцип организации таблиц. Если есть инфа про схему, покажите, я проанализирую и отпишу есть ли физически удаленный тайл в БД. Только инцидент просьба не закрывать (чтоб не плодить если подтвердится).
TagsNo tags attached.
Relationships
Attached Files
Issue History
Date ModifiedUsernameFieldChange
09-09-2014 07:33yava88New Issue
09-09-2014 07:35yava88Note Added: 0014627
09-09-2014 08:26vdemidovSteps to Reproduce Updatedbug_revision_view_page.php?rev_id=6256#r6256
09-09-2014 08:27vdemidovNote Deleted: 0014627
09-09-2014 08:27vdemidovAssigned To => vasketsov
09-09-2014 08:27vdemidovStatusnew => assigned
09-09-2014 08:54zedNote Added: 0014630
09-09-2014 10:53yava88Note Added: 0014635
09-09-2014 11:05yava88Note Edited: 0014635bug_revision_view_page.php?bugnote_id=14635#r6261
09-09-2014 11:07vdemidovNote Added: 0014636
09-09-2014 11:21zedNote Added: 0014637
09-09-2014 11:26zedNote Added: 0014638
09-09-2014 11:34yava88Note Edited: 0014635bug_revision_view_page.php?bugnote_id=14635#r6262
09-09-2014 11:36vdemidovNote Added: 0014639
09-09-2014 11:38yava88Note Added: 0014640
09-09-2014 11:38zedNote Added: 0014641
10-09-2014 07:18zedStatusassigned => closed
10-09-2014 07:18zedAssigned Tovasketsov =>
10-09-2014 07:18zedResolutionopen => no change required

Notes
(0014630)
zed   
09-09-2014 08:54   
Не понимаю, чего вы хотите от нас и в чём по вашему баг SAS? Тайлы из БД удаляются? Если да, то всем остальным делом занимается базавод и SAS на него никак повлиять не может. Проверить, удаляются ли тайлы можно визуально, включив режим Только из кэша.

Плюс ко всему, вы наверное не до конца читали хелп (или вернее, не сначала), на который я вам в прошлый раз давал ссылку.

The standard form of VACUUM removes dead row versions in tables and indexes and marks the space available for future reuse. However, it will not return the space to the operating system, except in the special case where one or more pages at the end of a table become entirely free and an exclusive table lock can be easily obtained. In contrast, VACUUM FULL actively compacts tables by writing a complete new version of the table file with no dead space. This minimizes the size of the table, but can take a long time. It also requires extra disk space for the new copy of the table, until the operation completes.

The usual goal of routine vacuuming is to do standard VACUUMs often enough to avoid needing VACUUM FULL. The autovacuum daemon attempts to work this way, and in fact will never issue VACUUM FULL.

И вообще, идею с освобождением места на диске, после удаления тайлов, считаю бессмысленной. БД всё равно займёт его через день, так зачем насиловать диск, выполняя полную копию таблицы? Ну не выгодно это с точки зрения производительности, поэтому все БД так поступают - однажды увеличившись в размерах уже не уменьшаются, и повторно используют пространство от удалённых записей.
(0014635)
yava88   
09-09-2014 10:53   
(edited on: 09-09-2014 11:34)
Разобрался. Всё работает правильно. Прошу прощения за беспокойство.

Кому интересно. Проделал следущее:

postgresql35w=# VACUUM;
VACUUM
postgresql35w=# select pg_database_size('postgresql35w');
 pg_database_size
------------------
      12640772612
(1 row)
---------------Запустил удаление ----------------------------------
postgresql35w=# select pg_database_size('postgresql35w');
 pg_database_size
------------------
      12640883832
(1 row)
---------------5000 тайлов удалено ----------------------------------
postgresql35w=# select pg_database_size('postgresql35w');
 pg_database_size
------------------
      12640883832
(1 row)

postgresql35w=# VACUUM;
VACUUM
postgresql35w=# select pg_database_size('postgresql35w');
 pg_database_size
------------------
      12640772612
(1 row)

postgresql35w=# VACUUM FULL;
VACUUM
postgresql35w=# select pg_database_size('postgresql35w');
 pg_database_size
------------------
      12581852280
(1 row)

То есть только после VACUUM FULL; место высвобождается. Но не в месте дело, а в том, что удаление происходит правильно.
(0014636)
vdemidov   
09-09-2014 11:07   
Все вопросы к автору - vasketsov. Кроме него, я больше не знаю ни одного человека, который бы этим тайлохранилищем пользовался. Я даже не представляю как его настраивать, поэтому и просил написать в вики статью, раз уж у вас получилось его настроить.
(0014637)
zed   
09-09-2014 11:21   
А так может просто не выполняется commit, если процесс насильственно прерван. Такое вполне может быть.

По поводу структуры я вам точно не подскажу, но судя по мыслям, что высказывались в тикете, где обсуждалось сознание этого хранилища, в БД применяется разбиение таблиц по принципу как в Беркли сделано разбиение по файлам sdb. Только в беркли бъётся квадратами по 256*256 тайлов, а в СУБД можно настраивать размер ячейки. Ну или можно хранить всё в одной таблице.

Сами тайлы хранятся вот в таких таблицах:

create table "%Z%%HX%%DIV%%HY%_%SVC%" (
   x numeric not null,
   y numeric not null,
   id_ver smallint not null,
   tile_size int default 0 not null,
   id_contenttype smallint not null,
   load_date TIMESTAMP default CURRENT_TIMESTAMP not null,
   tile_body bytea null,
   constraint PK_%Z%%HX%%DIV%%HY%_%SVC% primary key (x, y, id_ver)
)
;

(вместо переменных внутри %% подставляются конкретные значения).

С X и Y в качестве полей там больше и таблиц-то нету, как вы могли их не заметить?
(0014638)
zed   
09-09-2014 11:26   
> Я даже не представляю как его настраивать

Элементарно: 0001113:0010146
(0014639)
vdemidov   
09-09-2014 11:36   
>Элементарно
Ну так добавь это описание в вики.
(0014640)
yava88   
09-09-2014 11:38   
Разобрался. Всё работает правильно. Прошу прощения за беспокойство.

vdemidov, да напишу. Работать оно еще 3 дня назад начало, а вот понимание только сейчас приходит.
(0014641)
zed   
09-09-2014 11:38   
Ну так сам добавь.