#dev (ilita) | Обсуждение разработки I2Pd | i2pd development discussion | http://i2pd.website/

Vort посмотрел я изменения последних двух коммитов

Vort во-первых, мне кажется, что в слове Appling опечатка

Vort во-вторых, лаги остались, на примерно таком же уровне, что и раньше

Vort но поменялся их характер

Vort раньше лаг чаще попадал в блок с единственным пакетом

Vort теперь же чаще лагают кучи размером побольше

Vort раньше лаг в блоке с одним пакетом приводил к сильному накоплению очереди

Vort теперь лаги накапливают очередь слабее

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

Vort но что могу сказать точно - надо искать дальше источники лагов

Vort хех. начал писать код в Visual Studio и характер лагов стал таким же, как и при прошлом тесте

Vort эффекта от предпоследнего коммита не видно - все три вызова PopulateRouterInfoBuffer в SSU2Session как лагали, так и лагают

orignal ну хначит надо смотреть дальше

Vort насчёт последнего коммита и оставшихся лагов я пока в сомнениях

orignal в любом случае убрать обращение к диску из треда полезно

Vort это ты про профили сейчас говоришь?

un 'однако, выводы эти неточны, так как нагрузка на мой узел нестабильна.' <<< это долгий процесс тестирование и наблюдение

orignal PopulateRouterInfoBuffer это была не починка как таковая а уменьшение числа

un главное не дергаться. спешка только при ловле блох.

orignal да про профили

un :) особенно с сетью

orignal про PoulateRouterInfoBuffer тут думать надо

orignal при каком сценрий возможно загрзука буфера без соединения

orignal Applying поправилю

Vort вот ещё пример нестабильности: при прошлых тестах PoulateRouterInfoBuffer был не главным источником лагов. теперь же - главный. то ли последний коммит помог, то ли нагрузка поменялась

orignal вопрос тут в другом как часто возникает переполнение SSU2 очереди

orignal если уменьшить котсанту ту с 2500 скажем до 250

Vort ну вот когда чтение RI у меня на 10 секунд залагало, тогда и возникло переполнение :)

orignal одного RI на 10 секунд?

Vort ну да, я же показывал строчку из лога

orignal как такое может быть?

Vort компиляция в Visual Studio наверно все ресурсы сожрала тогда

Vort я же собирал одни логи и писал сбор вторых логов :)

orignal надо (как говорит Путин) посмотреть в каком случае RI подгужается без существующего соединения

orignal я что то не могу сообразить

Vort имеешь в виду случаи, когда требуется вызов PopulateRouterInfoBuffer ?

orignal да

orignal ну то есть он вызывается часто но там не должно быть загрузхи

orignal с диска

orignal if (r->GetBuffer ()) return true;

orignal return r->LoadBuffer (m_Storage.Path (r->GetIdentHashBase64 ()));

orignal то есть когда проваливается в LoadBuffer

Vort PopulateRouterInfoBuffer в случае "case 1: // Bob from Alice" кстати довольно редко случается

Vort в основном лаги лезут из "case 3: // Bob from Charlie" и "// send relay intro to Charlie"

orignal и вот это не понятно

orignal ибо там должны быть установленные соединрения везде

Vort по логике RI Чарли должен быть загружен?

orignal ты смотришь просто вызовы или LoadBuffer?

orignal по логике он должен быть в памяти когда есть соединение

Vort я по разному делал. сейчас я тупо смотрю на время выполнения вот этой строчки

Vort if (r && (r->IsUnreachable () || !i2p::data::netdb.PopulateRouterInfoBuffer (r))) r = nullptr;

Vort если больше 10мс, то пишу в лог

orignal а не может быть больше 10 мс потому что треду этому проц не дается?

orignal я бы проверял частоту вызовов LoadBuffer

Vort это случается слишком часто и слишком надолго

Vort точнее даже не так

Vort среди всех лагов, в этих местах лаги самые частые

Vort вокруг LoadBuffer я тоже логирование ставил

Vort сейчас просто поменял метод

