Обновление Safe Network 🇷🇺 7 июля 2022 г

Это машинный перевод. Оригинал на английском здесь: Update 7 July, 2022


Спасибо Spatium за 4 заглавных изображения, которые вы увидите в ближайшие недели :heart_eyes:

Некоторые многообещающие новости на фронте поиска ошибок, поскольку команда выследила неприятное маленькое существо, которое вызывало взаимоблокировки во время репликации данных при оттоке. Для технических специалистов рассматриваемая ошибка была ссылкой на заблокированный для чтения узел, который сохранялся даже после того, как он был удален, и его отслеживание стало возможным благодаря текущей работе по устранению многопоточности и упрощению кода. Таким образом, мы подумали, что сейчас самое время рассказать людям о работе, которую мы делаем в sn_node, в этом и других аспектах. @joshuef берет на себя управление на этой неделе.

Общий прогресс

@yogesh занимается рефакторингом кодовой базы, чтобы избавиться от SledDB. Как упоминалось в предыдущих обновлениях, мы собирались заменить SledDB (для хранения регистров), поскольку у нее были проблемы с ограничениями на запись, а также она не поддерживалась активно. Поэтому в предыдущие недели мы протестировали несколько альтернатив, каждая из которых имела свои плюсы и минусы. В результате анализа команда решила использовать внутреннее дисковое хранилище, которое мы уже используем для хранения фрагментов. Это keep-it-simple реализация, в которой нет наворотов и которая работает наравне с другими альтернативами, в то же время освобождая нас от другой внешней зависимости, которая может не поддерживаться супер. В настоящее время он поддерживает только хранение фрагментов и поэтому нуждается в обновлении для поддержки хранения регистров, над чем работа идет полным ходом.

@qi_ma просматривал тесты оттока, которые были неудачными и медленными, отчасти, как мы думаем, из-за ошибки, описанной во введении (и ниже). Клиентам также были отправлены ложные сообщения, которые вполне могут быть частью той же проблемы.

Также на этой неделе @Heather_Burns триумфально вернулась после чумы в парламент Великобритании, где она представляла MaidSafe на круглом столе малых технологических компаний и стартапов, которые могут нанести побочный ущерб в решимости правительства регулировать интернет вокруг Facebook. Хизер сообщает, что члены парламента, с которыми она встречалась, — одни из немногих, кто на самом деле «понимает это» и хочет предотвратить это, так что, надеюсь, наше сообщение было услышано громко и ясно. Непреднамеренно она могла также разрушить правительство. Упс.

Состояние узла

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

Вот небольшой обзор состояния узлов:

Меньше замков

В последние недели мы перевели узел на однопоточную настройку. Это якобы не оказало большого влияния на производительность (хотя немного улучшило ситуацию), но цель здесь заключалась в упрощении базы кода. Поскольку нужно беспокоиться только об одном потоке (по умолчанию… мы можем порождать другие по мере необходимости), нам не нужно иметь столько сдержек и противовесов по всему коду, чтобы он мог работать параллельным образом.

Самым ярким примером этого является возможность удалить RwLocks (блокировки чтения-записи) из кодовой базы. Эти крошечные структуры позволяют коду ждать, пока данный фрагмент данных не будет изменен в другом потоке, прежде чем мы его отредактируем. Аккуратный!. Да. Но и опасно. Многие из недавних ошибок и проблем, которые мы отсортировали в sn_node, возникли из-за того, что эти ожидания продолжаются бесконечно (ситуация, которую мы называем тупиком).

Именно здесь переход к однопоточному sn_node действительно блестит, так как мы можем удалить подавляющее большинство из них из кодовой базы, а вместе с ними мы избавимся от целого класса ошибок (и очень болезненных для отладки ошибок!). Таким образом, код не только чище, яснее и разумнее, но и менее подвержен ошибкам при загрузке!

Сейчас мы прошли ~80% пути. Удалив множество блокировок внутренних структур node и заменив их одной блокировкой более высокого уровня, рассуждать намного проще (хотя переход действительно привел к еще одной тупиковой ситуации!). Хороший пример того, как простота трансформируется в скорость, можно увидеть в некоторых наших Benchmarks.

Это большая победа.

Тестовые сети

Еще одна область, над улучшением которой мы работали и будем продолжать работать, — это тестовые сети и отладка. Некоторые ошибки тестовой сети были результатом сбоя инфраструктуры, например, скажем, мы запустили дроплет DigitalOcean, но узел по какой-то причине не запустился там должным образом. Недавние изменения сделали перезапуск узлов более стабильным, а также убрали код фонового зацикливания, что должно помочь в подобных ситуациях.

Мы также стремимся улучшить ситуацию с журналированием, чтобы некоторые более четкие журналы Cmd выводились отдельно от более подробных журналов выполнения. Их должно быть легче анализировать для людей, и, надеюсь, мы сможем подключить их к экземпляру ElasticSearch, который у нас есть для внутренних тестовых сетей.

Членство

Членство продолжает улучшаться, хотя это было задержано однопоточным переключателем. Мы стремимся сократить разрыв между тем, что узлы понимают и за что голосуют, и тем, что используется в рамках SectionAuthorityProvider (SAP). Это также должно улучшить стабильность.

Дисфункция

Другой класс ошибок, с которым мы сейчас работаем, — это несколько более «мета» класс ошибок — узлы голосуют за другие узлы как неработающие (и, следовательно, в автономном режиме). Сделать это хорошо сложно (когда нода не работает, а когда у нее временно плохие времена?). Эта боль остро ощущается при непрерывной интеграции (CI), где машины менее мощные, поэтому иногда мы можем видеть, как узлы голосуют в автономном режиме, что может нарушить цикл тестирования…

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

Память и ЦП

С однопоточными изменениями, недавней переработкой повторной публикации данных и некоторыми упрощениями в кодовой базе узла sn_node в целом работает очень хорошо, в среднем ~ 130 МБ памяти для старших (на Mac; локальная тестовая сеть), ~ 70 МБ для взрослые люди.

Прямо сейчас любые большие всплески являются для нас чистыми красными флажками, и это действительно хорошее место, поскольку это значительно упрощает поиск причины таких проблем.

Данные

Недавнее обнаружение багов с «салазками» подорвало ощущение стабильности данных, но мы работаем над устранением этого прямо сейчас. Мы надеемся, что это изменение должно упростить и унифицировать хранение данных в sn_node, поэтому поведение должно быть более согласованным для любого типа данных.

И Таааак…

Хотя может не всегда казаться, что дела в сообществе продвигаются, учитывая, что не все видят, над чем работают и улучшаются изо дня в день, дела определенно идут в правильном направлении. Каждая тестовая сеть, которую мы раскручиваем, более стабильна (в целом), но если по какой-то причине возникает ошибка, со всеми этими недавними изменениями, а также с сервером ElasticSearch, отслеживающим статистику дроплетов, становится намного легче увидеть, в чем заключаются проблемы, и надеюсь тоже будет только легче!


Полезные ссылки

Не стесняйтесь отвечать ниже со ссылками на переводы этого обновления для разработчиков, и модераторы добавят их сюда.

Как проект с открытым исходным кодом, мы всегда ждем отзывов, комментариев и предложений сообщества - так что не стесняйтесь, присоединяйтесь и давайте вместе создадим безопасную сеть!