После вчерашнего сообщения Decibel'а
осталось некоторое количество вещей,
которые стоило бы объяснить
поподробнее. Мы получили изрядное
количество жалоб от членов команды DPC,
утверждавших, что никакого
организованного мега-слива не было, и
что вывод, сделанный командой DCTI, был
поспешным и во многом неверным.
На настоящий момент причиной
фактического выхода статистики из
строя мы считаем совокупность
отдельных участников, копивших блоки
в прошлом и сливающих их из
соображений типа "мои 8012 блоков
скоро не зачтут вовсе". Кто-то
скажет: "И что ж в том дурного?"
Увы, увы, это вызывает одномоментный
сброс большого количества блоков,
который в норме должен был бы
происходить в течение многих дней.
Маленькое замечание: вообще нехорошо
пытаться копить блоки. Даже если вы
делаете это в одиночку и "только на
несколько недель". Почему?
Наш мастер-сервер оптимизирован для
обработки ключей из одного или по
крайней мере из малого количества сегментов.
Каждый сегмент ключей занимает 32
мегабайта памяти. Чем меньше
сегментов загружено в память
одновременно, тем быстрее идет
процесс обработки. Из-за оптимизаций
кода даже процесс смены сегмента
достаточно сильно ухудшает
производительность. Когда на мастере
набирается очередь из нескольких
миллионов блоков из, скажем, 20
сегментов, ему совсем плохеет.
В ответ на это некоторые могут
заявить: "Ну уж если вы теперь не
можете справиться с выбросом
нагрузки в виде нескольких миллионов
блоков, что же вы будете делать с ними
потом, когда такая загрузка станет
нормальной?" Я надеюсь, что данное
выше объяснение сохраняет истину и
на будущее. Мы тщательно
спроектировали мастер-сервер, и его
тестирование показало, что при
обработке более-менее стандартно
поступающих блоков, мы с легкостью
обработаем поток порядка 1000
гигаключей в секунду на текущем
оборудовании. В нормальной ситуации
блоки из неоткрытых сегментов
откладываются в отдельную очередь,
которая обрабатывается в периоды
снижения загрузки. При наличии кучи
очередей для массы неактивных
сегментов теоретическая
производительность в один тераключ в
секунду падает до величины, которая
ниже средней скорости получения
ключей, ибо ситуация с растущей
очередью -- одна из самых неприятных
для любого процесса обработки данных.
[Спросите у любого серьезного
программиста баз данных - D.Marck].
Я надеюсь, я привел достаточно веские
аргументы для того, чтобы участники
не пытались сохранять слишком много
блоков. Ежедневная статистика
предназначена именно для того, как
она называется: для оценки дневной
производительности. Не для того,
чтобы раз в год на сутки занять
первое место из-за того, что вы
накопили больше ваших друзей. Если вы
действительно хотите занять первое
место, просто найдите больше
компьютеров для обсчета!
Мы пытаемся привлечь максимальное
количество участников, и всегда рады
проявлениям энтузиазма участников.
Однако, если наши правила постоянно
нарушаются, мы можем быть вынуждены
предпринимать специальные меры
против этого, например,
блокированием участников в
статистике или ограничением времени
жизни блока. Не потому, что нам не
нравятся эти конкретные участники, а
потому, что мы хотим сохранить
ситуацию честного соревнования для
всех. По возможности, без "хитрых
приемов", типа накопления блоков.
Последнее замечание по поводу
очереди блоков: ее создание не
означает, что наша система сломалась,
просто нагрузка на нее такова, что
требует специальных мер по обработке.
Мы примем все блоки, и никогда не
будем отказывать в приеме блоков на
наших прокси-серверах. Мы обязательно
обработаем все их. Может быть, не
сегодня, когда получится, но
обработаем. В результате каждый блок
будет учтен. Ваша суммарная
статистика будет корректно отражать
общее количество блоков. Если все
мы будем предпринимать усилия по
поддержанию работы системы в том
виде, в котором она была
спроектирована, отложенных очередей
возникать не должно, и ежедневная
статистика тоже будет корректна.