View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003101 | SAS.Планета | Баг / Bug | public | 05-07-2016 17:38 | 02-08-2016 10:03 |
| Reporter | gma | Assigned To | zed | ||
| Priority | normal | Severity | major | Reproducibility | have not tried |
| Status | resolved | Resolution | fixed | ||
| Platform | Windows | OS | 7 | OS Version | Enterprise |
| Product Version | 160707 | ||||
| Target Version | 181221 | Fixed in Version | 181221 | ||
| Summary | 0003101: Отказ в конвертации кэша в SQLite из-за проблем с памятью | ||||
| Description | Оперативки в машине 32Гб. Была запущена конвертация кэша из GMT в SQlite. Кэш "весит" немногим больше 130Гб, на диске есть место. NTFS. В некий момент конвертация остановилась, в логе пошли ошибки, появилась надпись про невозможность работы, точно не помню. Перезапустил процесс заново, появилась приложенная картинка. Лог размером 1,3Гб -- весь не покажу, но вот несколько крайних записей: 2 0 1 6 - 0 7 - 0 5 1 5 : 0 2 : 2 9 . 7 3 1 ( i n i t ) 3 . 1 3 . 0 a t E : \ S A S P l a n e t \ s q l i t e 3 . d l l 2 0 1 6 - 0 7 - 0 5 1 5 : 0 2 : 2 9 . 7 3 1 ( i n i t ) o u t o f m e m o r y ( e r r o r c o d e : 7 ) 2 0 1 6 - 0 7 - 0 5 1 5 : 0 2 : 2 9 . 7 3 1 ( i n i t ) 3 . 1 3 . 0 a t E : \ S A S P l a n e t \ s q l i t e 3 . d l l 2 0 1 6 - 0 7 - 0 5 1 5 : 0 2 : 2 9 . 7 3 1 ( i n i t ) o u t o f m e m o r y ( e r r o r c o d e : 7 ) 2 0 1 6 - 0 7 - 0 5 1 5 : 0 2 : 2 9 . 7 3 1 ( i n i t ) 3 . 1 3 . 0 a t E : \ S A S P l a n e t \ s q l i t e 3 . d l l 2 0 1 6 - 0 7 - 0 5 1 5 : 0 2 : 2 9 . 7 3 1 ( i n i t ) o u t o f m e m o r y ( e r r o r c o d e : 7 ) | ||||
| Tags | SQLite | ||||
| Attached Files | |||||
|
|
> надпись про невозможность работы -- cant.png |
|
|
Попробуйте заархивировать лог, и если он получится не очень большой, прислать его мне. Возможно, там будет что-то интересное. Затем, удалите его и запустите дебажную версию. В SQLite кэше что-то успело создаться? Сколько файлов там и какого размера? Файлы только с раcширением *.sqlitedb или есть и другие (и много ли их, если есть)? |
|
|
> Попробуйте заархивировать лог -- sqlite.zip. Это следующий лог. первый потёрся самой программой, когда я запустил повторную конвертацию. Стабильно доходит до 15 уровня и затыкается. Внутри зипа есть кусочек старого лога (err10-07.txt) в месте перехода от ошибка10 к ошибка07. До этого с двух часов ночи была ошибка10. Переключение между номерами ошибок произошло после нажатия на Ок в окне "can't". Больше ничего интересного там не было. > В SQLite кэше что-то успело создаться? -- да создались папки: z2\ z11\ z12\ z13\ z14\ z15\ внутри созданы файлы трёх видов (files.txt). Все файлы *.sqlitedb-wal пустые (0), Все *.sqlitedb-shm равны 32кб и забиты нулями. |
|
|
Запустил дебажку. она поработала пару часов и точно так же отвалилась. Выключал через диспетчер. Одновременно работал GM и памяти оставалось около 8 Гб. Соотв. отвалилась раньше. |
|
|
Попробовал на свежей "стабильной" (с) версии 160707 запустить этот процесс через "Операции--скопировать". Получилось то же самое (outom.png) Логи этого процесса не создавались. |
|
|
Проблема в том, что не контролируется количество соединений с БД и они, открываясь, никогда не закрываются. Нужно переделывать механизм открытия соединений и делать ограниченный по размерам пул. |
|
|
Могу создать новый инцидент, но мне кажется, они как-то связаны "bd.png" |
|
|
Очевидно, если SQLite кэш выжрал всю доступную память, то ни Беркли ни всё остальное не сможет нормально работать, поэтому, да, эти ошибки связаны. |
|
|
Вся! память не выжирается. Съедается всего 3,5Гб т.к. прога 32-битная, и на этом всё кончается. Но конвертация в беркли была запущена на вновь открытой программе и вроде бы не должна быть напрямую связана с предыдущей ошибкой. Я предполагаю связь внутреннюю -- в алгоритмах конвертации или в отношениях с памятью... |
|
|
> Вся! память не выжирается. Съедается всего 3,5Гб Ого, а вы в курсе, что 32-битной проге, без дополнительных ухищрений доступно только 2 Гб, а с некоторыми костылями 3 Гб на 32-битной винде и 4 ГБ на 64-битной. Более того, даже наличие свободной памяти не гарантирует что нужное количество памяти можно выделить. Память может быть сильно фрагментирована. |
|
|
Сообщение об ошибке даёт ясно понять, что процессу не хватает памяти. Что вы пытались сделать с кэшем Беркли? И как к этому был причастен кэш SQLite? Рекомендую дождаться когда этот баг в SQLite будет исправлен и тестировать уже потом. |
|
|
> Проблема в том, что не контролируется количество соединений с БД и они, открываясь, никогда не закрываются. Нужно переделывать механизм открытия соединений и делать ограниченный по размерам пул. А в беркли закрываются? Кстати, скорость конвертации из обычного кеша в sqlite просто ракета, если сравнивать с berkley. Неужели последний настолько медленный? |
|
|
> А в беркли закрываются? Да, закрываются и ограничены 32-мя штуками (можно изменять через конфиг). > Неужели последний настолько медленный? Его пришлось сильно затормозить, т.к. были проблемы с повреждением БД. Возможно страдает моя реализация, а возможно ещё что. Если есть мысли, как можно сделать кэш быстрее (не повредив его устойчивости), высказывайте свои мысли, буду рад обсудить. |
|
|
Средняя скорость конвертации sas->bdb 20 тайлов в секунду... Что-то явно не так ибо совсем не стыкуется с описанием bdb: "BerkeleyDB can be extremely fast - I recently designed a built a data analysis platform for an employer that was capable of doing 40k inserts per second on an 8 core x86 system (while at the same time doing thousands of reads per second) with a dataset in the 30G range. This was with full transactional protection" - http://stackoverflow.com/questions/2824135/how-fast-is-berkeley-db-sql-compared-to-sqlite http://www.oracle.com/technetwork/products/berkeleydb/berkeley-db-perf-128909.pdf http://highscalability.com/blog/2012/11/29/performance-data-for-leveldb-berkley-db-and-bangdb-for-rando.html А где можно код посмотреть? Я, конечно, навряд ли чем буду полезен, но мало ли . |
|
|
Не стоит засорять этот тикет вопросами про Беркли. На форуме есть специальный топик: Использование в Sas.Планета кеша в формате Berkeley Код у нас лежит в репозитории, а кэш Беркли вот в этой папке: /Src/TileStorage/BerkeleyDB/ |
|
|
Я ошибся, соединения всё таки закрываются. Но вот количество открытых никак не контролируется и до того, как сработает очистка мусора (раз в 3 минуты), можно успеть открыть очень много соединений. Но это цветочки, а вот ягодки: задан очень большой размер кэша в памяти (60 000 страниц) для одного файла БД. Учитывая, что размер одной страницы обычно равен 4 кБ, то SQLite разрешено кэшировать в памяти 4 * 60000 = 240 Мб (!) на один файл. Т.е. чтобы выжрать всю память, достаточно активно писать в 5-6 файлов БД. По-умолчанию, в SQLite кэшируется 2000 страниц (8 Мб на файл), протестируйте с этим значением. Для этого, закройте SAS и в папке с кэшем для карты, в которую идёт запись (например, /cache_sqlite/sat/), создайте текстовый файл s.sql вот с таким содержимым: PRAGMA encoding="UTF-8" PRAGMA cache_size=2000 PRAGMA main.journal_mode=WAL PRAGMA synchronous=NORMAL И попробуйте запустить конвертер кэша, а потом отпишитесь сюда. В ночнушке же, я, пожалуй, уменьшу время сборки мусора до 1 минуты и размер кэша до 2000. |
|
|
На всякий случай: - Значение cache_size, при желании, можно уменьшать вплоть до 10 страниц - для увеличения быстродействия конвертирования кэша, можно отключить синхронизацию (synchronous=OFF) |
|
|
Полсуток -- полёт нормальный. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 05-07-2016 17:38 | gma | New Issue | |
| 05-07-2016 17:38 | gma | File Added: outof.png | |
| 06-07-2016 06:23 | gma | File Added: cant.png | |
| 06-07-2016 06:24 | gma | Note Added: 0017495 | |
| 06-07-2016 06:25 | gma | Tag Attached: SQLite | |
| 06-07-2016 07:41 | zed | Note Added: 0017496 | |
| 06-07-2016 07:59 | vdemidov | Status | new => feedback |
| 06-07-2016 11:01 | gma | File Added: sqlite.zip | |
| 06-07-2016 11:07 | vdemidov | Status | feedback => new |
| 06-07-2016 11:23 | gma | Note Added: 0017503 | |
| 06-07-2016 11:24 | gma | File Added: files.zip | |
| 06-07-2016 17:07 | gma | Note Added: 0017504 | |
| 06-07-2016 17:09 | gma | File Added: SASPlanet.Debug.zip | |
| 06-07-2016 17:09 | gma | File Added: sqlite2.rar | |
| 06-07-2016 17:11 | gma | Note Edited: 0017504 | |
| 08-07-2016 05:41 | gma | Note Added: 0017505 | |
| 08-07-2016 05:42 | gma | File Added: outom.png | |
| 09-07-2016 09:28 | zed | Summary | отказ в конвертации кэша в sqlite из-за проблем с памятью => Отказ в конвертации кэша в SQLite из-за проблем с памятью |
| 09-07-2016 09:28 | zed | Status | new => confirmed |
| 09-07-2016 09:28 | zed | Target Version | => 181221 |
| 09-07-2016 09:30 | zed | Note Added: 0017506 | |
| 12-07-2016 18:06 | gma | Note Added: 0017509 | |
| 12-07-2016 18:07 | gma | File Added: bd.png | |
| 13-07-2016 03:23 | zed | Note Added: 0017510 | |
| 13-07-2016 06:10 | gma | Note Added: 0017514 | |
| 13-07-2016 06:22 | vdemidov | Note Added: 0017515 | |
| 13-07-2016 06:22 | zed | Note Added: 0017516 | |
| 21-07-2016 16:19 | aflexus | Note Added: 0017537 | |
| 21-07-2016 16:53 | aflexus | Note Edited: 0017537 | |
| 21-07-2016 17:33 | vdemidov | Relationship added | has duplicate 0003113 |
| 22-07-2016 13:15 | zed | Note Added: 0017553 | |
| 27-07-2016 21:46 | aflexus | Note Added: 0017562 | |
| 27-07-2016 21:48 | aflexus | Note Edited: 0017562 | |
| 28-07-2016 05:25 | zed | Note Added: 0017563 | |
| 01-08-2016 13:16 | zed | Note Added: 0017577 | |
| 01-08-2016 13:21 | zed | Assigned To | => zed |
| 01-08-2016 13:21 | zed | Status | confirmed => feedback |
| 01-08-2016 13:37 | zed | Note Added: 0017578 | |
| 02-08-2016 06:06 | gma | Note Added: 0017581 | |
| 02-08-2016 06:06 | gma | Status | feedback => assigned |
| 02-08-2016 09:09 | zed | Status | assigned => resolved |
| 02-08-2016 09:09 | zed | Fixed in Version | => 181221 |
| 02-08-2016 09:09 | zed | Resolution | open => fixed |
| 02-08-2016 10:03 | vdemidov | Product Version | .Nightly => 160707 |
| 08-08-2025 13:22 | zed | Category | Баг => Баг / Bug |