» SatMap (2)

nemo3001

Цитата:

Поэтому число вставок порядка 20-ти и показалось мне и полезным, и относительно безопасным.

Дело говоришь, потому так и сделаю...

nemo3001

Цитата:

тем больше будут возрастать пиковые посекундные нагрузки на диск в момент сброса содержимого журнала в кэш SatMap, конечно тоже до определенного предела, связанного с производительностью диска

А это как? Диск ведь все равно выше своей предельной производительности работать не будет, да и записать в потоке 20, 128 или 1024 файла ему практически безразлично и по сравнению с переписыванием фильма или кэша в 50 GB с диска на диск или тем более с партиции на партицию это вообще не нагрузки. А вот что действительно нагружает и портит диск, так это постоянное дерганье головок и опытные пользователи SatMap хорошо знают как раньше диски летели У меня и самого новый сигейтовский терабайтник грохнулся, пришлось 100 баксов отдать за восстановление информации. А умозрительные теории хороши когда есть более-менее достаточный опыт работы с программой, весьма надо сказать дискодробительной.

relictus

Цитата:

Поэтому число вставок порядка 20-ти и показалось мне и полезным, и относительно безопасным.

Дело говоришь, потому так и сделаю..

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

Так что опытные пользователи все равно 128-1024 выставят, а вот ньюбиков жалко. Хотя 20 вставок конечно лучше чем 1 .

nemo3001

Цитата:

а при 1000 вставках - утрату 4 тыс тайлов (500*8), более полутора часов времени закачки и 36 мб трафика.

это зависит от скорости Инета, у меня в среднем 5-6тайлов\сек спутник (скорость зависит от времени, в час-пик скорось меньше) для однопоточного SatMap, т.е. 1000 тайлов скачивается за 4-5мин.
Т.е. если идёт выкачка на сотни тысач тайлов, то проблемы со скоростью и трафиком обычно нет. И на первое место выходит бережное отношение к HDD.

PS: представляю собой "обычного домашнего пользователя", со спецификой домашнего использования.

relictus
про настрой-ку по-умолчанию в SatMap (кол-во вставок в БД) для общего случая мне сказать сложно, т.к. незнаю как оценить общий случай.

relictus
egor23

Цитата:

у меня в среднем 5-6тайлов\сек

Так как скорость инета и действительно может сильно отличаться у разных пользователей, то наилучшим решением возможно была бы установка в настройках не количества вставок в БД, а времени между вставками, например 30 сек по умолчанию, или больше/меньше по выбору пользователя, хотя возможно это будет чуть труднее отсчитывать в программе, зато критичность-то для нагрузки на диск и для рисков представляет именно не количество тайлов, а временная задержка между накоплением тайлов в журнале и сбросом их в кэш.

Время важнее количества. Выбирая сейчас оптимальное количество вставок для своего случая, все равно ориентируешься-то на скорость закачки, чтобы подобрать на самом деле время. Тогда оптимисты смогут выставлять полчаса, а кому надежность важнее - 30 сек, главное, чтобы не 0 сек, разрушающие жесткие диски...

Так что возможно наилучшим решением была бы настройка времени задержки между вставками в кэш SatMap прямо в секундах (со значением по умолчанию скажем 30 сек), или уж в минутах (например, с шагом 0,5, со значением по умолчанию 0,5 мин). Это позволило бы автоматически учитывать скорость закачки, да и ее изменение тоже. У кого-то за 30 сек скачается 20 тайлов, у кого-то - 150, но величина нагрузки на диск и риска возможной потери времени при сбоях будет сохраняться примерно одинаковой.

Ну, а если в программе останется еще и возможность прежней настройки, по количеству тайлов, так вообще никто в обиде не останется наверное . Жаль только, что изменение количества тайлов по умолчанию займет у программиста 5 сек рабочего времени, а настройка задержки по времени мягко говоря потребует несколько больше работы...

egor23
Что скажешь насчет:

Цитата:

Так что возможно наилучшим решением была бы настройка времени задержки между вставками в кэш SatMap прямо в секундах

?

relictus

Цитата:

?

если это будет ещё одна дополнительная настройка, пускай будет.
Если это будет замена текущих настроек, то возникают вопросы, от времени зависят текущие две настройки, и в частности кол-во страниц.

