HELP! Мультисредовое приложение на двух процессорном компе. (гипотезы, мнения, )

yeziz 03.03.2004 - 11:17 | Привет, ув. All! Проблема: есть некий мультисредовый сервер. На одном процессоре прогон некоторого теста занимает 9 минут. На двух процессорах на (том же компутере) - 25 минут. :-( Я понимаю, что если прога корявая, то выигрыша может не получиться или он будет мизерным, но чтоб так... Слышал, что подобная проблема была с Exchange Server-ом: там тоже при переходе с 4-х процессоров на 8 наблюдалось падение производительности, но в чем причина - не знаю. Если кто сталкивался/читал/знает хоть что-нибудь - подскажите. Знать бы хоть - куда рыть. Гипотезы, даже неподтвержденные, тож принимаются. Да, все это работает под 2000-ным. Заранее спасибо.
Delphist 1 - 03.03.2004 - 14:17 | Реального опыта с многопроцессорными системами не имею, потому говорю лишь гипотезы. Если приложение мультипоточное (multi-thread), то проблемы могут быть 1) проблемы на уровне ОС (решаются свежими патчами, тут поможет www.microsoft.com) 2) проблемы в синхронизации потоков. Тут подробнее опиши модель твоей программы: на чем написана, применяемые технологии, средства синхронизации и т.п. 3) попробуй отключить HyperThreading (если у тебя P4)
девочка на шару 2 - 03.03.2004 - 14:20 | гипотезы: криво спроектирована синхронизация потоков и не менее криво спроектировано тестирование возьмите нормальный профайлер, сравните на разных машинах. он вам сам покажет, в каких местах затыки
yeziz 3 - 03.03.2004 - 18:13 | Проектировано не то, чтоб криво, а просто никак. Коду много лет. Переделывали что только можно и из чего только можно. Проблема в том, что необъяснимо именно соотношение: 3-хкратное превышение времени выполнения на двух процессорах по сравнению с одним. 2 Delphist: HyperThreading отключен, с ним - еще хуже (хотя должно быть - еще лучше :-)). Патчи свеженькие, бо Windows Update молотит он-лайн. Программа написана на Це++. Это сервис, который ловит из шаред мемори данные от веб-сервера, берет из пула сред и запускает обработку, включая обращение к БД и мэйнфрейму. Мест для затычки - уйма, это я понимаю. Но я не понимаю, как производительность может упасть в 3 раза. Объяснимо неулучшение (если потоки выполняются последовательно, сериализуются), объяснимо даже некоторое ухудшение - за счет переключения контекстов, но ухудшение...
yeziz 4 - 03.03.2004 - 18:17 | 2 девочка: а профайлер вносит такой "шум", что все рассинхронизируется и затыки пропадают...
VaS 5 - 03.03.2004 - 21:42 | Проследи времена ожиданий объектов синхронизации (именованно, логом).
Delphist 6 - 03.03.2004 - 22:56 | Совет дурацкий, но другого я не вижу: если коду много лет, изначально не предполагал многопоточность и он латан-перелатан с учетом все возраставших требований, НАПИШИ ВСЮ ЗАДАЧУ ЗАНОВО имхо, больше времени уйдет на лазание по тексту с отладчиком в руках, чем перепроектировать задачу по-уму и написать набело.
yeziz 7 - 04.03.2004 - 11:13 | 2 Delphist: Так и делаю. Только та версия, на которой проблемы, уже у заказчиков, потому чинить надо и старый код тоже. Кроме того, переписать ВСЕ сначала практически нереально (никто уже точно не знает, что там должно быть :-)), только по кусочкам. Писан он был еще для вин 3.х... 2 VaS: пытаюсь это сделать, но их там, как собак нерезаных. Кроме того, есть еще (просто обязаны быть) конфликты с аллокациями и освобождением памяти, бо с памятью тут не церемонятся: цикл работы одного юзверя - ок. 100 000 аллокаций... :-(, да переключение контекстов. Потому и пытался найти версию, которая бы показала хоть сколько-нибудь оптимальное направление поисков. Опять таки: объекты ожидания - это последовательное (в худшем случае) выполнение потоков. В этом случае, производительность была бы, максимум, чуть хуже, чем на одном процессоре.
VaS 8 - 04.03.2004 - 17:21 | Сделай статистику по ниткам - сколько времени каждая находилась в том или ином состоянии (работа, ожидание, сон). Для этого надо будет вставить кучу кода перед/после ожиданий и слипов. Возможно сразу увидишь, что какая-то нитка почти постоянно ждет других. С увеличением числа процессоров другие нитки все чаще будут захватывать нужный тормозящей нитке объект. Попробуй разделить блокировки на запись и чтение (в случаях, когда мало ниток пишут, но много - читают).
Delphist 9 - 04.03.2004 - 17:57 | yeziz, я прекрасно тебя понимаю. Попробуй убедить заказчика, что перепланировка задачи просто необходима. Особенно напирай на начало win 3.х. Это как пытаться перетащить водительское кресло от велосипеда в Запорожец, потом в Жигули, далее в Мерседес. Это же нереально. Само сабой, они будут зажимать деньги за новую разработку. Классическая проблема, когда на технику выбрасывается куча баксов и абсолютно не учитывается вопрос приобретения софта.
Delphist 10 - 04.03.2004 - 18:12 | ! Прочитал еще раз про аллокации и вспомнил. РЕЗКОЕ падение скорости, убежден, связано с неэффективной работой родного менеджера памяти Windows. Ибо только один процессор может получить одновременный доступ к пулу памяти, второй процессор ждет. Учитывая, что аллокаций около 100 тысяч, тут и получаешь падение на 25 минут. Загляни на http://www.microquill.com/ - если не врут, скорость вырастет в 4-5 раз. Если повезет, переписывание сведется к перекомпиляции с новыми библиотеками.
yeziz 11 - 04.03.2004 - 19:00 | 2 VaS: Попробую, но это малореально, слищком много кода в каждом срэде, слишком часто меняется картинка. Я тут подхватил интеловскую утилитку для проверки перфоманса (VTuneT Analyzer 7.1). К ней есть плагин, который проверяет срэды (Thread Checker). Она мне выдала кучу ошибок типа одновременной записи в одну область памяти. Мои бывшие (а частью, и нынешние) коллеги злоупотребляли stl-ем, в частности, его мап-ом, а он, как выяснилось, не срэд-сейфовый... :-( И сколько еще таких сюрпризов... 2 Delphist: спасибо за адрес. Я сейчас глянул - хип агент точно пригодится, а вот переходить на их библиотеку - поостерегусь. Проблема в том, что нормальное приложение (тот же Exchange) работает ведь на Виндовсе с его виндовским менеджером памяти. Так что, видимо, аллокации замедляют работу (это-то бесспорно), но вот причина ли это такого фатального замедления... В любом случае, должно быть не хуже (или чуть хуже), чем на 1 камне. Причина, видимо, глубже. Опять же, перекомпилировать эту туеву хучу кода с новыми библиотеками - разоришься на тестировании :-))). Ладушки. Всем - огромное спасибо! Буду рыть дальше. Если скинете мыло (мое - под ником), то об исполнении (результатах) доложу всем заинтересованным. :-)))
Э-эх 12 - 04.03.2004 - 21:40 | Думаю, причина замедления работы при использовании двух процессоров, в данном случае, в том, что из нескольких потоков происходят изменения одной и той же области памяти. Ведь если один поток (исполняющийся на одном процессоре) меняет какой-то блок памяти, а другой поток (исполняющийся на другом процессоре) читает этот же блок, второму процессору приходится инвалидейтить свой кеш и "переливать" блок из кеша другого проца в свой. Очевидно, что это операция не самая быстрая. Когда же оба потока исполняются на одном проце (конечно, в каждый момент времени исполняется только один из них), кеш используется в полную силу. В этом плане, использование HT на одном проце может дать некоторый прирост производительности (по крайней мере, такого сильного ухудчшения быть не должно), т.к. кеш у него общий для обоих "виртуальных процессоров".
yeziz 13 - 07.03.2004 - 12:20 | 2 Э-эх: Т.е., как только я пытаюсь работать с общей областью памяти (или другим общим ресурсом) на многопроцессорной машине, я неизбежно получаю замедление? Звучит странновато, хотя и объясняет замедление. С другой стороны, работа с общими ресурсами, как правило, занимает достаточно малую часть flow. Как правило, основная работа, все-таки, ведется с локальными (необщими) ресурсами.
yeziz 14 - 10.03.2004 - 12:48 | РЕЗЮМЕ: использование функции _set_sbh_threshold приводит к ПАДЕНИЮ (в моем случае более, чем в 2 раза) производительности на многопроцессорной машине. Отказавшись от специфической поддержки аллокации малых блоков получили рост процентов на 25 (4 мин - время работы теста на 2-х процессорах, 2 - мин - на 1-ом, 1 мин 35 сек - на 2-х после отказа от _set_sbh_threshold). Всем спасибо!

>>