Проверка программ на живучесть...

[Aleck D.Shadow]

, и корректную работу в режиме нехватки ресурсов.

Интересует следующее:
Существуют ли тестирующие программы, которые, например, делают очень частое обращение к диску,
или занимают на 100% процессор в случайные моменты времени или постоянно и т.п. ?

[Алексей++]

Aleck D.Shadow, так сделай сам )  Особенно с 100% процессора - без проблем сделать

например

Код:

main(/*...*/) // не знаю, что тут пишется ))
{
 for(int i=0;i<100000;i++)
 {
  DWORD dwdRANDOM_PAUSE=...;
  DWORD dwdRANDOM_N=...;
  int iii;
  for(;dwdRANDOM_N;dwdRANDOM_N--){iii=iii*iii}; //100%
  Sleep(dwdRANDOM_PAUSE);//пауза случайная
 }
return 0;
}

[Aleck D.Shadow]

Это то без проблем, просто я думал что существуют какие нибудь тесты для
проверки. А-ля Driver Verifier, но для программ.

[Scorp__)]

Как я понял, целых решений стресс-тестов не бывает. Или я их не нашел. Но можно найти утилиты россыпью. Например утилита Mem Eat ест память. CPU Burner грузит процессор. Для диска не нашел...

Обычно стресс-тесты используются для определения устойчивости железа, но некоторые можно приспособить и для проверки устойчивости своей программы. Вот здесь http://www.benchmarkhq.ru/russian.html?/b_cpu.html есть подборка, но там далеко не все будет тебе полезно.

[nikedeforest]

Разрешите такой дилетантский вопрос. А есть ли смысл в таком тестировании ПО. По идеи все ресурсы в системе распределяет сама ОС. Т.е. получается, что тестируем-то мы ОС в данном случае. Да и к тому же, как программа отреагирует на длительную загрузку ЦП или винчестера? Да никак! Программа в течении работы неоднократно получает ресурс и опять отдает, спустя квант времени. Так какая же разница от того, что квант будет не наносекунды, а секунды, к примеру?

[Алексей++]

nikedeforest, если программа работает , скажем , с портом или сокетом, разницу заметно будет имхо

[nikedeforest]

С этим, уже поспорить тяжелее

[Dimka]

Писать программу нужно с учётом приоритетов. Так, чтобы критические по производительности части ОС не откладывала в долгий ящик. При этом если нагрузку CPU создаёт своя программа, то придётся её параллелить. Часто возникает вопрос разработки более эффективных алгоритмов и требуемых структур данных для них.

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

Это одно уравнение, только в каждом случае в качестве неизвестного берутся разные его части.

[Aleck D.Shadow]

To Scorp__):
Спасибо, посмотрим.

To Nikedeforest:
Если программа работает 24 часа в сутки, и 7 дней в неделю, то мне бы очень хотелось знать как себя ведет программа,
в случаях критических для системы в целом. Ведь срабатывают разного рода таймауты, а это значит программа должна самостоятельно восстановить соединение, или заново инициализироваться, при этом умудриться не допустить утечек, и прочего
сопутствующего добра.

To Dimka:
Согласен.

[Алексей++]

Aleck D.Shadow, кстати, ты не один с такой прогой  ) Я тоже пишу и поддерживаю программу, которая должна работать круглый год (в теории) и вроде даже работает )

[Aleck D.Shadow]

Aleck D.Shadow, кстати, ты не один с такой прогой  ) Я тоже пишу и поддерживаю программу, которая должна работать круглый год (в теории) и вроде даже работает )

Всё зависит от сложности её работы (не программирования!) связь с БД, сбор данных, исп.протоколы и т.п.

[Sla]

Как-то очень тяжело понять "нехватка ресурсов" на технологической машине.
Если есть нехватка => неправильно построена схема процесса.
Самый простой способ, и возможно, наиболее оптимальный, с точки зрения цена/надежность, разделение технологических задач на разные машины, соответсвенно оценив использование общих ресурсов, таких как сеть, базы данных, а тем более, если задачи на одной машинке, доступ к дисковым опреациям.
Обслуживание/стоимость/надежность - на разделенных процессах, читай машинах, выше.
Конечно, доказать это руководству/заказчику, задача не из легких.