Vort ну и там же не только около 10мс. вот к примеру такое бывает: SSU2Checkpoint 55 delta 140563 us / HandleReceivedPacketsQueue size 1 duration 140775 us

Vort то есть, 99.9% времени лага попало именно на ту строчку

orignal тогда буду думать

orignal почему вообще LoadBuffer вызывается

Vort "<~orignal> по логике он должен быть в памяти когда есть соединение" пир тесты считаются за полноценные соединения?

Vort я просто помню, что там какие-то специальные состояния были у сессий

orignal ну есть пир тесты от чарли к алисе без сессии

orignal но тут то зачем RI?

orignal точнее RI нужен не нужен буфер

Vort окей, понял

orignal кроме того он прилетает от боба

orignal аналогично с HolePunch

Vort посмотрел я ещё на логи и делаю вывод, что вопрос про LoadBuffer таки самый главный сейчас

Vort остальные источники могут быть действительно из-за того, что ОС отняла процессор не вовремя. а вот LoadBuffer явно "светится" в логах

orignal вот это надо понять почему требуется его прогружать если он не должен брасываться

orignal так а если закомментрирвать вот эту строчку

orignal void DeleteBuffer () { m_Buffer = nullptr; m_IsBufferScheduledToDelete = false; };

orignal в RouterInfo.h

orignal m_Buffer = nullptr;

orignal чтобы гарантированно не сбрасылвался

Vort ок, сейчас сделаю

orignal тогда паяти будет жрать меньше

orignal *больше

orignal но LoadBuffer вообще не должен вызываться

Vort то есть, вопрос в том, уберёт ли это лаги в строчках с PopulateRouterInfoBuffer ?

Vort в общем, собираю бинарник с /*m_Buffer = nullptr;*/, посмотрю на эффект

orignal да

orignal именно так

Vort с обрезанным DeleteBuffer пока что за 20 минут ни разу не залагало около PopulateRouterInfoBuffer. при прошлом тесте за такое же время уже 17 лагов было там

orignal ага

orignal значит надо ращбираться почему вообще дроп происходит

orignal короче

orignal мы при старте зануляем буфер

orignal но он при утсановке соединения должен обновиться

Vort в NetDb::LoadRouterInfo есть r->DeleteBuffer ();

orignal да но оно вызывается только при старте

orignal дальше допустим мы установили соединение и сразу придет одновление

Vort не могут ли запросы приходить до того, как приходит свежий RI ?

Vort и как там вообще дела с "гонками" ?

Vort не может ли запрос на обновление RI "застрять" где-то?

orignal может наверное но все это должно быстро просраться

orignal грубо говоря через час на флудфиле этого быть не должно

orignal тут логика какая

orignal новый RI всегда прилетает в SessionConfirmed

orignal а боб первым шлет свой RI

orignal if (sendDatabaseStore)

orignal session->SendLocalRouterInfo ();

orignal в PeerConnected

Vort в таком случае подозрение на m_Peers

Vort это не там ли случаем хаос с мьютексами?

orignal гонка разумеется может быть в SessionConfirmed между auto ri1 = i2p::data::netdb.AddRouterInfo (ri->GetBuffer (), ri->GetBufferLen ());

orignal и PeerConnected

orignal если в этот момент из NetDB будет сброс на диск то вполне

orignal соотвественно

orignal надо сброс буфера включать только через время

orignal что я и намерен сделать

Vort так что получается - пир отключился, буфер сбросился, пир подключился, буфер обновиться не успел, но уже пришёл запрос?

Vort кстати. там около строчки "// update RouterInfo in netdb" я тоже лаги замечал

Vort и около ExtractRouterInfo

Vort но не настолько явные, как возле PopulateRouterInfoBuffer

Vort при выключении узла особо лагало там

Vort наверно как раз из-за сбросов

orignal ну там скорее всего мьютекс

orignal а вот задержку сброса да надо бы сделать

Vort так в чём смысл идеи задержки сброса? я так понимал ситуацию, что сброс мог быть в условно-далёком прошлом, а вот когда пришло время записать (обновить) свежий буфер, тогда случается гонка

