Благодарности към Spatium за 4-те заглавни изображения, които ще видите използвани през следващите седмици 
Някои обещаващи новини от фронта за лов на грешки, тъй като екипът ни проследи гадно малко създание, което причиняваше блокировки по време на репликацията на данни при напускане на възли. За по технически настроените, въпросният бъг беше препратка към заключен за четене възел, който продължаваше да съществува дори след като беше премахнат, и проследяването му стана възможно благодарение на продължаващата работа за премахване на многонишковата работа на процесора и опростяването на кода. Решихме, че това е подходящ момент да запознаем хората с работата, която вършим в sn_node. @joshuef ще ви разкаже за това тази седмица.
Общ напредък
@yogesh е готов да преработи кодовата база, за да се отървем от SledDB. Както споменахме в предишните новини, бяхме на път да заменим SledDB (за съхраняване на регистри), тъй като имаше проблеми с ограниченията за запис и също така не се поддържаше активно. Затова сравнихме няколко алтернативи през предходните седмици, като всяка имаше своите плюсове и минуси. Като резултат от анализа екипът реши да избере наша собствена разработка на дисково съхранение, което вече използваме за съхраняване на парчета данни. Това е дръж-го-просто реализация, която няма никакви екстри и се представя наравно с другите алтернативи, като същевременно ни освобождава от наличието на друга външна зависимост, която може да не е супер поддържана. Понастоящем тя поддържа само съхранение на парчета и следователно трябва да бъде преработена, за да поддържа съхранение на регистри, по което работата е в ход.
@qi_ma разглежда тестовете при напускане на възли, които са неуспешни и бавни, отчасти - според нас - поради грешката, описана във въведението (и по-долу). Имаше и фалшиви съобщения, изпратени до клиенти, които може да са част от същия проблем.
Също тази седмица, @Heather_Burns направи триумфално завръщане в парламента на Обединеното кралство, където тя представляваше MaidSafe на кръгла маса на малки технологични фирми и стартиращи фирми, които ще бъдат ощетени в решимостта на правителството да регулира интернет около Facebook. Хедър съобщава, че депутатите, с които се е срещнала, са едни от малкото, които наистина „разбират това“ и не искат това да се случва, така че се надяваме, че нашето послание беше чуто силно и ясно. По невнимание тя може да е унищожила и правителството. Опа!
Състояние на Възела
Много хора може би се чудят какво е състоянието на възела сега и защо сме поели определени задачи.
Ето кратко описание на състоянието на възлите:
По-малко заключвания
През последните седмици преместихме възела към работа с една процесорна нишка. Това привидно не оказа голямо влияние върху производителността (въпреки че подобри малко нещата), но целта тук беше да се опрости кодовата база. Със само една нишка, за която да се тревожим (по подразбиране… все пак може да създадем други, ако е необходимо), не е необходимо да имаме толкова много проверки и баланси в целия код, за да може да работи едновременно.
Най-ясният пример за това е възможността за премахване на RwLocks (блокировки за четене и запис) от кодовата база. Тези малки структури позволяват на кода да изчака, докато дадена част от данните не бъде модифицирана в друга нишка, преди да я редактираме. Чудесно!. Да. Но и опасно. Много от скорошните бъгове и проблеми, които сортирахме в sn_node, се дължат на тези чакания, които продължават за неопределено време (ситуация, която наричаме безизходица).
Именно тук преминаването към еднонишков sn_node наистина блести, тъй като можем да премахнем по-голямата част от тях от кодовата база и с тях премахваме цял клас грешки (и то наистина болезнени за отстраняване на грешки!). Така че не само кодът е по-чист, по-ясен и по-разумен, но трябва да е и по-малко податлив на грешки при зареждане!
Сега сме на ~80% от пътя за да го завършим. След като премахнахте много заключвания във вътрешните структури на възела и ги заменихте с едно заключване от по-високо ниво, сега е много по-лесно за разсъждение (въпреки че преходът доведе до друга безизходица!). Добър пример за подобренията към опроставяне се изразяват в покачване на скоростта, и може да се види в Benchmarks
Това е голяма победа.
Тестови мрежи
Друга област, в която работим за подобряване на нещата и ще продължим да го правим, са тестовите мрежи и отстраняването на грешки. Някои грешки в тестовата мрежа са резултат от проблеми с инфраструктурата, например стартирахме възел в DigitalOcean, но възелът не стартира правилно там по някаква причина. Скорошните промени направиха рестартирането на възлите по-стабилно, както и изчистиха неработещия код, което би трябвало да помогне в ситуации като тази.
Също така се стремим да подобрим ситуацията със записването на логове, с някои по-ясни Cmd логове, които ще се извеждат отделно от по-подробните логове при стартиране. Те трябва да бъдат по-лесни за анализиране от хората и, надяваме се, ще можем да ги закачим в ElasticSearch, който използваме за вътрешни тестови мрежи.
Членство
Членството продължава да се подобрява, въпреки че беше задържано, докато превключим на една процесорна нишка. Работим по затварянето на празнината между това, което възлите разбират и гласуват, и това, което се споделя в рамките на SectionAuthorityProvider (SAP). Това също трябва да подобри стабилността.
Дисфункция
Друг клас бъгове, с които сега се занимаваме, е малко по-„мета“ клас бъгове – възли, гласуващи за други възли дали са нефункционални (и съответно офлайн). Правенето на това добре е трудно (кога възелът е нефункциониращ или има временно забавяне?). Тази болка се усеща остро при непрекъсната интеграция (CI), при по-слаби компютри и затова понякога можем да видим възли, които се гласуват офлайн, което може да прекъсне тестов цикъл…
За тази цел наскоро разширихме тестовите пакети в sn_dysfunction и се стремим да продължим да разширяваме и подобряваме това, за да стигнем до възпроизводими ситуации, при които можем да знаем, че офлайн гласувания възникват поради лоши възли.
Памет и процесор
С промените към една процесорна нишка, скорошното преработване на повторното публикуване на данни и с някои опростявания в кодовата база на възела sn_node в повечето случаи работи много добре, средно ~130MB използване на памет за Старейшини (на Mac; локална тестова мрежа), ~70MB за Възрастни.
В момента всякакви големи скокове в използваната памет са ясни червени знамена за нас и това е наистина хубаво, тъй като прави намирането на причината за такива проблеми много по-лесна за откриване.
Данни
Неотдавнашното откриване на sled бъгове заглуши усещането за стабилност на данните, но работим върху премахването на това точно сега. Надяваме се тази промяна да опрости и обедини съхранението на данни в sn_node, така че поведението да бъде по-последователно във всеки тип данни.
И така…
Въпреки че не винаги може да се почувства напредъка, като се има предвид, че не всеки вижда върху какво работим и подобряваме всеки ден, нещата определено вървят в правилната посока. Всяка тестова мрежа, която завъртаме, е по-стабилна (като цяло), но ако по някаква причина има грешка, с всички тези скорошни промени, плюс със сървъра ElasticSearch, проследяващ работата на тестовите машини, става много по-лесно да се види къде се крият проблемите и надяваме се за напред също да става все по-лесно!
Преводи:
English 
Russian ; 
German ; 
Spanish ; 
French
- Официален сайт на Safe Network
- Обобщено представяне на Safe Network
- Safe Network Фундаменти
- Карта на проекта
- Подробна информация може да намерите както винаги във форума на международната общност: Safe Network Forum
- Ако имате въпроси може да ги зададете във Facebook групата на българската Safe общност: Redirecting...
- Ако искате да следите последните новини заповядайте във Facebook страницата на Safe Network България: Safe Network България