Offtopic:

Вопрос к людям которые эту тему читают
Как часто в своей практике используют технологические машины?
И как к этому вопросу относится руководство/заказчик?

Под это можно и темку спецательно открыть, с опросом

[Алексей++]

Aleck D.Shadow, есть база, есть много инфы с порта и из сети ) Всё непрерывно сохраняется в базу, часть бызы сохраняется в файлы, дабы не замусоривать. Короче ещё та сказка )))

[Scorp__)]

Sla, а что ты имеешь в виду под технологической машиной?
Распределенную систему труднее контролировать, так что утверждение, насчет надежности не бесспорно. К тому же не решает всех проблем. Пример: перегрузка сети, как ни разделяй рабочие процессы - это внешний фактор. Вот еще один: если ОС не реального времени, то возможен interrupt flood от неисправного устройства, который сожрет все процессорное время.

[Sla]

Scorp__), есть задачи и есть задачи,
Зачем на "технологической машине", неисправное устройство? (неисправное устройство и в ОСРВ также принесет немало хлопот)
Зачем "технологическую машину" включать в перегруженную сеть?

Если уж возникает вопрос достоверности обработки или доставки, то соответственно, требуются протоколы, гарантирующие доставку/обработку.

И вообще, о чем речь?
Вопрос  звучал: Проверка на живучесть при нехватке ресурсов
Т.е заведомо ввести машинку в такой режим, но здесь ты вроде и сам дал ответ.
Готовых инструментов, под все твои желания, вряд-ли найдется, а если и найдется - то будет стоить определенных много-много убиенных енотов.

Я знаю, что такое нехватка ресурсов, что такое зависшие процессы, необработанные транзакции, неотправленные отчеты (упс, это уже из другой серии). Есть собственные методы борьбы с этим.

Из личного опыта
Ввод девайса в стресс - обязательное условие тестирования
Ввод системы (программы) в стресс - перегрузка запросами, проверка реакции на прерывания и т.д.
До тестирования ОС руки не доходили, хотя когда-то чего-то пытались сделать, но потом поняли, что скорее нам это не нужно.

Хотелось бы спросить у Михалыча, у него есть опыт работы с QNX, как QNX успевает обработать такое большое количество прерываний и при этом не умереть?

[Scorp__)]

Sla, погоди, я не очень понимаю твой термин. Вот машина рабочего места оператора в танке, это технологическая машина или нет? Там возможен просто выход устройства из строя в процессе эксплуатации, при этом необходимо, чтобы ПО не грохнулось, и вся система продолжала бы работать, пусть и с ограничениями. Но сначала все это хозяйство собирается на стенде, который не трясет, он никуда не едет и вообще живет в тепличных условиях. То есть при работе на стенде ПО будет показывать себя отлично, а в боевой работе может грохнуться, если его не проверить.

Ааа, я понял, ты имел в виду, что, как может быть постоянная нехватка ресурсов в системе. Такого, конечно быть не должно, но речь то шла именно про стресс-тестирование, просто не было именно этого термина. Кстати, бывает и постоянная нехватка ресурсов, когда архитектор в самом начале наплевал на тщательный выбор параметров системы и запаса "прочности". Мы, как правило, сталкиваемся с недостаточной пропускной способностью канала. При этом: "никто ничего переделывать не будет", а виновато в конечном итоге получается ПО Или вот перетирающиеся флешки, тоже хороший вариант

[sss]

cpustress.exe из Platform SDK

[Aleck D.Shadow]

Scorp__):
В точку.
Sla:
У нас технологическая машина - это обычный или не обычный (в более бронированном корпусе) компьютер.
Исторически у нас называют "технологическим" все что связанно с выполнением той или иной технологии производства.
Проблема возникает не в проектировании, а заложенных изначально неучтенных(естественно) багов, т.е. вот если вот тут эта штука будет в этот момент времени здесь, а вот та штука будет вот тут, и еще человек включит тумблер то программа попадает в ловушку зацикливается и нагружает сеть, незначительно, но при этом начинает тормозить другая штука которая ни в коем случае не должна тормозить.
PS:
Нет предела совершенству.