rex

Цитата:

Если не сильно сложно, сделай так, чтобы при щелчке курсор помещался в центр
карты, на красном крестике. Тогда двойной клик будет нейтрализован.

Сделал: satmap_v2.4.1.3_exe.7z (1.4 МБ)
Попробуй (да и все желающие тоже) и отпишись - стало ли удобнее? Или наоборот - раздражает?

Добавлено:
egor23

Цитата:

возникают вопросы, от времени зависят текущие две настройки, и в частности кол-во страниц.

Ну да, это я как-то упустил из виду...
Сразу что-то отпала охота реализовывать временнУю задержку между вставками

relictus

Цитата:

стало ли удобнее?

Попробовал.
Автоматическое перемещение курсора мыши в центр экрана после щелчка левой кнопкой по карте и центровки в месте этого щелчка - это просто другой, альтернативный способ для перемещения по карте. Сделать бы для этого способа checkbox в настройках программы, чтобы можно было использовать его при желании, а нет - так использовать прежний способ обработки щелчка мыши.

Поясню чуть подробнее. При просмотре карты смещение изображения на экране сейчас можно выполнять кажется тремя способами - перетаскивание с зажатой левой клавишей мыши, щелчок на экране в стороне от центра экрана и стрелками клавиатуры вверх-вниз-влево-вправо.
Если просто принять сделанное изменение и автоматически перемещать курсор мыши в центр экрана после каждого щелчка левой кнопкой по карте, то если сейчас для перемещения изображения скажем на несколько экранов вправо-вверх хватало тех же нескольких щелчков мыши в правом-верхнем углу экрана (это было быстрее, чем несколько зацепов/смещений мышью по диагонали, либо нескольких пар нажатий на клавиатуре вверх-вправо, вверх-вправо...), то теперь перемещение изображения по диагонали превращается в повторения - щелкни мышью/перемести мышь в угол.
Если для перемещения вверх/вниз/влево/вправо теперь все еще можно будет теперь бросить мышь и взяться за клавиатуру, то диагональные смещения изображения станут просто менее удобными. Наоборот, честно говоря, напрашивалось для них добавить бы клавиатурную навигацию по диагоналям клавишами Home/End/PgUp/PgDn, да еще бы и с цифровой части клавиатуры, где физическое расположение клавиш 8-2-4-6 а также 7-1-9-3 прямо соответствует направлениям на север-юг-запад-восток а также на северо-запад и тд. (можно считать это предложением к доработке программы )

Оставив безальтернативным способ перемещения изображения версии программы v2.4.1.3, мы лишимся удобного диагонального перемещения изображения простыми щелчками мыши в углу карты. Ну а добавив этот способ, как один из вариантов перемещения по карте с помощью мыши, можно и существующее удобство сохранить, и помочь тем, кому удобнее автоматическая центровка курсора мыши после щелчка.

Добавлено:
P.S. Ну а если смещаешься вдоль дороги или реки, которая идет под 30 градусов скажем к горизонтали - сейчас поставил курсор мыши у края карты, где идет река/дорога и щелкай последовательно, то после изменений в версии 2.4.1.3 уж досыта надергаешь мышку из центра к краю карты после каждого щелчка... Но это конечно не исключает удобства для кого-то и такого способа управления. В общем тут я - за альтернативность...

nemo3001
Всё разложил по полочкам -
Подожем теперь, что скажет сам автор хотелки

Добавлено:
nemo3001

Цитата:

добавить бы клавиатурную навигацию по диагоналям клавишами Home/End/PgUp/PgDn, да еще бы и с цифровой части клавиатуры, где физическое расположение клавиш 8-2-4-6 а также 7-1-9-3 прямо соответствует направлениям на север-юг-запад-восток а также на северо-запад и тд. (можно считать это предложением к доработке программы )

Ну,
1) насколько я знаю, не на всех клавах есть "цифровая часть клавиатуры"
2) диагонального смещения можно достичь нажимая одновременно лево-вверх, право-низ и т.п.

relictus
а если ДаблКлик ЛКМ поставить на перемещение с центровкой, а одиночный оставить как было

