LINUX.ORG.RU
ФорумTalks

Приключения с полнотекстовым поиском recoll. Или SSD и всё, всё, всё

 , ,


0

2

Я уже пару раз создавал темы на LOR:

(ещё в 2015) Фризы системы, iotop 99.99% но W/R = 0

(и 5 дней назад) Во что упирается индексатор recall/xapian

В 2015-м году я так и не разобрался, забросил. Сейчас кажется до истины дошёл. Просто история успеха или неуспеха, как считать.

Индексируется для локального поиска порядка 500 тысяч разных документов, общим объёмом где-то более 600Гб в пожатом виде. Хранятся внутри .zip, zip в свою очередь в более крупных.

Ещё в 2015 году столкнулся с большими и нарастающими тормозами из-за чего процесс стал занимать недели и я даже не дождался после примерно как раз недели общего времени. За которое было проиндексировано менее половины.

Сейчас с новыми версиями на новых дисках примерно тоже самое. Какие были советы можно почитать в вышеприведенных темах.

В общем, я наконец-то прикупил SSD - Samsung EVO 860 на 500 Гб., отформатировал в XFS и поместил туда индексы. «Процесс пошёл» куда резвее и уже за 15 минут было проиндексировано 14 тысяч документов.

Однако, замедление стало и тут заметно! Не так явно как на HDD, но тоже. Даже составил таблицу:

Обработано док-вВремя, мин.Файлов/сек
140001515.5
200003011.1
30000575.8
34000678.4
40000887.5
500001216.9
550001396.6
565511456.5

Как можно видеть скорость падает, не считая не совсем понятной аномалии в районе 30 тысяч.

Что интереснее, по мере падения скорости, растёт объем записываемых данных на SSD. При примерно равном общем занятом объёме. Общее количество записанных гигабайт берётся из SMART для SSD (поле 241 Total_LBAs_Written) затем * 512/1024/1024/1024) = Gb

Обработано док-вЗаписано на SSD, Гбdu -sh в Гб
2650022423
2806024823
3000027923
3200030924
3400033923
3800041224
4000044524
5000062328
5500071833
5655175130

Итак за 2 часа 25 минут на SSD было записано уже 751 Гб.
Что это не случайно показывает команда iotop -obPat в которой можно посмотреть, что процесс recollindex записал уже 261 Гб за 39 минут после возобновления индексации. (прочитал 25 Гб за это же время)

Причём из таблицы следует, что объём перезаписываемых данных всё время растёт. В районе 14 тысяч файлов 1Гб набирался на 118 обработанных файлов. К 56 тысячам уже 1 Гб перезаписи генерируют 75 файлов.

Оставлю-ка я до утра.

Мораль сей басни или какие предсказания:

  1. Справится ли SSD или тоже упрётся в потолок производительности, как и HDD?

  2. Насколько мне хватит SSD? вот так вот одна единственная программка и хренак ресурса нет ;-)) Чую полная обработка будет стоить как бы не менее 10% от гарантийных 300 TBW

  3. Как-то я недооценивал важность SSD

  4. Можно ли сказать, что архитектура recoll/xapian кривая, косая?

  5. Смех, смехом, но как бы не тот случай, когда Optane 900p имеет преимущество. Или во всяком случае что-то серверное с большим количеством циклов перезаписи. Обычных SSD с их ресурсом мало для разных там recoll’ов.

★★★★★

Последнее исправление: anonymous_incognito (всего исправлений: 3)

Ответ на: комментарий от crypt

Ну как ты будешь распространять эту свою ФС со сжатием? Этот архив, если что просто скаченное в интернете, а не какая-нибудь энтерпрайзная система.

anonymous_incognito ★★★★★
() автор топика
Ответ на: комментарий от anonymous_incognito

тем более бред какой-то. распространять один архив в 600Гб? что за дибилизм? если ты его индексируешь, то чтобы люди в нем находили что-то нужное. если находить что-то нужное, то и скачивать нужно давать кусками.

crypt ★★★★★
()
Последнее исправление: crypt (всего исправлений: 1)
Ответ на: комментарий от pekmop1024

на флибусту похоже)

может, он просто стихи любит писать:)

crypt ★★★★★
()
Ответ на: комментарий от anonymous_incognito

Этот архив, если что просто скаченное в интернете, а не какая-нибудь энтерпрайзная система.

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

crypt ★★★★★
()
Ответ на: комментарий от anonymous_incognito

как ты будешь распространять эту свою ФС со сжатием

да тот же nginx может отдавать в сеть пожатые файлы. зачем этот бред с зипами в 2020 году.

crypt ★★★★★
()

да причём здесь recoll.
ФС какая? падика бтрфс? и планировщик io и приоритетов в современном ядре сломан нахер.

darkenshvein ★★★★★
()
Ответ на: комментарий от darkenshvein

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

crypt ★★★★★
()
Ответ на: комментарий от crypt

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

darkenshvein ★★★★★
()
Ответ на: комментарий от darkenshvein

я не знаю, что за рекол, но ты с ТС явно любишь один вид порно. можете вечерком с пивком собираться...

crypt ★★★★★
()
Ответ на: комментарий от crypt

