Страница 1 из 3
падения при большой нагрузке

Добавлено:
09 сен 2010, 06:18
dr0m0k
Снова возвращаюсь вк этой теме, т.к. проблема до сих пор не решена и непонятно будет ли решена вообще. Вкратце напомню суть - при просмотре большого количества камер с большой скоростью система падает и перезапускается. Как известно, это связано с перерасходом виртуальной памяти и причина в ОС. Но !. Это же ерунда... Если существующий метод работы с архивом некорреткно работает под выбранной ОС, значит его надо менять. А тянется это уже хз сколько - наверное с самого появления Storage 2005. Новый Storage 2010 ситуацию не спасает, может сделать Stotage 2010.1 ?

или хотя бы Storage 2011?
Вообще, хочется услышать хотя бы, что работа в этом направлении ведется и результаты будут скоро, потому что пока даже такой информации нет, да и если работа ведется, то 5 лет ведь уже...
З.Ы. недавно, я по причине этого глюка потерял объект - пришлось забрать сервер и часто слышу нарекания с других объектов.
З.З.Ы. а давайте исправим это в SP1 !!!


Добавлено:
09 сен 2010, 09:25
BigMax
Миша, я попросил коллег из отдела Комплексных цифровых решений и Технической поддержки ответить тебе на форуме. Ты, мне казалось, понимаешь, что ограничения никак не связаны с архивом (не важно с каким 2005 или 2010).
Странно, что ты не научился правильно выбирать конфигурацию системы чтобы она обеспечивала требуемые клиентом параметры работы.
(Желание сделать семь шапок из одной шкурки всегд приводит к тому, к чему и должно)

Добавлено:
09 сен 2010, 09:28
Tregart
Ну вот в этой теме я предлагал решение этой проблемы:
http://www.videonet.ru/forum/viewtopic. ... 43&start=0
интересно было бы услышать мнение саппорта.

Добавлено:
09 сен 2010, 10:51
dr0m0k
BigMax писал(а):Миша, я попросил коллег из отдела Комплексных цифровых решений и Технической поддержки ответить тебе на форуме. Ты, мне казалось, понимаешь, что ограничения никак не связаны с архивом (не важно с каким 2005 или 2010).
Странно, что ты не научился правильно выбирать конфигурацию системы чтобы она обеспечивала требуемые клиентом параметры работы.
(Желание сделать семь шапок из одной шкурки всегд приводит к тому, к чему и должно)
Падение работающей программы - это не ограничение, это исключительная ситуация! Такого быть не должно в принципе.
Опишу последний такой сервер: мать ASUS, памяи 2 гигабайта, DEP и PAE отключены, восстановление системы на архивных дисках отключено, 4 винчестера по 500 гиг, процессор Intel Core 2 Quad Q9400, 36 цветных камер (PowerVN8 + PowerVN8 + TinyVN4), VideoNet 8.6
Всё собрано по требованиям.
З.Ы. в любой программе должна быть защита "от дурака" и если невозможно что-то сделать без риска для стабильности работы - этого делать не надо.

Добавлено:
09 сен 2010, 11:14
Vibat
Сомневаюсь, что Тини с PowerVN8 это по требованиям.
Михаил бы мне сказал, что с памятью новые платы работают по другому и потому возможны торможения (так ?)

Добавлено:
09 сен 2010, 11:31
dr0m0k
Vibat писал(а):Сомневаюсь, что Тини с PowerVN8 это по требованиям.
Михаил бы мне сказал, что с памятью новые платы работают по другому и потому возможны торможения (так ?)
речь не о торможении...

Добавлено:
09 сен 2010, 21:25
biggrandfather
Хотел найти твоё решение, но так и не понял, кем ты был в том топике ? Вот его участники :
Stalker , Vibat, Максим, Slav, dr0m0k, OW , Max

Добавлено:
10 сен 2010, 04:07
Tregart
Старый ник Stalker.
Решение вот:
2. Так же необходимо дать возможность ограничивать максимальную скорость просмотра архива. Например максимальное кол-во камер - 9, максимальная скорость - 4х.