zporuchik
ДаблКлик в окне вьювера невозможно использовать чисто по техническим причинам

relictus

Цитата:

насколько я знаю, не на всех клавах есть "цифровая часть клавиатуры"

да, конечно, на ноутбуках, например. Но и там обычно есть вкл/выкл эмуляции цифровой клавиатуры через Fn+NumLck или Fn+спец.кнопка.
Расширенные скан-коды клавиш цифровой клавиатуры отличаются от кодов аналогичных по функциям стрелок/PgUp/PgDn и тд, поэтому вроде бы программа не обидится, если в условия цепочки case (или в последовательность команд if, как уж там это в программе сделано) просто добавить через ИЛИ еще и скан-коды цифровой части клавиатуры. У кого нет/не включена эта часть клавиатуры, для того просто не сработает условие ИЛИ и все...

Цитата:

нажимая одновременно лево-вверх, право-низ и т.п

ну, однократное нажатие на клавиши Home/End/PgUp/PgDn все-таки удобнее этой "лезгинки" по стрелкам

Впрочем, конечно, это просто предложение, разве что еще кто-то выскажется за него...

nemo3001

Цитата:

Впрочем, конечно, это просто предложение

Разреши мне не браться за него
А то я с этими "мелочевками" просто никогда не внедрю что-то новое...

relictus

Цитата:

Попробуй (да и все желающие тоже) и отпишись - стало ли удобнее? Или наоборот - раздражает?

Спасибо! Стало на порядок удобнее!

Что касается конно-шахматной идеи nemo3001 использовать центровку для многократного перемещения щелчками, то идея конечно интересная и у nemo3001 похоже оригинальных и нестандартных идей еще много , но думаю если в SatMap исчезнет возможность чесать левое ухо правой ногой, программа не пострадает .

По по поводу:

Цитата:

Так что возможно наилучшим решением была бы настройка времени задержки между вставками в кэш SatMap прямо в секундах

Не бери дурного в голову . Это еще один оригинальный прожект. Скорость закачки не постоянна и геморрой будет еще тот, а пользы пшик. Просто установи по дефолту любое из понравившихся тебе значений количества вставок в диапазоне 16 - 128. Для защиты диска начинающего пользователя вполне достаточно, а опытный все равно под свой интернет и свои задачи сам все подстроит.

О цифровой клавиатуре. SatMap все-таки в перспективе программа для мобильного использования, а это практически исключает возможность использования цифровой клавиатуры. Вариант через Fn+key теоретически конечно возможен, но лишь дома за столом.

Добавлено:
relictus

Цитата:

диагонального смещения можно достичь нажимая одновременно лево-вверх, право-низ и т.п.

Вот когда понимаешь потребность в нормальном хелпе. Попробуем применить на нетбуке.

rex

Цитата:

Стало на порядок удобнее!

Да? Хм..а как по мне, так - нет, посему сделаю-ка я это опционально

nemo3001

Цитата:

а может быть этот номер экземпляра программы, который ты вывел в заголовок программы, теперь можно будет продублировать и в заголовке загрузки перед словом "Выделение", да и в окне капчи тоже - в начале заголовка перед датой/временем, а то не видно, чья это капча в очередной раз жить мешает

Цитата:

И еще. В трее, где написано оставшееся время закачки для текущего экземпляра программы, в случае появления капчи может быть вместо "[время] - SatMap" выводить, например, "[!] - SatMap"

Сделал, протестируй: satmap_v2.4.1.5_multi_exe

relictus


Цитата:

Сделал, протестируй: satmap_v2.4.1.5_multi_exe

Да, все работает как надо, в капче виден номер экземпляра, в трее видно, кто ждет ответа на капчу.
Я тут сталкивался несколько раз с тем, что программа, не докачав список сама выводила окно "Сохранить список закачки? Да/Нет" и приостанавливала работу, а по трею это конечно оставалось незамеченным. Может быть есть смысл при появлении этого окна независимо от причины (нажатие клавиши Стоп в закачке и пр) тоже в трее вместо "[время] - SatMap" выводить, например, просто "SatMap". Если пользователь нажал Стоп при закачке, время ему уже не нужно, а по трею будет все-таки видно, что закачки в этом экземпляре уже нет.
Аналогично - при появлении на экране сообщения - что-то вроде "Попытка установить соединение при отсутствующем сокете" (иногда появляется при разрыве связи с инетом), или что-то похожее - нет сейчас под рукой такого окна.
В общем - вышел из режима закачки, сменить бы и заголовок в трее на "SatMap" вместо "[время] - SatMap".


