nemo3001
Member | Редактировать | Профиль | Сообщение | Цитировать | Сообщить модератору
relictus
parasss,egor23
Как и многие тут на форуме, я тоже обратил внимание на достаточно сильный рост нагрузки на жесткий диск при одновременной закачке тайлов несколькими копиями SatMap.
Решил протестировать возможность снижения количества дисковых операций, используя настройки SatMap, посмотрел предварительно, что тут на форуме писали об этом.
Для тех пользователей SatMap, кто не в курсе технологии транзакции, кратко напишу, как я это себе представляю (а кто во всем этом разбирается лучше меня, можете сразу к тесту моему перейти, ну или поправить меня там, где я напишу глупости всякие).
Путь тайла из интернета в кэш SatMap при включенном режиме транзакций упрощенно выглядит так: закачка тайла -> журнал -> кэш SatMap. Количество тайлов, записываемых в журнал до их передачи в кэш SatMap, настраивается в разделе "Кэш" -"Завершить транзакцию после...". Сейчас там по умолчанию стоит "после 1 вставки в БД". То есть сейчас каждый тайл сначала из интернета скачивается в журнал, потом он передается в кэш SatMap и журнал очищается (как очищается - см. дальше).
Кроме того, стоит иметь ввиду, что передача тайла из журнала в кэш - это не только создание записи в кэше, физическое копирование туда полей записи, включая тайл, но и перестройка индекса в БД SQlite. 10 вставок отдельных записей видимо заставляет БД 10 раз перестраивать индекс, 1 вставка сразу 10-ти записей перестраивает индекс 1 раз.
Вести этот журнал можно 4 разными способами (DELETE,TRUNCATE,PERSIST и MEMORY), или вообще отключить его (OFF) и тогда закачанный тайл сразу будет записываться в кэш SatMap.
Причем из документации SQlite, которую тут цитировал relictus, следует, что в вариантах MEMORY и OFF при любых сбоях в момент записи тайлов в кэш SatMap (электропитание и пр.), "the database file will very likely go corrupt", то есть база данных с большой вероятностью будет безнадежно испорчена, накопленный кэш SatMap пойдет "фтопку".
Надежными способами ведения журнала таким образом остаются:
1) DELETE - создание файла журнала, заполнение его, копирование записей в БД, удаление файла журнала с диска. Это способ сейчас используется в SatMap по умолчанию, если ничего в программе не настраивать.
2) TRUNCATE - однократное создание файла журнала, а затем - циклично: заполнение его, копирование записей в БД, изменение размера файла до 0 байт (без удаления файла с диска)
3) PERSIST - однократное создание файла журнала, а затем - циклично: заполнение его, копирование записей в БД, перезапись заголовка журнала нулями (размер файла при этом не изменяется)
Таким образом, для теста снижения количества дисковых операций сами собой напросились:
1)увеличение количества вставок тайлов в журнал до передачи их в кэш SatMap ("Настройки" - "Кэш"), и
2) использование различных безопасных режимов журнала транзакций, используя настройку в файле satmap.xml в секции <prog> параметра <JM>режим</JM> (то есть, записать туда <JM>DELETE</JM>, или <JM>TRUNCATE</JM> и тд).
Для этого теста:
1) запускал на закачку тайлов SatMap
2) использовал Filemon для протоколирования дисковых операций
3) сохранял результат Filemon в текстовый файл
4) открывал полученный файл в Excel, подсчитывал промежуточные итоги количества записей по столбцу "время" (в меню Excel "Данные"-"Итоги"), потом либо суммировал эти количества за разные промежутки, либо подсчитывал среднее.
Результаты теста в таблице:
===========================================================
Количество DELETE TRUNCATE PERSIST
дисковых ----------- ----------- -------------
операций Вставок в БД: 1 20 50 1 20 50 1 20 50 100
===========================================================
за 1 цикл записи (средн) - 105 155 - 120 168 - 130 150 220
----------------------------------------------------------------------------
за 1 сек (средн/ 82 45 33 139 49 45 143 40 56 159
макс) 159 105 126 196 116 154 194 123 141 183
----------------------------------------------------------------------------
за 30 сек 2237 221 191 4102 355 340 4048 398 295 210
----------------------------------------------------------------------------
за 60 сек 4475 435 353 >8000 615 450 >8000 - - 320
----------------------------------------------------------------------------
за 5 мин - 1328 - - 2368 - - 2467 - -
(в % к DELETE) 1,78 1,85
============================================================
Передать здесь, в тексте сообщения, эту таблицу в наглядном виде - дело безнадежное, поэтому для тех, у кого все цифры смешались на экране в кучу, сообщу коротко словами результаты теста.
1. Обязательно надо увеличивать количество вставок в БД до завершения транзакции - до 20-ти или выше, в зависимости в от скорости закачки и своего оптимизма. Рекомендую цифру 20, при которой риски остаются малыми, а количество обращений к диску сокращается в 10 (!) раз (например, с 2237 раз за 30 сек - до 221 раза). Если увеличивать количество выше 20-ти, начинают расти пиковые (максимальные) нагрузки на диск в 1 сек, что и понятно - сначала накопили в журнале много тайлов, а потом надо их сразу записать в кэш, вот тут-то диск поскрипит немного и затихнет до следующей порции.
relictus, не мог бы ты сделать в программе по умолчанию именно 20 вставок в БД до завершения транзакции вместо 1, как сейчас? Чтобы программа запускалась сразу с этой настройкой и пореже бы заигрывала с жестким диском  .
2. При режиме ведения журнала DELETE нагрузка на жесткий диск по количеству обращений к нему неожиданно оказалась ниже, чем в режимах TRUNCATE и PERSIST. Казалось бы каждый раз удалять/создавать файл журнала труднее, чем просто обнулять его длину или записывать нулики в его начало. Может быть это, кстати, так и есть, я-то тестировал КОЛИЧЕСТВО, а не ПРОДОЛЖИТЕЛЬНОСТЬ дисковых операций. Но по этому тесту (в последней строке таблицы) - количество обращений к диску в режимах TRUNCATE и PERSIST почти в 2 раза больше, чем в режиме по умолчанию DELETE. Поэтому все-таки рекомендую ничего не изменять в файле satmap.xml в секции <prog>, параметр <JM>режим</JM>. Может быть конечно кто-то потестирует этот момент более тщательно и даст другие выводы, но пока это так.
|
Всего записей: 234 | Зарегистр. 06-05-2010 | Отправлено: 17:16 19-06-2010 | Исправлено: nemo3001, 17:29 19-06-2010 |
|
. 
