Записки программиста, обо всем и ни о чем. Но, наверное, больше профессионального.

2012-03-30

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

Интересно бывает наблюдать за изменением отношения к предмету с ходом времени, вернее, с накоплением опыта.
Вот, к примеру, день назад мне казался очень интересным вопрос — почему с увеличением количества обработчиков (процессов) общая производительность падает, хотя должна бы возрастать. Нет, не абстрактно а вполне конкретно — на задаче генерации тайлов кеша для некоей карты в 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-ти и более расчет либо выдает сбой из-за непонятного таймаута, либо просто медленнее выполняет задачу. Собственно, сбой по таймауту и сподвиг меня на исследование вопроса об оптимальном количестве потоков. Про таймаут перетрем чуть позже.

Так вот, оптимальное количество потоков волшебным образом совпало с количеством используемых в карте источников данных. В качестве каковых используются FileGeodatabasegdb. Их пять. Возможно, это просто совпадение, чтобы утверждать что-либо надо сперва провести массу практических экспериментов. Я же для себя сделал вывод — для каждого конкретного картпроекта надо опытным путем подбирать оптимальное количество потоков. Это не сложно, берем таймер и прогоняем тестовый счет минут на 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-ов.

Комментариев нет:

Отправить комментарий

Архив блога

Ярлыки

linux (241) python (191) citation (185) web-develop (170) gov.ru (156) video (123) бытовуха (111) sysadm (100) GIS (97) Zope(Plone) (88) Book (81) programming (81) бурчалки (80) грабли (77) development (73) Fun (72) windsurfing (72) Microsoft (64) hiload (62) opensource (58) internet provider (57) security (57) опыт (55) movie (52) Wisdom (51) ML (47) language (45) hardware (44) JS (41) curse (40) money (40) driving (39) DBMS (38) bigdata (38) ArcGIS (34) history (31) PDA (30) howto (30) holyday (29) Google (27) Oracle (27) virtbox (27) health (26) vacation (24) AI (23) Autodesk (23) SQL (23) Java (22) humor (22) knowledge (22) translate (20) CSS (19) cheatsheet (19) hack (19) tourism (18) Apache (16) Manager (15) web-browser (15) Никонов (15) happiness (14) music (14) todo (14) PHP (13) weapon (13) HTTP. Apache (12) SSH (12) course (12) frameworks (12) functional programming (12) hero (12) im (12) settings (12) HTML (11) SciTE (11) crypto (11) game (11) map (11) scala (10) HTTPD (9) ODF (9) купи/продай (9) benchmark (8) documentation (8) 3D (7) CS (7) DNS (7) NoSQL (7) Photo (7) cloud (7) django (7) gun (7) matroska (7) telephony (7) Microsoft Office (6) VCS (6) bluetooth (6) pidgin (6) proxy (6) Donald Knuth (5) ETL (5) NVIDIA (5) REST (5) bash (5) flash (5) keyboard (5) price (5) samba (5) CGI (4) LISP (4) RoR (4) cache (4) display (4) holywar (4) nginx (4) pistol (4) xml (4) Лебедев (4) IDE (3) IE8 (3) J2EE (3) NTFS (3) RDP (3) USA (3) mount (3) spark (3) Гоблин (3) кухня (3) урюк (3) AMQP (2) ERP (2) IE7 (2) NAS (2) Naudoc (2) PDF (2) address (2) air (2) british (2) coffee (2) font (2) ftp (2) holiday (2) messaging (2) notify (2) sharepoint (2) ssl/tls (2) stardict (2) tests (2) tunnel (2) udev (2) APT (1) CRUD (1) Canyonlands (1) Cyprus (1) DVDShrink (1) Jabber (1) K9Copy (1) Matlab (1) Palanga (1) Portugal (1) VBA (1) WD My Book (1) autoit (1) bike (1) cannabis (1) chat (1) concurrent (1) dbf (1) ext4 (1) idioten (1) krusader (1) license (1) mindmap (1) pneumatic weapon (1) quiz (1) regexp (1) robot (1) science (1) serialization (1) tie (1) vim (1) Науру (1) крысы (1) налоги (1) пианино (1)

Google+ Followers