Цитата:

Разреши мне не браться за него

Все наши разговоры тут, это не больше, чем просто желание помочь тебе в улучшении программы (а себе конечно - в ее использовании). Когда очередное предложение по любой причине тебе хочется отклонить - отклоняй без сомнений, а будет время или самому понадобится - вернешься к нему и сделаешь...
И вообще, тебе можно было бы подумать о помощнике, который бы в твоем коде разбирался бы как в родном и мог бы делать мелкие доделки в него, допуская минимум ошибок (и хотел бы этого ) . Лучше конечно поискать бы его не в виртуальном, а в физическом твоем окружении, так проще определяться с доверием и слаженностью в работе. Хотя, наверное найти такого помощника - почти как в рекламе сыра - "это - фантастика" .

Кстати, обнаружилась приятная особенность при работе с SatMap, вдруг кому и пригодится.
Я разместил несколько экземпляров мультиверсии SatMap в разные папки, назвав их SatMap_01, SatMap_02 и тд. А заодно переименовал в каждой из этих папок EXE файл программы соответственно в 01_SatMapGPS_multi.exe, 02_SatMapGPS_multi.exe и тд. Просто хотел, чтобы каждый экземпляр легко было идентифицировать в Диспетчере задач.
А Windows, запоминая по имени EXE файла в диалоговом окне открытия списка закачки последнюю использовавшуюся папку, теперь мне всегда четко для каждого экземпляра SatMap (имена-то EXE файлов теперь у них разные) сразу предлагает нужную папку для открытия списка закачки. Мелочь, а удобно...

nemo3001

Цитата:

Может быть есть смысл при появлении этого окна независимо от причины (нажатие клавиши Стоп в закачке и пр) тоже в трее вместо "[время] - SatMap" выводить, например, просто "SatMap".

Может и есть смысл, подумаю
Кстати, почему ты все время называешь треем панель задач (таскбар)?

Цитата:

И вообще, тебе можно было бы подумать о помощнике, который бы в твоем коде разбирался бы как в родном и мог бы делать мелкие доделки в него

Дык где ж его взять-то, да еще и в физическом воплощении?

relictus

Цитата:

Да? Хм..а как по мне, так - нет, посему сделаю-ка я это опционально

Сам хотел это предложить, чтобы было и вашим и нашим, но зная о твоей нелюбви к опциональности воздержался

relictus
netrebos
egor23
Ну вот наконец-то выбрал время, чтобы рассмотреть влияние на возможность снижения количества дисковых операций настройки SatMap, названной "Размер кэша БД SQLite", значение по умолчанию - 2000 страниц, прочитал конечно обсуждение этой настройки на форуме в мае, после появления версии SatMap v2.3.7.
Хотелось понять, как связана эта настройка с настройкой количества вставок в БД до завершения транзакции и как повлияет на количество дисковых операций различный размер кэша БД SQLite в зависимости от разного количества вставок в БД.

Кратко напишу, как я себе представляю использование программой кэша БД SQLite и какие выводы можно сделать из этого.

Стоит сказать, что термином "кэш" (cache) можно назвать самые разные вещи (даже наличные деньги так называют, только это уже "cash"). Переведу в нашем случае это слово как "место хранения, хранилище" и постараюсь хотя бы по-разному именовать разные виды кэша, которые используются программой SatMap - временные, постоянные, на жестком диске, в ОЗУ.
Ну, например,
1) "кэш SatMap" - это БД SQLite, постоянное хранилище тайлов и связанной с ними информации на жестком диске.
2) "Журнал" - это временное хранилище тайлов на жестком диске до передачи их в кэш SatMap.
3) "Кэш БД SQLite", указанный в настройках программы, это временное хранилище информации в ОЗУ компьютера, используемое "движком" SQLite (то есть встроенными функциями SQLIte) для работы с БД SQLite.
А еще в настройках SatMap есть "Внутренний кэш", но это уже временное хранилище тайлов в ОЗУ, предназначенное для ускорения просмотра карты на экране и не имеющее прямого отношения к закачке/сохранению тайлов.