да тот же nginx может отдавать в сеть пожатые файлы. зачем этот бред с зипами в 2020 году.

Ты вообще не представляешь о чём речь. Такие вещи в таком объёме отдаются не nginx’ом, а торрентами. Ибо трафик.

anonymous_incognito ★★★★★
() автор топика
Ответ на: комментарий от crypt

Ты выносишь очень ценное мнение, не зная подробностей. Человек тебе сказал, что индексировал пару сетевых библиотек.

Теперь слушаю как он их должен был получить nginx’ом и в какую БД и каким софтом запихать.

anonymous_incognito ★★★★★
() автор топика
Последнее исправление: anonymous_incognito (всего исправлений: 1)
Ответ на: комментарий от darkenshvein

индексатор где то недели две возился, вместе с рар/зип арзхивами пыхтел.

Ну вот это и не правильно на мой вкус. Хорошая система индексации должна по моим представлениям потратить не более, чем ну суток на Тб максимум.

anonymous_incognito ★★★★★
() автор топика
Ответ на: комментарий от darkenshvein

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

anonymous_incognito ★★★★★
() автор топика
Последнее исправление: anonymous_incognito (всего исправлений: 1)
Ответ на: комментарий от anonymous_incognito

Ты вообще не представляешь о чём речь.

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

crypt ★★★★★
()
Ответ на: комментарий от anonymous_incognito

Ещё в 2015 году столкнулся с большими и нарастающими тормозами

дак я не понял тогда, на что ты грешишь, что движок реколла после пачки апдейтов стал кривее, или что дисковый планировщик(ну и процессов до кучи) стал кривее?

darkenshvein ★★★★★
()
Последнее исправление: darkenshvein (всего исправлений: 1)
Ответ на: комментарий от darkenshvein

Некоторые простые вещи настолько просты, что иногда не сразу до них додумываешься. Но когда я замерил поток на запись, стало понятно, что recoll (или xapian скорее) похоже непрерывно перезаписывает индексы. И по мере роста количества проиндексированных файлов растёт и объём перезаписи индексов.

Возможно сортируя их каждый раз, но это уже догадка.

И вот это трудно назвать правильной архитектурой и именно на это уходит всё время работы. Причём пока размер исходного файла для индексации не превысил примерно 30Гб и 15 000 файлов оно как бы и всё нормально по большому счёту. Но вот более - ты говоришь две недели индексировал (интересно на ssd или нет?)

Это совсем не то, что можно использовать для больших массивов данных и тут никакой оптан не поможет, даже если под индексы вообще RAM-диск использовать, на каком-то объёме и он затыкаться будет.

Обидно ещё, что в принципе по своему интерфейсу, «всеядности» к файловым формату recoll неплохая вещь.

anonymous_incognito ★★★★★
() автор топика
Последнее исправление: anonymous_incognito (всего исправлений: 2)
Ответ на: комментарий от crypt

Ну я же описал вначале объект который индексируется. Объект не я создаю.

Задача легко и быстро его проиндексировать для полнотекстового поиска. recoll хорош тем, что готовый.

Как бы аналог таких программ как Google Desktop Search и т.п.

Например, для lucene почему-то не нашёл устраивающего готового варианта.

anonymous_incognito ★★★★★
() автор топика
Ответ на: комментарий от crypt

Ну представь себе, что ты скачиваешь, как сказал darkenshvein, электронную библиотеку и хочешь локально в ней искать что-то полнотекстово.

anonymous_incognito ★★★★★
() автор топика
Ответ на: комментарий от crypt

Ну почему регулярно? Хотя тоже интересный юзкейс.

Для этих целей давно были придуманы системы полнотекстового поиска среди файлов. Некоторые ещё с 1991-го года развиваются, например, http://www.dtsearch.com/index.html

Где-то в начале 2000-х вообще был зоопарк из них.

anonymous_incognito ★★★★★
() автор топика
Последнее исправление: anonymous_incognito (всего исправлений: 1)
Ответ на: комментарий от anonymous_incognito

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

ок, то есть ты свою библиотеку скачал, а конвертировать из зипов в какую-нибудь систему не хочешь, потому что продолжаешь ее раздавать торрентами?

crypt ★★★★★
()
Ответ на: комментарий от crypt

Я не скачивал библиотеку и тем более не раздаю её, а задачу индексирования я просто с 2015 года так и не сделал даже один раз. Понимаю, кажется странным, но почему бы нет? Особо не нужно, скорее любопытство. Тогда были и другие дела, сейчас решил в конце-концов разобраться.

Но такое ощущение, что хоть свою программу для индексации пиши.

anonymous_incognito ★★★★★
() автор топика
Ответ на: комментарий от anonymous_incognito

Ну представь себе, что ты скачиваешь, как сказал darkenshvein, электронную библиотеку

Я не скачивал библиотеку

мда. ты уж определись, хочешь ты поделиться, что там у тебя или хочешь оставить в секрете.

crypt ★★★★★
()
Ответ на: комментарий от crypt

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

anonymous_incognito ★★★★★
() автор топика
Ответ на: комментарий от anonymous_incognito

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

OxiD ★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.