Добавлено:
10 сен 2010, 05:32
dr0m0k
да уже не раз просили это сделать, но что-то всё никак

Добавлено:
10 сен 2010, 07:34
Vibat
я вчера пробовал крутить на 24 скорости (и зажимал клавишу турбо) 22 камеры цвет. пишут по детекции хорошего качества DVPack2, 3 винта 750 Gb, 2 штуки PowerVN8 , 2 gb ram, Core 2 Quad, 2 монитора ну за пол часа так ничего и не произошло
Попробую сегодня еще ..
У меня другая проблема - 8.6, потому как нормально работает на версии 8.4 (как говорит Максим - научился

), уже стал забывать где, разве что пыль сдуть

Добавлено:
10 сен 2010, 12:44
Predator
Система VideoNet позволяет пользователю осуществлять множество различных действий в самых разнообразных комбинациях. Естественно каждое дополнительное действие (такое как воспроизведение, перемотка, улучшение качества сетевого видео или темпа отображения по сети) увеличивает нагрузку на компоненты сервера, как программные, так и аппаратные, иногда очень существенно. В конечном счёте это может привести к ограничению работоспособности системы вплоть до её перезапуска с целью высвободить недостающие ресурсы для продолжения работы. Рецепт в данном случае только один: если есть вероятность возникновения таких ситуаций (конфигурация системы такова, что работает уже на пределе), необходимо опытным путем, установить рамки, в которых пользователь может работать с системой (сколько камер можно воспроизводить из архива одновременно; сколько камер и с какой скоростью перематывать в направлении вперед, а сколько в направлении назад; и т.д.). Сделать это можно путем проведения сценария работы с системой с одновременным контролем за расходов виртуального адресного пространства, нагрузки на процессор, память и диски (через счетчики Windows). При проектировании систем необходимо учитывать все выше сказанное и выбирать такое соотношение «число камер/сервер», которое позволило бы заказчику работать с системой так, как он хочет.
Можно было бы конечно внести искусственные ограничения в систему, но тогда пользователи не могли бы получать от системы и оборудования максимума их возможностей. Ведь зачастую, пиковые нагрузки возникают крайне редко, да и сталкиваются с такими ситуациями единицы, даже из наиболее продвинутых инсталляторов/интеграторов и пользователей.

Добавлено:
10 сен 2010, 14:34
Vibat
Tregart писал(а):Старый ник Stalker.
Решение вот:
2. Так же необходимо дать возможность ограничивать максимальную скорость просмотра архива. Например максимальное кол-во камер - 9, максимальная скорость - 4х.
Плохое решение. Если у вас надо ограничить, повесьте инструкцию рядом с оператором на какой скорости крутить и тут же палку (если ему непонятно) ..
я то почему должен страдать ? у меня всё работает !


Добавлено:
10 сен 2010, 23:07
dr0m0k
почему страдать? речь об добавлении такой опции в конфигурацию!
З.Ы. основной мой тезис - система не должна падать (перезапускаться) вне зависимости от того на какой платформе она запущена, если в работе я использую только предоставленные самой системой возможности и органы управления.

Добавлено:
11 сен 2010, 08:16
Vibat
Добавлять придется не в конфигурацию, а в настройки проигрывателя. Тогда надо паролить опции проигрывателя. Стоит ли со всем этим заморачиваться, когда можно просто сказать ?
--
Стоп. Так ты согласен, что сбой архива на большой скорости прокрутки это не глюк архива ? (а перерасход ресурсов)
Ведь действительно, стоит подумать, если системный монитор (по Кудинову Михаилу) показывает перерасход ресурсов компьютера, почему не ограничить возможности VideoNet автоматически ? По типу как процессоры Intel снижают скорость при нагреве.