В упрощенном представлении пути тайла из интернета в кэш SatMap, как "закачка тайла -> журнал => кэш SatMap", на самом деле стрелки отмечают места, где вероятно и используется кэш БД SQLite.

На первом этапе, после получения тайлов из интернета они вероятно не записываются сразу в журнал поштучно, а сначала накапливаются в кэше БД SQLite в ОЗУ и записываются в журнал одной порцией либо при заполнении этого кэша до предела, указанного в настройке программы, либо при выполнении команды в программе о завершении транзакции (напомню, что в этот момент вся информация из журнала копируется в кэш SatMap и журнал после этого очищается или удаляется).
Во всяком случае вроде так описывал ситуацию relictus по документации к SQLite:

Цитата:

все скачанные тайлы будут находиться в области памяти, зарезервированной движком SQLite

Используется ли этот кэш БД SQLite на втором этапе, при копировании информации из журнала в кэш SatMap, конечно не ясно, но тоже вероятно. Чем копировать из журнала по одной записи, вроде бы быстрее прочитать группу записей в ОЗУ и записать их оттуда в кэш SatMap.
Этот вопрос хорошо бы еще уточнить, потому что при недозаполненном кэше БД SQLite и завершении транзакции вроде бы нет необходимости записывать сначала скачанные тайлы в журнал, потом читать их в ОЗУ и снова записывать их же в кэш SatMap, а тем не менее в прошлом тесте мы видели, что дисковые операции с журналом происходят активно.
Журнал транзакций нужен для надежной, с возможностью отката при аварии, записи тайлов в кэш SatMap. Если настройка размера кэша БД SQLite здесь влияет на работу, то видимо надо добиваться, чтобы весь журнал входил целиком в кэш БД SQLite, иначе потребуется считывать его несколько раз порциями. А если настраиваемый размер кэша БД SQLite здесь не участвует, то достаточно будет подробно рассмотреть работу программы только на первом этапе - от закачки тайлов и накопления их в ОЗУ до копирования тайлов в журнал.

Впрочем, теперь уже несложно описать требования к настройкам программы для первого этапа получения тайлов - от интернета до журнала.
Суммарный размер тайлов до завершения транзакции должен быть меньше указанного в настройках размера кэша БД SQLite, тогда все закачанные тайлы (в количестве, указанном в настройке "количество вставок в БД") будут записаны из ОЗУ в журнал за один раз.
Иначе же тайлы все равно будут записываться в журнал порциями, но меньшего размера, в соответствии с указанным в настройках размером кэша БД SQLite. Это тоже достаточно безопасно по нагрузке на жесткий диск, запись будет производиться не по одному тайлу, просто порции эти будут поменьше, чем мы установим в настройке "количество вставок в БД".

Например, мы установили "количество вставок в БД" по 1000 штук, а в кэш БД SQLite вошло только 600 тайлов. Тогда первой порцией в журнал запишется 600 тайлов, второй порцией - оставшиеся 400 и все, поступит команда завершения транзакции. Вместо однократного обращения к жесткому диску будет двукратное, но с меньшим объемом информации за 1 раз.

Вот и все, никакой чрезвычайной нагрузки на жесткий диск не произойдет, даже если мы неверно установили размер кэша БД SQLite и указанное нами "количество вставок в БД" не вместилось в этот кэш.

Осталось подсчитать, сколько же "вставок в БД" поместится при указанном в настройках по умолчанию размере кэша БД SQLite в 2000 страниц.
relictus уже писал, что размер 1 страницы кэша БД SQLite - 16 кб и общий его размер по умолчанию составляет в программе 16*2000= 32 мегабайта.
Размер 1 тайла изменяется в широких пределах, от 1-2 до 30 кб и возможно больше. Например, тайл x=1654&y=635&z=11 оказался размером 29135 байт, но средний размер 16 тыс соседних с ним тайлов уже оказался 18000 байт.
Для максимальной оценки возьмем закачку самых больших по размеру тайлов. Тогда в кэш БД SQLite по умолчанию войдет примерно 1000 таких больших тайлов, а реально, с учетом среднего их размера - в 2 раза больше.

