"Ускорение" обработки данных в boinc-проектах
Цитата: AlexA от 20.10.2019, 08:24Как известно, пожалуй, главной особенностью boinc-проектов, да и грид-систем в целом, остается малая связанность обрабатываемых задач и сильная их зависимость от режимов работы удаленных компьютеров, на которых по различным причинам обрабатываемые задания могут "зависать" на длительное время. В результате замедляется и общий ход вычислений проекта (пока пройдет время дедлайна, пока новая копия недообработанного задания отошлется новому расчетчику, пока оно посчитается и вернется ...). В общем, при многих сотнях или тысячах компьютеров это может оказаться серьезной проблемой.
Одним из способов решения часто предлагается учитывать надежность хостов. Т.е. тем хостам, которые более стабильно и быстро просчитывают и возвращают задания отсылать новые порции в первую очередь и в большем количестве. Мне помнится, что эту тему обсуждали и даже в каком-то (вроде бы полуручном) виде реализовывали толи в SAT, то ли в Герасиме.
ВОт на подобное обсуждение наткнулся на форуме проекта SETI@home beta. И было это еще в 2013-м году.Можно ли учесть при отправке повторных заданий репутацию хоста (например, репутацию выдающего действительного результата и скорость, с которой он обычно отправляет результаты), а также повторную отправку осуществлять, прежде всего, хостам с самой высокой репутацией?
Часто в базе данных висят результаты на многие недели или даже месяцы, ожидая хостов, которые никогда не отсылают результат. Затем он истекает и отправляется снова, и часто снова отправляется хосту, который в лучшем случае отправит его обратно через пару недель, или, в худшем случае, никогда больше не услышит. Тогда цикл начинается сначала ...
Наличие хостов с высокой репутацией надежности в качестве первичных хостов повторной отправки, вероятно, уменьшит спрос на базу данных, а также размер базы данных, поскольку не будет слишком много задач одновременно.
Тема почему-то не получила особого развития, там всего один ответ:
Я должен согласиться с вами в этом. Это следует использовать здесь, в бета-версии и на основной SETI. Это определенно помогло бы постоянно растущей проблеме с таблицами базы данных, которая у них была нередко.
Еще одна вещь, которая помогла бы решить проблемы с базой данных, заключалась бы в сокращении времени первоначального оборота (крайнего срока) до 14 дней для новых задач и 7 дней для всех повторных отправлений. Я не знаю ни одного другого проекта с таким длительным сроком, как SETI.
Я знаю, что BoincSIMAP использовал надежные хосты для повторной отправки. Повторно отправленные задачи отправляются как высокоприоритетные, поэтому они передаются на передний план для обработки.
Тут упоминается реализация подобного алгоритма в проекте SIMAP. Кто-то в курсе как это работало и где еще применяется подобный подход?
Или он по каким-то причинам неэффективен и не нашел своей реализации?
Как известно, пожалуй, главной особенностью boinc-проектов, да и грид-систем в целом, остается малая связанность обрабатываемых задач и сильная их зависимость от режимов работы удаленных компьютеров, на которых по различным причинам обрабатываемые задания могут "зависать" на длительное время. В результате замедляется и общий ход вычислений проекта (пока пройдет время дедлайна, пока новая копия недообработанного задания отошлется новому расчетчику, пока оно посчитается и вернется ...). В общем, при многих сотнях или тысячах компьютеров это может оказаться серьезной проблемой.
Одним из способов решения часто предлагается учитывать надежность хостов. Т.е. тем хостам, которые более стабильно и быстро просчитывают и возвращают задания отсылать новые порции в первую очередь и в большем количестве. Мне помнится, что эту тему обсуждали и даже в каком-то (вроде бы полуручном) виде реализовывали толи в SAT, то ли в Герасиме.
ВОт на подобное обсуждение наткнулся на форуме проекта SETI@home beta. И было это еще в 2013-м году.
Можно ли учесть при отправке повторных заданий репутацию хоста (например, репутацию выдающего действительного результата и скорость, с которой он обычно отправляет результаты), а также повторную отправку осуществлять, прежде всего, хостам с самой высокой репутацией?
Часто в базе данных висят результаты на многие недели или даже месяцы, ожидая хостов, которые никогда не отсылают результат. Затем он истекает и отправляется снова, и часто снова отправляется хосту, который в лучшем случае отправит его обратно через пару недель, или, в худшем случае, никогда больше не услышит. Тогда цикл начинается сначала ...
Наличие хостов с высокой репутацией надежности в качестве первичных хостов повторной отправки, вероятно, уменьшит спрос на базу данных, а также размер базы данных, поскольку не будет слишком много задач одновременно.
Тема почему-то не получила особого развития, там всего один ответ:
Я должен согласиться с вами в этом. Это следует использовать здесь, в бета-версии и на основной SETI. Это определенно помогло бы постоянно растущей проблеме с таблицами базы данных, которая у них была нередко.
Еще одна вещь, которая помогла бы решить проблемы с базой данных, заключалась бы в сокращении времени первоначального оборота (крайнего срока) до 14 дней для новых задач и 7 дней для всех повторных отправлений. Я не знаю ни одного другого проекта с таким длительным сроком, как SETI.
Я знаю, что BoincSIMAP использовал надежные хосты для повторной отправки. Повторно отправленные задачи отправляются как высокоприоритетные, поэтому они передаются на передний план для обработки.
Тут упоминается реализация подобного алгоритма в проекте SIMAP. Кто-то в курсе как это работало и где еще применяется подобный подход?
Или он по каким-то причинам неэффективен и не нашел своей реализации?
Цитата: hoarfrost от 20.10.2019, 10:04Могу сказать следующее:
- Когда все результаты приходят быстро, без задержек - то это облечает работу с ними: позволяет раньше "закрыть" очередной диапазон, начать постобработку, меньше потребляется места на томе и т.д. Это действительно очень удобно;
- Но теория вероятности потому и работает, что из 16000 workunit-ов с хотя бы одним заданием у штук 200-300 - что-нибудь да произойдёт. Участник может добавить новый проект, из-за чего BOINC начнёт первые несколько дней отдавать его заданиям наибольший приоритет, а когда статистика по времени работы разных проектов - выравняется и дело дойдёт до ранее полученных заданий - компьютер окажется выключенным на пару-тройку дней. Или пропадёт сеть, или сломается HDD и т.д.;
- Все перечисленные выше проблемы - могут быть абсолютно внезапными, у компьютеров, которые ранее демонстрировали огромную надёжность. Например - как с первыми 3 узлами Shmya Cluster, которые просто оказались отключенными от сети. Поэтому, на мой взгляд, вводить коэффициенты надёжности и т.п. - не имеет особого смысла, так как всё можно сделать проще;
- Насколько мы видели в RakeSearch - основная проблема не в том, что кто-то не вернул результат, а в том, что в некоторых workunit-ах не возвращается не один, а два, три, четыре и даже больше результатов. Вероятность того, что отдельно взятый workunit станет таким невезучим - очень мала, но даже среди 16000 - таких наибрается около 10-15 штук. И именно от того, насколько быстро будут обработаны результаты к вот таким "невезучим" workunit-ам и зависит то, насколько быстро будет закрыт очередной диапазон;
- Ну а коли так, что всё просто - после того, как выпускается первая партия заданий к workunit-у (т.е. initial quorum), атрибут delay_bound для такого workunit-а - меняется с 7 дней на 3 и всё - все дополнительные задания будут уже выпускаться с маленьким deadline-ом и обрабатываться намного быстрее (как только на BOINC-клиенте появляется задание с deadline-ом в 3 дня, то, как правило, он сразу же начинает его считать). Делается это просто, буквально одним sh+SQL скриптом. Так как workunit-ов, к которым требуется выпускать дополнительные задания - немного, что такие "экспресс-задания" будут растворяться в общей массе и не будут как-то ощутимо нарушать порядок вычисления других заданий на компьютере. Подобный эксперимент мы некорое время проводили в RakeSearch, во время поиска R9, когда хотели навести некоторый порядок в ещё незакрытых диапазонах. Возможно, что мы ещё вернёмся к этой практике, благо уже есть некоторая статистика уже именно в рамках поиска R10 и будет с чем сравнить.
Могу сказать следующее:
- Когда все результаты приходят быстро, без задержек - то это облечает работу с ними: позволяет раньше "закрыть" очередной диапазон, начать постобработку, меньше потребляется места на томе и т.д. Это действительно очень удобно;
- Но теория вероятности потому и работает, что из 16000 workunit-ов с хотя бы одним заданием у штук 200-300 - что-нибудь да произойдёт. Участник может добавить новый проект, из-за чего BOINC начнёт первые несколько дней отдавать его заданиям наибольший приоритет, а когда статистика по времени работы разных проектов - выравняется и дело дойдёт до ранее полученных заданий - компьютер окажется выключенным на пару-тройку дней. Или пропадёт сеть, или сломается HDD и т.д.;
- Все перечисленные выше проблемы - могут быть абсолютно внезапными, у компьютеров, которые ранее демонстрировали огромную надёжность. Например - как с первыми 3 узлами Shmya Cluster, которые просто оказались отключенными от сети. Поэтому, на мой взгляд, вводить коэффициенты надёжности и т.п. - не имеет особого смысла, так как всё можно сделать проще;
- Насколько мы видели в RakeSearch - основная проблема не в том, что кто-то не вернул результат, а в том, что в некоторых workunit-ах не возвращается не один, а два, три, четыре и даже больше результатов. Вероятность того, что отдельно взятый workunit станет таким невезучим - очень мала, но даже среди 16000 - таких наибрается около 10-15 штук. И именно от того, насколько быстро будут обработаны результаты к вот таким "невезучим" workunit-ам и зависит то, насколько быстро будет закрыт очередной диапазон;
- Ну а коли так, что всё просто - после того, как выпускается первая партия заданий к workunit-у (т.е. initial quorum), атрибут delay_bound для такого workunit-а - меняется с 7 дней на 3 и всё - все дополнительные задания будут уже выпускаться с маленьким deadline-ом и обрабатываться намного быстрее (как только на BOINC-клиенте появляется задание с deadline-ом в 3 дня, то, как правило, он сразу же начинает его считать). Делается это просто, буквально одним sh+SQL скриптом. Так как workunit-ов, к которым требуется выпускать дополнительные задания - немного, что такие "экспресс-задания" будут растворяться в общей массе и не будут как-то ощутимо нарушать порядок вычисления других заданий на компьютере. Подобный эксперимент мы некорое время проводили в RakeSearch, во время поиска R9, когда хотели навести некоторый порядок в ещё незакрытых диапазонах. Возможно, что мы ещё вернёмся к этой практике, благо уже есть некоторая статистика уже именно в рамках поиска R10 и будет с чем сравнить.