Добавлено:
11 сен 2010, 08:35
dr0m0k
Vibat писал(а):Добавлять придется не в конфигурацию, а в настройки проигрывателя. Тогда надо паролить опции проигрывателя. Стоит ли со всем этим заморачиваться, когда можно просто сказать ?
у нас очень суровые люди, как известно, и слова не воспринимают...
--
Стоп. Так ты согласен, что сбой архива на большой скорости прокрутки это не глюк архива ? (а перерасход ресурсов)
я говорю про падение VideoNet, можно это назвать и сбоем архива. Ну а что не согласиться? Это ж официальный ответ разработчика.
А вообще причина мне интересна только с исследовательской точки зрения - гораздо интереснее устранение этой причины, какой бы она не была.
Ведь действительно, стоит подумать, если системный монитор (по Кудинову Михаилу) показывает перерасход ресурсов компьютера, почему не ограничить возможности VideoNet автоматически ? По типу как процессоры Intel снижают скорость при нагреве.
о том и речь...
Грубый пример: когда при программировании выделяется память, нужно проверять что она выделилась, но можно и не проверять, а сразу работать с ней - памяти же много, чего бы ей не выделиться... А в результате получим вылет программы. Еще раз говорю - пример очень грубый, VideoNet - большая сложная система - всё на несколько порядков сложнее, но это не значит что не нужно решать проблему.

Добавлено:
11 сен 2010, 13:50
Tregart
Vibat писал(а): Плохое решение. Если у вас надо ограничить, повесьте инструкцию рядом с оператором на какой скорости крутить и тут же палку (если ему непонятно) ..
я то почему должен страдать ? у меня всё работает !

Мое решение - хорошее решение. Можно повесить рядом инструкцию
"Камеру №1 не смотреть! Это скрытая камера, которая стоит в женской раздевалке!", а можно разграничить права доступа к ней.
Вы страдать не должны, т.к. речь идет о добавлении гибкости конфигурирования П.О. А еще огромный минус предложенной Вами схемы в том, что оператор "нечаянно" покрутит,а потом скажет что он вообще ни к чему не прикасался.
Predator писал(а):Можно было бы конечно внести искусственные ограничения в систему, но тогда пользователи не могли бы получать от системы и оборудования максимума их возможностей.
Михаил! Мне кажется, что вы немного лукавите. В видеонете можно ограничивать темп записи по камерам с 25 к/с до 1 к/с. Т.е. если инсталлятор обрезает темп записи до 2 к/с это значит он не дает пользователю добиться максимума возможностей от системы и это жутко плохо? Или ограничение прав доступа к настройке видеосервера это плохо? Вы ввели кучу опциональных искусственных ограничений в софт и это делает его гибким, а теперь говорите, что это не айс.
Я вижу такую схему решения проблемы:
В настройках проигрывателя добавляется опция ограничить скорость просмотра и кол-во камер на монитор. Эти опции можно редактировать только под учеткой администратора. Либо добавить эту опцию в закладку "Система". Каких прав и свобод лишится пользователь системы, получивший еще более гибкие настройки?

Добавлено:
11 сен 2010, 17:17
Vibat
Да я уж почти согласился с вами, просто твой пример был неудачным
Например максимальное кол-во камер - 9, максимальная скорость - 4х
Ну серьёзно, вроде не первый день VideoNet_ом пользуюсь, но не разу с таким не сталкивался. Хоть 9, хоть 15, хоть 25 камер, крутят операторы и хоть бы хны !
ЗЫ
Если есть физический доступ к серверу - плохо, вычислить скрытую камеру (микрофон) вообще никаких проблем (других способов много вывести из строя сервер и крайнего не найти) , а если поставить операторам сетевое место IVC-V8 шансы обрушить архив (сам VN) составит почти ноль процентов.
ЗЫ2:
Насчет лукавства Кудинова, тоже не айс , он то здесь причем ?
Хотя подобных примеров в программе VN предостаточно, один из самых смешных - невозможность создать том одним файлом более 2 ТБ в Win XP

(но это уж другая тема)

