rats-search
rats-search copied to clipboard
DEgITx
Увеличение потребления CPU с размером базы.
Настроил вчера на домашей файлопомойке программу чтобы молотила. Экспериментальным путем подобрал параметры так чтобы скачки CPU были не очень частые и не доходили до 100% (это как бы не единственная задача которой занимается комп). Через некоторое время увидел что они слишком близко к 100% и подкорректировал показатели. Итого нагрузка на CPU была 30% со скачками до 60-65%. Но это вчера при ~20000 торрентов.
Сегодня я обнаружил большую нагрузку на CPU процессом searchd. Сегодня уже нагрузка только от searchd составляет от 40 до 80 процентов CPU, а при наличии других процессов график постоянно упирается в 100% нагрузки а иногда и задерживается там на несколько секунд.
Данные из проги: 0.23.0 p2p поиск - да пиров - 10 сервер репликации - да репликация - да скорость прохода - 70 узлов - 50 пакетов - 340
352,27Тб данных 122976 торрентов 3588479 файлов
Данные ПК: Размер папки с базой: 591 Мб CPU: Intel Core2Duo E8400 ОЗУ: 6Гб (-1 на рамдиск) Windows 7 Pro x64
Upd: загадочные настройки. Выкрутил скорость прохода на 3 (что судя по описанию должно увеличить нагрузку на CPU) и получил уменьшение нагрузки, хотя иногда searchd все равно скачет до больших значений. Ощущение что этот параметр в плане физической нагрузки влияет только на амплитуду - то есть нижние значения ниже, верхние почти такие же.
В общем с настройками разобрался. Решает - комплекс. То есть если снять ограничения на узлы и пакеты то и нагрузка на CPU растет. Осталось понять, действительно ли она увеличивается с размером базы потому что я после того как настроил ничего не трогал и от ПК отключился.
Хочу обратить внимание вот на какой аспект, есть разница в потреблении CPU между случаями:
- получение торрента по DHT - низкое
- получение от пиров - высокое
Сижу с врубленным системным мониттором, так вот. Когда качаются торренты от пиров, в логе появляется
replicate remote torrent <Title>
При этом скачком загрузка 1 ядра вырастает до 100% и через время падает.
А бывает другое, когда в логе
finded torrent <Title> and add to database
то нагрузка так и остается на нуле.
Думаю, это может быть подсказкой, почему тормозит, возможно два метода записи отличаются и второй работает быстрее.
Небольшая оптимизация будет уже в следующей версии 0.25.0 (в частности a84f8c7c2753e68d169b217aa78478f252551ca0)
Система стала неотзывчивой - в FAR менеджере набор символов с клавиатуры уже до нескольких секунд вызывал задержки между нажатием и появлением символов.
searchd кушал 79% процессора, 6,5 ГБ памяти (working set). Работает обмен торрентами p2p. Режим запуска: npm run server
База ~55М файлов 2.4 ПБ, размер папки с БД 7.6 ГБ.
Через sysinternals procexp уменьшил приоритет процесса searchd до 4.
Система ожила - searchd кушает 16-26% - поиск при этом только незначительно замедлился.
(кроме глобальных статистик:
select count(*) from files
делается 15-17 секунд, и никакого эффекта кеширования запросов не наблюдается - два последовательных запроса выполняются одинаково долго).
Регулярные падения из-за нехватки памяти вроде поправил аргументом запуска сервера в package.json "server": "node --max-old-space-size=8500 src/background/server.js", (памяти много, а node скромно берёт по умолчанию только 512 МБ).
если есть возможность, пришли базу целиком, там на такой базе нужно отдельно оптимизировать, у меня из-за ее отсутсвия нету возможности нормально оптимизировать на таких размерах
В 080fc92 появилась возможность отключение проверки целосности файлов при добавлении торрентов (см в настройках), это должно значительно сократить время добавления и использование cpu на базах где собрано большое количество торрентов, рекомендую там отключить
Добавил в базу свою подборку pornolab (более 700к торрентов). Отсюда и размер. И хештеги #PL в названиях торрентов (больше не придумал куда их вставить). https://yadi.sk/d/QuJBXfth3Zy6AD
` torrent.name=torrent.name.replace(/ #PL(\d+)$/,(a,g)=>{torrent.plid=g;''});
{ 'plid' in torrent ? <ListItem rightIcon={<ActionInfo />}
primaryText={__('Reference URL')}
secondaryText={<a url="http://pornolab.net/forum/viewtopic.php?t={torrent.plid}">Topic #{torrent.plid}</a>}
/> : '' }
Есть ещё базы данных по торрентам с десятками миллионов книг и научных статей. Думаю можно будет прикрутить поиск на движке p2p (скорее на мускуле - сфинкс не очень хорош для таких объёмов - запуск минут 5 идёт). Вот только там особенность, что имена файлов не отражают содержимое (как и у многих "нормальных" торрентов, кстати). У либгена имена файлов - md5 суммы (это 2,3 миллиона файлов торрентами по 1000 файлов научной литературы и учебников и ещё + 2 миллиона зарубежной художки). Тут нужно по поисковому запросу ответить инфохешем раздачи и именем файла + карточкой книги, чтобы показать пользователю - то ли это, что ему надо. Ну и ссылки на библиотеку для книги легко получить - если сидов не удастся найти. У флибусты и либрусека - торренты с архивами с цифровыми именами файлов (имена соответствуют id в базе соответствующей библиотеки), а до конкретной книжки легко можно добраться, если скачивать не целиком архив, а кусочек zip файла по смещениям, которые можно передать в поисковом ответе. Тут особенность, что сами файлы библиотек очень хорошо сидируются (десятки и сотни сидов) - но по куче разных инфохешей (разные апдейты и сборки, + есть даже каждый файл архива индивидуально - но сидов на них почти нет), причём для одних и тех же файлов (можно, конечно, найти раздачи с другими архивами - но внутри одно и то же).
У скайхаба около 55 миллионов единиц хранения (научные статьи и журналы). Торренты формируются по 100 архивов, в каждом из которых по 1000 файлов. Имена вообще практически произвольные - некий индекс doi который как-то отражает тематику, издательство, номер журнала, номера страниц. Сидируются крайне плохо (не каждый пока осилит хранение 35 терабайт), т.ч. тут точно полезно показать ссылки на страницу библиотеки (скорее даже библиотек - их около десятка). Есть ещё комиксы, которые максимально интересны той же американской аудитории (у нас как-то не особо популярны - там же миллионы фанатов). Однако их торренты предстоит только создавать. Тут проблема, что каждый комикс довольно внушительных размеров (от десятков до сотен мегабайт каждый) - соизмеримо с большими книгами научной литературой либгена - и они идут сериями как журналы скайхаба. И их реально дофига (сотни тысяч).
А может быть запилить распределённую базу данных? Она и сейчас в каком-то состоянии есть. С одной стороны надёжность хранения. С другой - доверие.
Пользователям честно говоря не нужна большая база данных, если есть способ получить что-то "из откуда-то ещё". Скорость ответов страдает и это "откуда то ещё" должно выдерживать нагрузку. А ещё легко реплицироваться и переживать потерю узлов и центра. Велосипеды на мускуле (пара табличек, ага) - довольно просто, но велосипед. МонгоДБ? Вроде для этого делался.
Оконечные пиры продолжат свою нелёгкую работу по сбору первички dht, но снимется обязанности по хранению баз торрентов, уйдёт ненадёжность репликации результатов сборов, а главное можно попробовать избежать ужасов поиска между пирами..
Помню времена, когда в едонки2000 развелась куча ботов с малварью. По поисковому запросу они генерировали действительные ed2k хеши с запрашиваемыми именами но своей малварью и отдавали клиентам ответ. Людям уровня "показали как искать - кликнул на результате" - штука очень опасная. Как сейчас seo gateway со страницами загрузок малвари и фейковыми комментариями якобы из соцсетей.
Прошу прощения, но может кто-нибудь подсказать? Как написать простой скрипт запуска для systemd? Пытаюсь вот так, да что-то не выходит:
[Unit]
Description=Rats
After=network-online.target
[Service]
Restart=on-failure
# do chdir before running the service
WorkingDirectory=/rats/rats-search
ExecStart=/usr/bin/tmux -L rats new-session -s rats -n rats -d "npm run server"
ExecStop=/usr/bin/tmux -L rats send-keys -t rats:rats C-c
# limit CPU and RAM quota for service
CPUAccounting=true
CPUQuota=30%
MemoryAccounting=true
MemoryLimit=500M
[Install]
WantedBy=multi-user.target