Я первоначально рекомендовал "количество вставок в БД" в 20 шт, а в тесте пробовал цифры в 50 и 100 шт. Мы помним, что rex писал об использовании им количества вставок в 128 шт, egor23 говорил, что использует 1000 вставок в БД до завершения транзакции.
Как теперь видно, и 20 и 1000 вставок в БД спокойно, с большим запасом вмещаются в кэш БД SQLite, установленный в программе по умолчанию.

А значит не стоит опасаться и "настройки времени задержки между вставками в кэш SatMap прямо в секундах" (со значением по умолчанию в 30 сек) вместо или вместе с существующей сейчас настройкой "количество вставок в БД".
Со скоростью 10 тайлов в сек (где бы еще взять такую скорость ) пользователь будет заполнять кэш БД SQLite в течение 100-200 секунд, то есть целых полторы-три минуты, а реально - так конечно больше. А если он при этом забудет увеличить размер кэша БД SQLite, то просто раз в несколько минут этот кэш все равно будет записываться в журнал. И никакой проблемы в этом видимо нет.

Так что, если конечно хватило сил дочитать до конца все это безобразие, я как смог попытался развеять пессимизм фраз:


Цитата:

возникают вопросы, от времени зависят текущие две настройки, и в частности кол-во страниц.

Цитата:

Ну да, это я как-то упустил из виду...
Сразу что-то отпала охота реализовывать временнУю задержку между вставками

Вывод из всего этого получился очень простой.

1. Имеющаяся сейчас в программе по умолчанию настройка размера кэша БД SQLite в 2000 страниц обеспечивает безопасную для жесткого диска закачку тайлов при большом диапазоне возможных настроек количества вставок в БД до завершения транзакции, от, скажем, 20 вставок и больше, вплоть до 1000 вставок в БД.

2. Добавление настройки времени задержки между вставками в кэш SatMap прямо в секундах, что позволило бы автоматически регулировать нагрузку на жесткий диск для пользователей с самыми разными скоростями доступа в интернет, никак не ухудшает режимы работы жесткого диска, если установить ее значение не меньше 20-30 сек.

nemo3001

Цитата:

Например, мы установили "количество вставок в БД" по 1000 штук, а в кэш БД SQLite вошло только 600 тайлов. Тогда первой порцией в журнал запишется 600 тайлов, второй порцией - оставшиеся 400 и все, поступит команда завершения транзакции.

при заполнении кэша БД SQLite начинается постоянная запись на диск (что-то типа продолжения кэша БД SQLite), пока не скачаются все тайлы "количество вставок в БД".

Цитата:

Осталось подсчитать, сколько же "вставок в БД" поместится при указанном в настройках по умолчанию размере кэша БД SQLite в 2000 страниц.

здесь нет прямой зависимости от размера скаченного
есть зависимость от количесвтва скаченных тайлов и размера скаченного
http://forum.ru-board.com/topic.cgi?forum=5&topic=30026&start=1580#9

Цитата:

relictus уже писал, что размер 1 страницы кэша БД SQLite - 16 кб и общий его размер по умолчанию составляет в программе 16*2000= 32 мегабайта.

Цитата:

размер = 16КБ (типа размера кластера в файловой системе)

http://forum.ru-board.com/topic.cgi?forum=5&topic=30026&start=1760#7

egor23

Цитата:

при заполнении кэша БД SQLite начинается постоянная запись на диск ... пока не скачаются все тайлы "количество вставок в БД"

Ну вот, нашлось что мне протестировать и с кэшем БД SQLite, а то пока у меня это была книжка без картинок

