Мы запускаем облачный сервис MQL5 Cloud Network! - страница 71

 
Interesting:

1. На моем CPU (AMD Phenom II X6 1090T Processor, 16373MB) PR колебалось от 59 до 61. Значение на время когда еще агенты в работе были, с 02.11.2011 ядра не в облаке.

Предполагаю, что PR можно увеличить и до 100, но по большому счету погоды это не сделает.

2. Ограничение на PR нужно понизить. Раздача должна проводиться для всех агентов у которых PR больше определенного "разумного" уровня (но при этом алгоритм должен подразумевать передачу задач приоритетно агентам с большим значением PR). Вот когда свободных агентов с большим значением PR нет шанс получат все остальные.

3. Понятно что агент с PR 50 выполнит задачу медленнее чем агент у которого PR 100. Это нужно учитывать в оценке стоимости. Но с другой стороны таких агентов может быть на порядок больше, что обеспечит вполне приемлемую скорость выполнения тестирования.

1. Да это и не важно, были агенты в облаке или нет, для этого есть дополнительный фильтр "Активные за последние сутки", установив его PR будет суммой агентов определенного хоста (сгруппированого) последних суток в работе, т.е. адекватный.
Ну или другой вариант: добавить группировку не по CPU, а по хостам (Описание), тогда будет наверно еще проще, типа вот хост и его общий PR.

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

3. А это уже учитывается, цена ведь считается от PR.

 

Меня тут настораживает еще один момент в связи с ранжированием заданий по уровню PR агентов. Если на одном процессоре в момент очередного получения заданий для агентов, одно из ядер было по нагрузкой. Соответсвенно, в этот момент PR агента на этом ядре упадет, предположим, ниже плинтуса, т.е. 10. Выходит, что он больше никогда не получит задание?
 
flexsun:

Меня тут настораживает еще один момент в связи с ранжированием заданий по уровню PR агентов. Если на одном процессоре в момент очередного получения заданий для агентов, одно из ядер было по нагрузкой. Соответсвенно, в этот момент PR агента на этом ядре упадет, предположим, ниже плинтуса, т.е. 10. Выходит, что он больше никогда не получит задание?

Я думаю PR считается агентом самостоятельно, т.е. он генерирует задачу и проводит тест каждые 5 минут к примеру, отправляет эти данные на сервер.

Получается если PR упадет до 10, то на время агент снимется из очереди на задачи, а через некоторое время PR пересчитается по новой, будучи уже не под нагрузкой и обновит данные на сервере, что вернет агент в строй.

Наверно все так и реализовано, а если нет -  на заметку разработчикам. 

 
fyords:

Получается если PR упадет до 10, то на время агент снимется из очереди на задачи, а через некоторое время PR пересчитается по новой, будучи уже не под нагрузкой и обновит данные на сервере, что вернет агент в строй.

Наверно все так и реализовано, а если нет -  на заметку разработчикам. 

Как обещали, начиная  с сегодняшнего билда (555) пересчет PR будет раз в час. До этого было намного чаще. Например, у меня вчера все ядра "скатились" до 60, сегодня утром, когда компьютер всю ночь стоял без нагрузки - выравнялись до 110-116. Разработчиками это учтено.

 
В менеджере агентов на вкладке "Службы" не хватает текущего статуса "свободен/занят" (желательно с процентом выполнения). Навеяно наблюдением за 100% загрузкой CPU агентами на протяжении десятка минут, причём в логе последняя запись была за пару часов до описываемого момента).
 
WChas:

Как обещали, начиная  с сегодняшнего билда (555) пересчет PR будет раз в час. До этого было намного чаще. Например, у меня вчера все ядра "скатились" до 60, сегодня утром, когда компьютер всю ночь стоял без нагрузки - выравнялись до 110-116. Разработчиками это учтено.

Ну вот поставил я 555 билд и заметил циклическую загрузку по всем ядрам до 100% каждую минуту (запустил монитор ресурсов (Win7), там шкала 60 секунд), может это и есть пересчет PR?

Хотя через 10 минут цикличность пропала. Наблюдаем дальше. 

Файлы:
CPU.jpg  49 kb
 
fyords:

Ну вот поставил я 555 билд и заметил циклическую загрузку по всем ядрам до 100% каждую минуту (запустил монитор ресурсов (Win7), там шкала 60 секунд), может это и есть пересчет PR?

Хотя через 10 минут цикличность пропала. Наблюдаем дальше. 

На мой взгляд на прикрепленном файле - явное выполнение задания.
 
Ashes:
В менеджере агентов на вкладке "Службы" не хватает текущего статуса "свободен/занят" (желательно с процентом выполнения). Навеяно наблюдением за 100% загрузкой CPU агентами на протяжении десятка минут, причём в логе последняя запись была за пару часов до описываемого момента).
Полностью согласен и поддерживаю. Так будет наглядней..
 
WChas:
На мой взгляд на прикрепленном файле - явное выполнение задания.
Количество выполненых задач не возрастало в тот момент, хотя кто его знает, спорить не буду.
 
WChas:
На мой взгляд на прикрепленном файле - явное выполнение задания.

Проверять нужно не общую загрузку ЦПУ, а конкретного приложения (процесса), а нашем случае это тестер.

Хотя если на ПК ничего не крутилось особо тяжелого то может и такая проверка подойти.