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

Vort orignal: тут?

Vort я таки добавил логирование в SSU2Server::HandleReceivedPacketsQueue и уже нашёл интересность

Vort обычно пачка состоит из < 10 пакетов и её обработка занимает < 100 микросекунд

Vort но иногда случается вот такая херня: paste.i2pd.xyz/?391ebab04e986adc#Cdfs9x97JTYKeprNZp5YJM7toVje7SwAmpF8qdetk4MU

Vort задержка на треть секунды - это относительная редкость. задержки на несколько секунд, которые мы вчера обсуждали - редкость ещё бОльшая

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

Vort событие по ссылке, в 17:03, хорошо совпадает с массивным сбросом RouterInfo на диск, так что, похоже, лаги всё же связаны с дисковой активностью

Vort вот ещё два таких события. 316мс и 227мс: paste.i2pd.xyz/?0cf2386053ed4c15#29zbBJqBs3cCpT2AsZiHMrNZfH3Aj7hwV5Vqk7NWqUjH

` >... так что, похоже, лаги всё же связаны с дисковой активностью

` Неужели я дождусь хотя бы в виде режима, когда ш2зв выгружается и крутится в ОЗУ, с периодическим (нечастым) сбрасыванием всякого netdb на диськ и всё 🤔

orignal ну и какие предложения?

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

Vort главное, выяснено с высокой вероятностью, что это не перегрузка по CPU

orignal а почему ты думаешь что задерки по 1000 миллисекунд это не обрабюотка?

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

orignal там же в netdb мьютекс

orignal элементарно ватсон

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

orignal так ответ понятен

orignal надо разбираться с мьютексами

Vort угу. но это территория архитектуры, так что тут я мало чем могу помочь

orignal ну я понимаю это вопрос ко мне

orignal кстати такая же ботва будет в NTCP2

orignal отлично что нашел

orignal буду смотреть

orignal void NetDb::SaveUpdated ()

orignal м std::shared_ptr<const RouterInfo> NetDb::AddRouterInfo (const IdentHash& ident, const uint8_t * buf, int len, bool& updated)

orignal там блокировки одного и того же мьютекса

orignal Vort сколько примерно у тебя роутеров в базе было?

segfault orignal: у меня много оперативки, можешь добавить netdb полностью в оперативке? чтобы оно вообще к диску не обращалось

segfault как опцию

segfault просто как огромную std::map можно сделать

un сделай рам диск и запускай i2pd с data на нем

segfault <~orignal> если сброс RI на диск даже понятно почему

segfault <~orignal> там же в netdb мьютекс

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

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

un проблемы с дисковым ио на винде? на лине должно быть - там все в кеше который в памяти

un если тока рамы мало совсем

un как на чайнике

segfault un: тут скорее проблема в том, что нужно сделать тяжёлый системный вызов write

segfault un: он обработается, когда ос захочет

segfault и пока она не захочет поток будет висеть

Vort "<~orignal> Vort сколько примерно у тебя роутеров в базе было?" 10 тысяч

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

Vort конкретно для i2pd это не сильно важно, можно и заново RI скачать, а вот для других программ очень даже

Vort (те данные, что я выкладывал, я собирал со своего основного узла. то есть, флудфил с нагрузкой где-то 1 мегабайт/сек)

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