Использовал для теста Filemon, наблюдал с помощью него за режимами дисковых операций с журналом и кэшем SatMap.
Уменьшить в ходе тестирования количество страниц меньше 2000 программа не позволила, пришлось протестировать закачку слоя Спутник с заведомо большими по размеру тайлами (12 уровень, Сибирь) сначала в базовом режиме: 64 вставки в БД на 2000 страниц кэша БД SQLite, а потом - в аварийном режиме: 1500 вставок в БД на 2000 страниц кэша БД SQLite.
Так как тайлы были большого размера, предполагал на основании утверждения egor23, что примерно после 1000 скачанного тайла кэш БД SQLite переполнится и режим обращения программы к жесткому диску изменится.
Так и произошло. Если еще на 850-м тайле характер обращения в жесткому диску не менялся: группа записей в журнал и кэш SatMap - пауза примерно в 20 сек - новая группа записей, то примерно на 1250 тайле характер обращения к жесткому диску уже был в виде непрерывного, без пауз, обращения вперемешку к журналу и к кэшу SatMap.

Это может означать только одно. В имеющейся реализации SQLite переполнившийся кэш БД SQLite при еще незавершенной транзакции не очищается путем сброса накопившихся записей на жесткий диск - сразу всех или хотя бы большой их части (например, половины или трети записей сразу), а переходит практически в режим работы без кэша в ОЗУ, начав поштучно сразу записывать на жесткий диск, в журнал, каждую поступающую в него запись.

Для нас это означает, что отнестись внимательно к недопущению переполнения кэша БД SQLite в процессе закачки придется нам самим, переложить эту заботу на плечи движка БД SQLite не удастся.

А раз так, то подсчет текущей заполненности кэша БД SQLite записями придется произвести более тщательно.

egor23

Цитата:

есть зависимость от количества скаченных тайлов и размера скаченного

Постраничная запись в кэш БД SQLite конечно требует внести коррективы в мои расчеты заполнения этого кэша, тут ты абсолютно прав.

То, что записи БД вносятся в кэш постранично, реально может означать все-таки два способа занесения записей БД на страницы кэша БД SQLite.
Первый способ такой же, как происходит запись файлов в кластеры файловой системы, когда даже самый маленький файл всегда занимает целый кластер, а большой файл заполняет полностью цепочку кластеров кроме последнего, в который помещается остаток этого файла. Часть пространства кластера, где записан маленький файл или остаток большого файла, всегда бесцельно пропадает, не используется. Кластер здесь - минимально возможная единица записи информации.
Второй способ, кажется все-таки используется, например, в базах данных MS SQL Server и, возможно, в SQLite тоже. Он заключается во внесении на страницу нескольких полных записей, а когда очередная запись уже не входит на страницу целиком, она заносится на следующую свободную страницу и остаток предыдущей страницы так же бесцельно пропадает, не используется. Например, записи длиной в 5 кб размещаются на 16 кб страницах по 3 шт на странице, а 1 кб в конце каждой страницы не используется.

Использует ли SQLite для записи в кэш БД SQLite второй способ постраничной записи мы не знаем, это можно выяснить отдельным тестом. Но пока будем исходить из пессимистичного варианта использования пространства кэша БД SQLite - из первого способа, кластерной записи.
Тогда каждая будущая запись нашего кэша SatMap - сам скачанный тайл и несколько (предположим, 100) байт другой информации (координаты тайла и прочее) всегда будет занимать в кэше БД SQLite ровно либо 16 кб, либо 32 кб (для тайлов, которые больше 16 кб), либо 48 кб (для самых больших тайлов, размером больше 32 кб).

Идеальным вариантом было бы в этом случае использование встроенной функции SQLite, которая сообщала бы, сколько еще свободных страниц осталось в кэше БД SQLite. Если такой функции сейчас у них нет, то это - повод написать письмо разработчикам БД SQLite .
Используя такую функцию, программа могла бы при окончании свободного места в кэше БД SQLite (осталось 0 свободных страниц), просто завершить транзакцию заранее, не дожидаясь указанного нами в настройках "количества вставок в БД" или не дожидаясь окончания времени задержки между вставками в кэш SatMap. И все. После завершения транзакции кэш БД SQLite очистится, все страницы в нем освободятся и аварийного режима его работы не будет. Жесткий диск не подвергнется перегрузке поштучной записи тайлов.