Добавлено:
11 сен 2010, 18:00
dr0m0k
Vibat писал(а):Да я уж почти согласился с вами, просто твой пример был неудачным
Например максимальное кол-во камер - 9, максимальная скорость - 4х
Ну серьёзно, вроде не первый день VideoNet_ом пользуюсь, но не разу с таким не сталкивался. Хоть 9, хоть 15, хоть 25 камер, крутят операторы и хоть бы хны !
Ладно, такая ситуация - памяти 2 гига, проц - Квад 9400, запись в максимальном разрешении и качестве "хорошее" кодеком DVPack 2.0, скорость записи - 6к/с. Послдений тест проводил при отключенных камерах, т.е. детекторы не работают, записьне ведется. Выставляем на воспроизведение 25 камер, скорость 24х... Мотаем секунд 10-20, затем нажимаем кнопку перемотки назад. Всё - приплыли... Ни туда, ни сюда... Загрузка процессора стремится к нулю, память не жрётся. Тем не менее, картинка стоит. Перезапускаешь проигрыватель и можно опять работать. Это разве не глюк? Происходит какой-то зависон, который снимается перезапуском проигрывателя! А что, нельзя то же самое выполнить при смене направления перемотки?
Я проверю всё еще несколько раз и вышлю в поддержку с подробным описанием.
Насчет лукавства Кудинова, тоже не айс , он то здесь причем ?
Хотя подобных примеров в программе VN предостаточно, один из самых смешных - невозможность создать том одним файлом более 2 ТБ в Win XP

(но это уж другая тема)
Михаил точно ни при чем - он излагает позицию компании. Но камушек в мой огород кинул


Добавлено:
11 сен 2010, 18:14
Vibat
dr0m0k писал(а):Ладно, такая ситуация - памяти 2 гига, проц - Квад 9400, запись в максимальном разрешении и качестве "хорошее" кодеком DVPack 2.0, скорость записи - 6к/с. Послдений тест проводил при отключенных камерах, т.е. детекторы не работают, записьне ведется. Выставляем на воспроизведение 25 камер, скорость 24х... Мотаем секунд 10-20, затем нажимаем кнопку перемотки назад. Всё - приплыли... Ни туда, ни сюда... Загрузка процессора стремится к нулю, память не жрётся. Тем не менее, картинка стоит. Перезапускаешь проигрыватель и можно опять работать. Это разве не глюк? Происходит какой-то зависон, который снимается перезапуском проигрывателя! А что, нельзя то же самое выполнить при смене направления перемотки?
Я проверю всё еще несколько раз и вышлю в поддержку с подробным описанием.
Это архив 8.6 так себя ведет ? Тебе надо поторопиться с высылкой описания, т.к. 8.6 sp 1 близко к выпуску. Я с этой версией так и " не научился" . Удали файл тома, (перезапусти VN - формат 64 кб - не забывать адаптацию) , скорее всего будет нормально.
(боюсь сказать, что лечить архив 8.6 бесполезно, но очень похоже - так и есть)
Перемотка назад - может из за неё ? (мои операторы крутят "вперед", ну может по-кадрово чуть "назад" , найти нужный кадр)

Добавлено:
11 сен 2010, 18:41
dr0m0k
стопудово из-за перемотки назад! но глюк то налицо
З.Ы. а вообще - задача архив уронить... точнее определить последовательность действий случайных или намеренных, которые приводят к падению. Это актуально для всех версий. Присоединяйся!

Добавлено:
11 сен 2010, 18:45
Vibat
Я давно говорю, что очень надежна версия 8.4, что ей не хватает, так только Total IP . В ней придумали , к примеру, АДО , но и старый детектор оставили. Если АДО загружает непомерно процессор, то есть возможность пользоваться обычным детектором. Тут же нас выбора лишили .. Был нормальный архив, ну иногда "на старуху проруха .." , а стал какой непроверенный. Дали б нам на время хотя б погонять, потестить .. нет ? ; ну тогда читайте.

