Масштабируемость

Интересно бывает наблюдать за изменением отношения к предмету с ходом времени, вернее, с накоплением опыта.

Вот, к примеру, день назад мне казался очень интересным вопрос — почему с увеличением количества обработчиков (процессов) общая производительность падает, хотя должна бы возрастать. Нет, не абстрактно а вполне конкретно — на задаче генерации тайлов кеша для некоей карты в ArcGIS Server. А сегодня (после проведения серии бесчеловечных опытов :) мне этот вопрос уже не кажется столь интересным, ибо ответ на него почти очевиден.

Или другой вопрос — почему генератор кеша (ManageMapServerCacheTiles) отваливается по таймауту (A request to obtain a free ServerContext has failed because the Wait Timeout Interval has elapsed) и что с этим делать?

Поскольку гугление показывает, что очевидность эта условная (многие задают эти или похожие вопросы, но не получают или не понимают ответа), расскажу историю.

Поставлена задача — посчитать тайлы для кешированного картографического сервиса, на основе ArcGIS Server. Документация рассказывает, что чем больше процессов (в их терминологии — потоков) натравить на расчет, тем быстрее оно посчитается. И в это можно поверить, ибо теоретически задача прекрасно параллелится, вплоть до того, что можно один тайл считать отдельным потоком.

Есть железка с 8-ю ядрами и достаточным количеством памяти. В теории, можно зарядить до 16-ти потоков.

Практика же показала, что оптимальным (быстрейшим) конфигом (тут необходимо забежать вперед и уточнить: для заданной конкретной карты) будет конфиг с 5-ю потоками. При 6-ти и более расчет либо выдает сбой из-за непонятного таймаута, либо просто медленнее выполняет задачу. Собственно, сбой по таймауту и сподвиг меня на исследование вопроса об оптимальном количестве потоков. Про таймаут перетрем чуть позже.

Так вот, оптимальное количество потоков волшебным образом совпало с количеством используемых в карте источников данных. В качестве каковых используются FileGeodatabase — gdb. Их пять. Возможно, это просто совпадение, чтобы утверждать что-либо надо сперва провести массу практических экспериментов. Я же для себя сделал вывод — для каждого конкретного картпроекта надо опытным путем подбирать оптимальное количество потоков. Это не сложно, берем таймер и прогоняем тестовый счет минут на 5-15 для разных вариантов конфига.

Я выше говорил про то, что вопрос потерял свою интересность из-за очевидности ответа. Очевидность заключается в том, что, как известно, формат источника данных — gdb не предусматривает совместной/параллельной работы. Хотя в теории, при построении тайлового кеша данные используются только на чтение, что не должно вызывать блокировок. Так что, возможно, это неправильная очевидность. Пусть меня поправит тот, кто знает лучше.

А теперь про таймаут, из-за которого отваливалась процедура счета.

При достаточно большом количестве потоков (я проверял 12 и 16), инструмент выдавал такое сообщение о ошибке

Executing: ManageMapServerCacheTiles wrngis1 Sborka4cache Layers 'СЛОИ для КЭШа' 591657527,591555;295828763,795777;147914381,897889;73957190,948944;36978595,474472 "Recreate Empty Tiles" "-22954246,8225262 -3753860,36441453 22461579,686571 24540920,4368881" 12 NONE # IGNORE_COMPLETION_STATUS_FIELD # # Start Time: Wed Mar 28 18:33:00 2012 Finding missing tiles ERROR 000564: Completed with error. One or more server contexts failed. Failed to execute (ManageMapServerCacheTiles

при этом в журнале ArcGIS Server наблюдались такие записи

<Msg time='2012-03-28T20:10:59' type='WARNING' code='2008' target='Sborka4cache.MapServer' thread='1700' elapsed='60,00000'>A request to obtain a free ServerContext has failed because the Wait Timeout Interval has elapsed.</Msg>

И, что любопытно, в конфиге сервиса указаны таймауты

<WaitTimeout>60</WaitTimeout> <IdleTimeout>1800</IdleTimeout> <UsageTimeout>3000000</UsageTimeout>

Параметр

<WaitTimeout>60</WaitTimeout>

задается равным 60 секунд по умолчанию, при создании сервиса. И этого времени, очевидно, не хватает.

После того, как я увеличил этот параметр до 600 секунд (<WaitTimeout>600</WaitTimeout>), процедура перестала отваливаться с сообщением об ошибке и считала все корректно. Но, как выяснилось, медленно. На 12-ти потоках я в журнале ArcGIS Server видел такие числа

<Msg time='2012-03-28T21:11:29' type='INFO3' code='4006' target='Sborka4cache.MapServer' machine='wrngis1'
thread='1540' elapsed='122,12500'>Server Context created.</Msg>

то есть, время ожидание более 2-х минут. Что я исправил, уменьшив количество потоков до 5-ти.

В общем, если следить за этим показателем в логах, то можно поймать момент, когда конфиг перестает быть оптимальным. Ну и в целом, полезно иногда проанализировать журнал на предмет поиска чрезмерных elapsed-ов.