А если такой функции вдруг сейчас в SQLite нет, то выход все-таки есть.
Эту функцию программа может заменить сама прямым самостоятельным подсчетом оставшихся свободных страниц в ходе загрузки тайлов. Для этого сразу после начала очередной транзакции можно установить значение переменной, какой-нибудь SQLiteFreePagesCount, в соответствии с настройками программы в разделе "Кэш" (например, в 2000), а в процессе загрузки тайлов уменьшать значение этой переменной в зависимости от размера очередного скачанного тайла + предположим 100 байт дополнительной информации (эту добавку придется подобрать, можно ее и с небольшим запасом сделать).
Формула для определения того, сколько целых страниц кэша БД SQLite занимает очередная запись (тайл+100 байт), конечно совсем несложная, выглядит она примерно так: целая часть от (размер записи в байтах/16384) + 1.
Как только переменная SQLiteFreePagesCount стала = 0, завершаем транзакцию независимо от других наших настроек в программе, Commit, кэш БД SQLite очищается и жесткий диск не пострадает.

Все вроде. Интересно, конечно, мнение relictus на все эти выдумки

nemo3001

Цитата:

Интересно, конечно, мнение relictus на все эти выдумки

Мое мнение - может напишешь несколько Q:A про все эти вставки/страницы для ФАКа, а? Так складно всё излагаешь, да еще и доступным языком (я бы так не смог), случаем не журналист научно-популярного издания?


Цитата:

Идеальным вариантом было бы в этом случае использование встроенной функции SQLite, которая сообщала бы, сколько еще свободных страниц осталось в кэше БД SQLite. Если такой функции сейчас у них нет

Нет


Цитата:

Использует ли SQLite для записи в кэш БД SQLite второй способ постраничной записи мы не знаем, это можно выяснить отдельным тестом.

Я что-то тоже не смог найти инфы об этом...


Цитата:

Как только переменная SQLiteFreePagesCount стала = 0, завершаем транзакцию независимо от других наших настроек в программе, Commit, кэш БД SQLite очищается и жесткий диск не пострадает.

Звучит складно Надо только выяснить метод наполнения кэша SQLite...

Фигасе простыни в теме.

Alex Zaguzin
ну хоть конструктивные простыни, а потом это целиком в ФАК можно копипастить.
Сам офигиваю от количества букоф, но молчу ))) и читаю, а вдруг умнее стану.

relictus

Цитата:

Надо только выяснить метод наполнения кэша SQLite

А можно и не выяснять. Реализовать да и все. Подсчитывать исходя из первого, кластерного варианта, тогда все равно не дашь переполниться кэшу БД SQLite, как бы он не старался
Конечно, периодически ты будешь очищать этот кэш раньше, чем он заполнится, особенно при записях с неполученными тайлами, когда стоит отметка "Сохранять в кэше информацию о недоступных тайлах". Ну тут лучше завершить транзакцию раньше, чем позже. Тем более, что пока другого способа покорить этот кэш БД SQLite вроде нет.

Alex Zaguzin

Цитата:

Фигасе простыни в теме

Ну, сорри... Надеюсь, что дальше удастся писать покороче

nemo3001
А мое предложение насчет ФАКа/хэлпа долго будешь игнорировать-то? Так и осталось висеть в пустоте

relictus

Цитата:

А мое предложение насчет ФАКа/хэлпа долго будешь игнорировать-то

Тут народ и так зеленеет уже от деталей технических, а в факе все это читать совсем закучают .
А я вот по другому думаю - чем умнее станет сама твоя программа, тем меньше надо будет пользователям в факе настройки объяснять, все по умолчанию работает максимально оптимизировано, кэши всякие жить не мешают, пользуйся для радости - и все. Я как-тот писал уже тут - "Должно же когда-нибудь счастье в жизни стать абсолютным"
Ну, а если серьезно - фанатское руководство по SatMap, как видишь, постепенно так и будет здесь складываться. Дадим ему время.

nemo3001

Цитата:

Тут народ и так зеленеет уже от деталей технических, а в факе все это читать совсем закучают

Ну а ты напиши только квинтэссенцию своих "простыней"
Кто любит читать многостраничные топики с самого начала? Так и потеряются твои результаты тестов и выводы......

relictus
nemo3001
таак. не отвлекайтесь. давайте дальше уже по БД. Мне уже интересно во что это выльется.