Добавлено:
11 сен 2010, 18:50
dr0m0k
архив падает на всех версиях, хотя может с разной частотой... но тестить на 8.4 смысла нет, потому что есть 8.6 и никто не будет отвлекаться на глюки, которые возможно уже испрвлены

Добавлено:
11 сен 2010, 18:57
Vibat
dr0m0k писал(а):З.Ы. а вообще - задача архив уронить... точнее определить последовательность действий случайных или намеренных, которые приводят к падению. Это актуально для всех версий. Присоединяйся!
Присоединяюсь для проверки самых последних релизов. Нет более приятного занятия !


Добавлено:
12 сен 2010, 07:01
Tregart
Vibat писал(а):Да я уж почти согласился с вами, просто твой пример был неудачным
Например максимальное кол-во камер - 9, максимальная скорость - 4х
Ну серьёзно, вроде не первый день VideoNet_ом пользуюсь, но не разу с таким не сталкивался. Хоть 9, хоть 15, хоть 25 камер, крутят операторы и хоть бы хны !
Иногда слова могут быть очень неправильно истолкованы

Я имел ввиду, про возможность ограничения количества просматриваемых камер (например 9) и максимальной скорости просмотра (например 4х) . Тогда сервак не упадет точно.
Более того - при просмотре 28 камер со скоростью 24х софт не просто перезагружается. Отключается запись по ряду камер! И включается только после корректного перезапуска софта! Неоднократно были неприятные ситуации когда оператор "провожал" человека по камерам (т.е. смотрел одновременно несколько камер) и врубал перемотку на макс. скорости, чтобы пропустить неинтересное. Потом софт перезагружался, после перезагрузке останавливалась запись по ряду камер, а потом заказчик у меня спрашивал "Какого фига у меня записи нет".
Повторюсь - можно конечно везде ставить i7 920, но востребованно ли это? В вышеприведенном примере использовалась такая конфигурация сервака, что пиковая загрузка процессора составляла не более 35%. Стояло 4 гб памяти (определялись 3Гб) и все равно просмотр архива в таком режиме приводил к краху П.О.
Vibat писал(а):Если есть физический доступ к серверу - плохо, вычислить скрытую камеру (микрофон) вообще никаких проблем (других способов много вывести из строя сервер и крайнего не найти) , а если поставить операторам сетевое место IVC-V8 шансы обрушить архив (сам VN) составит почти ноль процентов.
Да это-то понятно. Но далеко не всегда заказчик готов платить за клиентское место. Под клиентским местом я подразумеваю не только стоимость IVC-v8, а еще сам системник, бесперебойник к нему + винда.

Добавлено:
12 сен 2010, 08:04
Vibat
Кудинов Михаил Пт, 10 Сен 2010 , 12:44 объяснял как мониторить ресурсы, я после того сообщения ему звонил и всё уточнял как он это делает (perfmon.exe и т.д. .. ) Тут тебе надо разобраться, это глюк архива или недостаток ресурсов. А может все на одном винчестере и он успевает записывать-считывать ? Не все зависит от мощности процессора или количества памяти, процессу например может не хватить виртуальной памяти, и толку от установленной 4 гб (тут я не совсем понимаю, как виртуальное адресное пространство накладывается на память в программе VideoNet).
Я как то настраивал "интеллект" , продукт ITV, 36 камер и 3 сетевых места . Всё зависало только при просмотре 36 камер в ТРАСЛЯЦИИ, но если смотреть по частям, по 9-16 камер, всё работает, оператор не дурак всё понял и более не вызывал. Проблема там оказалась в разогнанном процессоре, а выявилось с помощью стресс-теста Everest.
Если ресурсов не хватает и клиент отказывается платить за дополнительное оборудование, можно настроить ему проигрыватель VideoNet. Можно менять списки воспроизведения, а можно просматривать определенное количество камер . Конструируется временный режим (1,4,9,16,25). Ну наверное не мне тебе это объяснять.
Только эти настройки не пароляться, тут уж решать всем "комьюнити", нужно ли это.