Vort "<~orignal> ну там скорее всего мьютекс" который ждёт копирование буферов? вполне соответствует. в этом месте лаги где-то 30-60мс

orignal смысл в том что мы смотрим

orignal если обновление роутера свежее то не удалячем

orignal с тем мьютексом это след шаг

orignal я думаю не сделать ли мне на каждлый RouterInfo отдельный мьютекс

orignal это решит проблема

Vort да ну если там реально не больше 100мс, то это не приоритетно

Vort "<~orignal> если обновление роутера свежее то не удалячем" то есть это только уменьшит шанс попасть на лаг?

orignal нет

orignal если у тебя лаг между получением роутера в SecssionConfirmed и вызовом PeerConnected

orignal то секундная задрежка решит проболему

Vort ок

orignal о и да надо это флаг сбрасмывать при обвнлении

orignal m_IsBufferScheduledToDelete

orignal и скорее всего дело в этом

orignal мы флаг поставили обновление пришло а флаг отсается и сбрасывается

orignal вроде нормально там сбрасываю

orignal нашел я ошибку

orignal r->SetUpdated (false);

orignal updatedCount++;

orignal continue;

orignal вот и ответ

orignal поправил

orignal счас должно стать нормально

Vort поставил тестироваться

Vort orignal: функция CancelBufferToDelete осталась без дела?

orignal пока да

orignal но не надолго ))

Vort пулл реквест на гитхабе про работу с буферами видел?

orignal еще нет

orignal я не вижу разницы

Vort я не разобрался, в чём там дело

Vort наверно предупреждения у какого-то компилятора лезут

Vort так что если хуже не стало, то можно и влить

Vort но только проверить хорошо...

orignal тот тип тоже

orignal а я знаю в чем дело

orignal позже

Vort гуглёж подсказывает, что это cppcheck такое выдавать любит

orignal я думаю закрыть нахуй

orignal он там хуйни написал

orignal как же заебили все эти ИИ и анализаторы кода

orignal главное вот чувак бы хоть головой то подумал но зачем?

Vort ну вообще-то иногда такие инструменты всё же помогают находить ошибки

Vort но отличить правильное срабатывание от ложного часто довольно сложно

orignal ну вот он бы хоть сколько то подумал

orignal нахуя переделывать размер на то что копируется а не куда

orignal проблема не в интрументах а в людяъ которые их используют а потом как попугаи говорят "попка дурак"

Vort этот инструмент - не ИИ, поэтому рандомные глюки исключены и его явно что-то триггернуло. если там ошибки нету, то значит два варианта: или код написан непонятно, или инструмент баганутый

orignal ну так понятно что mempcy идет в буфер меньшего размера чем буфер

orignal потому и ругается

Vort то есть, переполнение сделано намеренно?

orignal это не переполнение

orignal вот смотри

orignal uint8_t publicKey[256];

orignal uint8_t signingKey[128];

orignal uint8_t certificate[3];

orignal там так объявлено

orignal я просто копирую в publicKey 387 байт

orignal одним memcpy

orignal потому что я точно знаю как там память расположена

orignal что так с LoadBuffer?

Vort этот код явно можно переписать понятнее. сразу только не соображу, как

Vort memcpy(this может?

orignal можно сделать union

orignal mcemcpy(this рисковано

orignal тут реально можно получить UB

Vort понял

orignal хотя наверное нет

orignal да с this будет нормально

Vort "<~orignal> что так с LoadBuffer?" ушли лаги около PopulateRouterInfoBuffer

orignal то есть это просто была моя бага

Vort осталась всякая фигня, за которой я сейчас гоняться не хочу

orignal и не надо

Vort на всякий случай опубликую мой извращённый метод ловли этого бага

Vort вдруг кому понадобится

onon congrat

Vort [хренова туча чекпоинтов]: github.com/Vort/i2pd/commit/f91cdfbf0614720bcc69962c19d9589e61176607

orignal надо будет еще в тоннельном треде переделать чтобы не грузились профили с диска