Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| | | | |
виртуальной 14.12.07 14:28 Число просмотров: 3713
Автор: Cyril <sc> Статус: Member
|
> > > Это я могу сказать и без счетчиков: 100% загрузка
> > > процессора,
> > Одного процессора или обоих, т.е. используется ли
> реально
> Обоих. Автокад неплохо знаком с многопроцессорностью.
> > второй процессор
> > при работе?
> > непрерывный своп при открытии файла (минут на
> > > 5), то же самое при маштабировании и отправке на
> > печать
> > > (тут задумчивость может продолжаться до 40
> минут).
> > После открытия файлов какой объем памяти в итоге
> занимает
> > приложение,
> Физической - точно не скажу, но примерно гиг с небольшим.
виртуальной
> > эти данные хотя бы дали возможность оценить
> необходимый
> > объем ОЗУ,
> > файлы содержащие вектрорные данные как правило имеют
> не
> > очень большой объем,
> Дело в том, что там не только вектора, но и растры. Опять
какого формата растры, сколько загружаемые растры занимают
места на диске, если речь идет о растровой подложке типа генплана
то какое разрешение используется, можно ли его понизить,
сколько бит на точку растра используется?
Провести опыт, отключить растровую подложку из проекта и посмотреть
на сколько измениться время загрузки
> же, векторны е данные при отображении растеризуются.
> > хотя допускаю что могут быть исключения, видимо у Вас
> какие
> > то спецефические
> > задачи, может расскажете поподробнее
> > Мне кажется, что сначала надо найти "узкие" места как
> в
> Нехватка оперативной памяти, недостаточная
> производительность дисковой подсистемы, недостаточная
> производительность процессоров.
> Первое видимо основное.
> > аппаратном обеспечении, так и программном и только
> потом
> > искать какое то более производительное железо или
> софт.
> > Imho Всегда можно найти задачу на которой загнется
> любая
> > вычислительная машина
|
|
<hardware>
|
Коллективный разум, помоги, плз! :) Нужно сконфигурировать очень производительную рабочую станцию-числогрыз. Я в затруднении. 06.12.07 21:58
Автор: Fighter <Vladimir> Статус: Elderman
|
|
Назначяение - обработка подробных геоданных для большой территории. Классические типа навороченные конфигурации (топовые 2-4 ядра Интел, 2-4(реально - 3)Гб ОЗУ, топовые матеря, быстрые райды (видимо SATA), ВыньХР) просто вешаются вместе с поставщиками. Поделился тем, что знаю. Что посоветовать хорошим людям? Восмипроцессорную систему с серверной виндой + 32Гб ОЗУ и SAS дисками? Или есть другие варианты? Линух желательно не придлагать там не та ситуация :)
|
|
Есть буфер по времени? Поставить счетчики производительности и посмотреть куда "упирается" приложение. Не может же оно нагружать все подсистемы :) 11.12.07 19:13
Автор: Garick <Yuriy> Статус: Elderman
|
|
|
| |
Это я могу сказать и без счетчиков: 100% загрузка... 11.12.07 20:16
Автор: Fighter <Vladimir> Статус: Elderman
|
|
Это я могу сказать и без счетчиков: 100% загрузка процессора, непрерывный своп при открытии файла (минут на 5), то же самое при маштабировании и отправке на печать (тут задумчивость может продолжаться до 40 минут).
|
| | |
Одного процессора или обоих, т.е. используется ли реально... 13.12.07 17:08
Автор: Cyril <sc> Статус: Member
|
> Это я могу сказать и без счетчиков: 100% загрузка
> процессора,
Одного процессора или обоих, т.е. используется ли реально второй процессор
при работе?
непрерывный своп при открытии файла (минут на
> 5), то же самое при маштабировании и отправке на печать
> (тут задумчивость может продолжаться до 40 минут).
После открытия файлов какой объем памяти в итоге занимает приложение,
эти данные хотя бы дали возможность оценить необходимый объем ОЗУ,
файлы содержащие вектрорные данные как правило имеют не очень большой объем,
хотя допускаю что могут быть исключения, видимо у Вас какие то спецефические
задачи, может расскажете поподробнее
Мне кажется, что сначала надо найти "узкие" места как в аппаратном обеспечении, так и программном и только потом искать какое то более производительное железо или софт.
Imho Всегда можно найти задачу на которой загнется любая вычислительная машина
|
| | | |
Обоих. Автокад неплохо знаком с многопроцессорностью. 13.12.07 18:01
Автор: Fighter <Vladimir> Статус: Elderman
|
> > Это я могу сказать и без счетчиков: 100% загрузка
> > процессора,
> Одного процессора или обоих, т.е. используется ли реально
Обоих. Автокад неплохо знаком с многопроцессорностью.
> второй процессор
> при работе?
> непрерывный своп при открытии файла (минут на
> > 5), то же самое при маштабировании и отправке на
> печать
> > (тут задумчивость может продолжаться до 40 минут).
> После открытия файлов какой объем памяти в итоге занимает
> приложение,
Физической - точно не скажу, но примерно гиг с небольшим.
> эти данные хотя бы дали возможность оценить необходимый
> объем ОЗУ,
> файлы содержащие вектрорные данные как правило имеют не
> очень большой объем,
Дело в том, что там не только вектора, но и растры. Опять же, векторны е данные при отображении растеризуются.
> хотя допускаю что могут быть исключения, видимо у Вас какие
> то спецефические
> задачи, может расскажете поподробнее
> Мне кажется, что сначала надо найти "узкие" места как в
Нехватка оперативной памяти, недостаточная производительность дисковой подсистемы, недостаточная производительность процессоров.
Первое видимо основное.
> аппаратном обеспечении, так и программном и только потом
> искать какое то более производительное железо или софт.
> Imho Всегда можно найти задачу на которой загнется любая
> вычислительная машина
|
| | | | |
виртуальной 14.12.07 14:28
Автор: Cyril <sc> Статус: Member
|
> > > Это я могу сказать и без счетчиков: 100% загрузка
> > > процессора,
> > Одного процессора или обоих, т.е. используется ли
> реально
> Обоих. Автокад неплохо знаком с многопроцессорностью.
> > второй процессор
> > при работе?
> > непрерывный своп при открытии файла (минут на
> > > 5), то же самое при маштабировании и отправке на
> > печать
> > > (тут задумчивость может продолжаться до 40
> минут).
> > После открытия файлов какой объем памяти в итоге
> занимает
> > приложение,
> Физической - точно не скажу, но примерно гиг с небольшим.
виртуальной
> > эти данные хотя бы дали возможность оценить
> необходимый
> > объем ОЗУ,
> > файлы содержащие вектрорные данные как правило имеют
> не
> > очень большой объем,
> Дело в том, что там не только вектора, но и растры. Опять
какого формата растры, сколько загружаемые растры занимают
места на диске, если речь идет о растровой подложке типа генплана
то какое разрешение используется, можно ли его понизить,
сколько бит на точку растра используется?
Провести опыт, отключить растровую подложку из проекта и посмотреть
на сколько измениться время загрузки
> же, векторны е данные при отображении растеризуются.
> > хотя допускаю что могут быть исключения, видимо у Вас
> какие
> > то спецефические
> > задачи, может расскажете поподробнее
> > Мне кажется, что сначала надо найти "узкие" места как
> в
> Нехватка оперативной памяти, недостаточная
> производительность дисковой подсистемы, недостаточная
> производительность процессоров.
> Первое видимо основное.
> > аппаратном обеспечении, так и программном и только
> потом
> > искать какое то более производительное железо или
> софт.
> > Imho Всегда можно найти задачу на которой загнется
> любая
> > вычислительная машина
|
| | | | |
Дельный (универсальный) совет: Если вы считаете, что в вашем... 13.12.07 18:53
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 13.12.07 18:54 Количество правок: 1
|
> Нехватка оперативной памяти, недостаточная
> производительность дисковой подсистемы, недостаточная
> производительность процессоров.
> Первое видимо основное.
Дельный (универсальный) совет: Если вы считаете, что в вашем компе какая-то железяка (проц/память/диски/видяха/...) сильно тормозит вашу работу/программу/базу/игрушку/..., то прежде чем бежать и покупать что-либо дорогое для апгрейда, сначала возмите эту железяку у знакомого/соседа/друга/... на время поиграться, померить прирост производительности, чтобы точно определиться с тем, что именно и с какими характеристиками вам все-таки нужно.
Тем самым можно избавится от неправильных дорогостоящих решений. Например вы заметили, что в процессе тормозной работы винчестер проявляет неистовую активность и возжелаете заменить именно его на более быстрый, что может дать слишком незначительный прирост производительности, по сравнению с увеличением оперативной памяти. Если задаче нехватает памяти и она интенсивно свапуется, то увеличив объем оперативки до такого, что задаче его начнет хватать, уверяю, программа "полетит"!
Можно взять прогу с данными, прийти к другу (если у него многопроцовый суперкомп с огромной оперативкой) в гости, запустить тестовую задачу и померить прирост производительности.
Если друзей с суперкомпами нет, то берем комп, идем в магазин, объясняем причину продавцу, просим, чтоб он дал распоряжение технарям взять память со склада, втыкнуть ее в ваш комп, запустить прогу, и если эффект будет, то вы сразу же расчитаетесь за память.
|
| | | | | |
Серверные компании могут предоставить сервера и воркстатион на испытания на неделю -другую. 13.12.07 22:22
Автор: Garick <Yuriy> Статус: Elderman
|
|
|
| | | | | | |
А кто у нас этим занимается? Если можно - парочку названий, плз. 14.12.07 14:41
Автор: Fighter <Vladimir> Статус: Elderman
|
|
|
| | | | | |
Совет действительно дельный. Не спорю. Тем более, что я сам такие советы регулярно даю. 13.12.07 19:55
Автор: Fighter <Vladimir> Статус: Elderman
|
|
Но в корневом посте и далее описана ситуация в которой оказались люди благодаря комп. мальчикам с блатными родственниками. Топовые бытовые конфигурации (тупо слизанные с пресс-релизов) не справляются за требуемое время, что вобщем-то логично. Народ желает, чтобы описаные задачи выполнялись немного медленее открытия Блокнота (утрирую конечно). Можно конечно предложить им дофигапроизводительный кластер или послать подальше, но не хотелеось бы подводить народ.
|
| | | | | | |
А чудес не бывает. Если прога требует кластер, то на... 14.12.07 10:26
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
|
> Но в корневом посте и далее описана ситуация в которой
> оказались люди благодаря комп. мальчикам с блатными
> родственниками. Топовые бытовые конфигурации (тупо
> слизанные с пресс-релизов) не справляются за требуемое
> время, что вобщем-то логично. Народ желает, чтобы описаные
> задачи выполнялись немного медленее открытия Блокнота
А чудес не бывает. Если прога требует кластер, то на обычном, да и на топовом тоже, она не полетит.
Давай еще уточним, если эксперименты не ставились, то поставить их надо обязательно. Взять тестовую задачу и попробовать ее прогнать на одном и том же компе, но второй раз програть, выдернув половину из установленных процессоров, а третий раз, выдернув половину из установленных модулей памяти и каждый раз замерив время.
> (утрирую конечно). Можно конечно предложить им
> дофигапроизводительный кластер или послать подальше, но не
> хотелеось бы подводить народ.
Поставив эксперименты можно будет точно сказать, с какой скоростью она будет работать на каждой конфигурации из чего можно сделать вывод - какая конфигурация нужна для того, чтоб она летала как Блокнот.
|
| | | | | | | |
"А чудес не бывает. Если прога требует кластер..." А бывают рабочие станции в кластерах? Не встречал:) И если приложение десктопное - значит без кластера. Хотя, возможно терминалится, но КАДы тяжело терминалятся. Возможно, существуют терминальные версии. 14.12.07 17:16
Автор: Garick <Yuriy> Статус: Elderman
|
|
|
| | | | | | | |
Вот конфигурация, которая их не устроила: 14.12.07 14:34
Автор: Fighter <Vladimir> Статус: Elderman
Отредактировано 14.12.07 14:38 Количество правок: 1
|
|
Q6700, Samsung 401LJ, 4Gb 1066, Asus P5K-WS Pro, 8800GTX(?), WinXP (которая больше 3 Гб не использует). Интересно было бы услышать следующую конфигурацию для эксперимента.
|
| | | | | | | | |
32 битная действительно не использует более 3-х Гб [upd] 14.12.07 17:51
Автор: Den <Денис Т.> Статус: The Elderman
Отредактировано 14.12.07 19:26 Количество правок: 2
|
Последний гиг 32-битная XP резервирует под свои функции.
Не думаю, что мощная видяха дает сильный прирост производительности на AutoCAD. Вполне подошла бы и менее производительная и более дешевая.
Какие процы использовались?
Одноядерные системы очень плохо справляются с каким-либо рендерингом. Проверено!
И даже хороший Core2 DUO дает заметный прирост производительности.
Если 32-битной проге не хватает памяти, а порог уже достигнут, то остается два выхода:
1. Купить 64-битный софт и подходящую платформу (железо, ОС)
2. Собрать SATA/SAS диск на динамической RAM
ИМХО, первое проще.
Вполне возможно, что высокая активность ЖД совсем не из-за свопинга, а из-за особенностей используемого софта. Если так, тогда на машинке, где происходит рендеринг, под кеш данных софта, а также под своп ОС можно использовать RAID 0 (чередование) на SAS (пара - тройка винтов). Это должно заметно ускорить дисковые операции с кешем данных софта.
|
| | | | | | | | | |
Q6700 - четырехъядерник. 15.12.07 02:35
Автор: Fighter <Vladimir> Статус: Elderman
|
> Последний гиг 32-битная XP резервирует под свои функции.
>
> Не думаю, что мощная видяха дает сильный прирост
> производительности на AutoCAD. Вполне подошла бы и менее
> производительная и более дешевая.
>
> Какие процы использовались?
> Одноядерные системы очень плохо справляются с каким-либо
> рендерингом. Проверено!
> И даже хороший Core2 DUO дает заметный прирост
> производительности.
Q6700 - четырехъядерник.
>
> Если 32-битной проге не хватает памяти, а порог уже
> достигнут, то остается два выхода:
> 1. Купить 64-битный софт и подходящую платформу (железо,
> ОС)
> 2. Собрать SATA/SAS диск на динамической RAM
Это как? Точнее "SATA/SAS диск на динамической RAM" это что? Виртуальный диск?
> ИМХО, первое проще.
>
> Вполне возможно, что высокая активность ЖД совсем не из-за
> свопинга, а из-за особенностей используемого софта. Если
> так, тогда на машинке, где происходит рендеринг, под кеш
> данных софта, а также под своп ОС можно использовать RAID 0
> (чередование) на SAS (пара - тройка винтов). Это должно
> заметно ускорить дисковые операции с кешем данных софта.
|
| | | | | | | | |
Нужно только двухпроцессорную плату и второй такой же... 14.12.07 16:35
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 14.12.07 17:00 Количество правок: 2
|
> Q6700, Samsung 401LJ, 4Gb 1066, Asus P5K-WS Pro,
> 8800GTX(?), WinXP (которая больше 3 Гб не использует).
> Интересно было бы услышать следующую конфигурацию для
> эксперимента.
Нужно только двухпроцессорную плату и второй такой же процессор.
Желательно еще несколько аналогичных (не обязательно таких же винтов), штуки три.
Если время обчсета тестового задания будет отличаться ровно в два раза при двух почти равных условиях, только в первом случае будет два процессора, а во втором один. Вывод можно будет сделать однозначный - во сколько раз больше процов, во столько раз быстрее будет считать.
Идея понятна?
Данный экасперимент с процессорами можно ставить только в одном случае, если на исходной системе загрузка процессора более 25%. То есть задача умеет параллелится, а Q6700, насколько я понял четырехядерный.
Далее можно уменьшать память до 2Гб, до 1Гб, ... При такого рода экспериментах возможно развитие процесса тестирования по двум направлениям. 1- Задача постепенно начент тормозить по мере уменьшения памяти и 2- задача резко начнет тормозить при уменьшении памяти ниже границы определенного объема или вообще сообщит о том, что ей не хватает памяти. В последнем случае эксперименты с памятью можно уже не проводить, иначе задуматься о 8-16 мегабайтной системе, особенно если прирост скорости будет пропорционален объему оперативки.
Увеличивание же памяти свыше 4Гб вероятнее всего не имеет смысла, поскольку маловероятно, что задача сможет работать с объемом памяти более 4Гб - разрядность не позволит.
Последний эксперимент с дисками. Этот эксперимент имеет смысл проводить, если в процессе работы программы идет интенсивный обмен с диском. Строим из дисков массив RAID-0 сначала из двух, потом из трех, потом из четырех. На этот массив выкладываем данные, своп и каталог временных файлов. Если на двухдисковом массиве задача будет работать почти в два раза быстрее, а на четырехдисковом в четыре, то надо задуматься о восьми-шестнадцатидисковом массиве. Если же прирост скорости будет отсутствовать или составлять 1-5%, то о дисках вообще задумываться не следует.
Эксперименты с памятью можно провести и на существующей конфигурации.
Эксперименты с дисками можно вообще не проводить, а померить объем записаных/считаных данных во время работы программы и разделить на время ее работы. Тем самым получим среднюю скорость. Если эта скорость не выйдет за пределы 1-3 мегабайт в секунду, то продолжать эксперименты с дисками не имееет смысла. Если он превысит 8-10 мегабайт в секунду, то дискам следует уделить особое внимание и начать эксперименты с RAID-0 в первую очередь.
|
| | | | | | | | | |
Понял, не дурак. Только эксперимент дороговатый получится. 15.12.07 02:42
Автор: Fighter <Vladimir> Статус: Elderman
|
> > Q6700, Samsung 401LJ, 4Gb 1066, Asus P5K-WS Pro,
> > 8800GTX(?), WinXP (которая больше 3 Гб не использует).
> > Интересно было бы услышать следующую конфигурацию для
> > эксперимента.
> Нужно только двухпроцессорную плату и второй такой же
> процессор.
> Желательно еще несколько аналогичных (не обязательно таких
> же винтов), штуки три.
> Если время обчсета тестового задания будет отличаться ровно
> в два раза при двух почти равных условиях, только в первом
> случае будет два процессора, а во втором один. Вывод можно
> будет сделать однозначный - во сколько раз больше процов,
> во столько раз быстрее будет считать.
> Идея понятна?
Понял, не дурак. Только эксперимент дороговатый получится.
> Данный экасперимент с процессорами можно ставить только в
> одном случае, если на исходной системе загрузка процессора
> более 25%. То есть задача умеет параллелится, а Q6700,
> насколько я понял четырехядерный.
> Далее можно уменьшать память до 2Гб, до 1Гб, ... При такого
> рода экспериментах возможно развитие процесса тестирования
> по двум направлениям. 1- Задача постепенно начент тормозить
> по мере уменьшения памяти и 2- задача резко начнет
> тормозить при уменьшении памяти ниже границы определенного
> объема или вообще сообщит о том, что ей не хватает памяти.
> В последнем случае эксперименты с памятью можно уже не
> проводить, иначе задуматься о 8-16 мегабайтной системе,
8-16 Гб?
> особенно если прирост скорости будет пропорционален объему
> оперативки.
> Увеличивание же памяти свыше 4Гб вероятнее всего не имеет
> смысла, поскольку маловероятно, что задача сможет работать
> с объемом памяти более 4Гб - разрядность не позволит.
Видимо смысл есть, но при использовании серверной или 64-разрядной ОСи. Опять же, противоречее с написаным выше.
> Последний эксперимент с дисками. Этот эксперимент имеет
> смысл проводить, если в процессе работы программы идет
> интенсивный обмен с диском. Строим из дисков массив RAID-0
> сначала из двух, потом из трех, потом из четырех. На этот
> массив выкладываем данные, своп и каталог временных файлов.
> Если на двухдисковом массиве задача будет работать почти в
> два раза быстрее, а на четырехдисковом в четыре, то надо
> задуматься о восьми-шестнадцатидисковом массиве. Если же
> прирост скорости будет отсутствовать или составлять 1-5%,
> то о дисках вообще задумываться не следует.
> Эксперименты с памятью можно провести и на существующей
> конфигурации.
> Эксперименты с дисками можно вообще не проводить, а
> померить объем записаных/считаных данных во время работы
> программы и разделить на время ее работы. Тем самым получим
> среднюю скорость. Если эта скорость не выйдет за пределы
> 1-3 мегабайт в секунду, то продолжать эксперименты с
> дисками не имееет смысла. Если он превысит 8-10 мегабайт в
> секунду, то дискам следует уделить особое внимание и начать
> эксперименты с RAID-0 в первую очередь.
Ок, в понедельник съезжу, погляжу.
|
| | | | | | | | | | |
Я не сомневаюсь, но действенное и недорогое решение может... 15.12.07 14:28
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 15.12.07 14:40 Количество правок: 6
|
> > Идея понятна?
> Понял, не дурак. Только эксперимент дороговатый получится.
> > В последнем случае эксперименты с памятью можно уже не
> > проводить, иначе задуматься о 8-16 мегабайтной
> системе,
> 8-16 Гб?
> Ок, в понедельник съезжу, погляжу.
Я не сомневаюсь, но действенное и недорогое решение может быть неочевидно. С одной стороны парадокс - применение 8-16 мегов памяти покажется бессмысленено при 32 разрядной задачи (а задачи таковы, я не сомневаюсь). С другой стороны, если изменение объема оперативки плавно меняет производительность, значит для самой задачи хватает маленького объема, а оперативка используется для кеширования огромного объема данных на диске, которые прога постоянно дергает при рабте. Установив море памяти (что не очень дорого) можно превзайти критическую границу, когда все данные с диска кешанутся в оперативке и программа заметно полетит. Для этого и операционку надо будет поменять на 64 разрядную, а программу совсем не обязательно, поскольку 32 разрядные проги без проблем работают под 64 разрядными операционками (но не наоборот).
|
| | |
Я так понимаю - это рабочие места, а не сервера? Тогда надо смотреть в сторону вокрсташинов на кзеонах. 11.12.07 23:31
Автор: Garick <Yuriy> Статус: Elderman
|
|
|
| | | |
Именно РМ. А что за АРМы на зионах? Просто никогда не сталкивался. 12.12.07 15:33
Автор: Fighter <Vladimir> Статус: Elderman
|
|
|
|
|
подробно о проекте
Анализ криптографических сетевых...
