LINUX.ORG.RU

Во что упирается индексатор recall/xapian

 full text search, ,


0

1

Пытаюсь проиндексировать для целей полнотекстового поиска около 500 тысяч файлов разного размера ( в среднем около 500 Кб, но есть и меньше и много гигабайт).

Картина следующая. recoll с нуля бодро стартует и где-то первые 2000 добавляет влёт. iotop показывает скорость R/W диска в 50-100Мб/сек. Загрузка CPU - под 300% в top’е.

Постепенно скорость снижается, к 3000-м до 10-20 Мб/сек, к 4000-м до 2-3 Мб/сек и после 10 000 в основном медленная тошниловка около 500 Кб/сек. CPU не загружен, память свободная.

Вывод iostat -x atop для диска, где индексы создаются

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           5.42    7.99   12.52    2.11    0.00   71.97

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sdb               0.00    13.61    0.06    3.83     0.54    88.14    45.57     2.09  536.68  175.03  542.32   2.31   0.90

Для диска на котором тексты лежат

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           5.41    7.97   12.49    2.14    0.00   71.99

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sdc               0.05     0.00    1.74    0.01   227.27     1.94   263.20     0.01    2.95    2.72   67.41   1.18   0.21

Вроде ничего такого.

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

А как посмотреть, что-то не помню. В смысле, чтобы не анализом логов strace, а может можно какой утилитой сразу.

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

Поначалу вроде быстрее, но не сильно. То есть, похоже fsync играют заметную роль, но что-то ещё с диском тормозное делается.

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

чтобы не анализом логов strace

У strace есть ключ -c, который сгенерирует табличку с количеством использованных системных вызовов. Подцепляешься к процессу через -p, ждёшь минуту, Ctrl-C, получаешь отчёт.

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

А индексируешь как? Рекомендуют так:

https://www.kv.by/content/320192-indeksatsiya-i-poisk-v-ubuntu-posredstvom-recoll Разумеется, индексирование может быть и фоновым, и автоматическим, Однако, для настроек скрытого индексирования реального времени используется CLI. Если будут пожелания от «неанглоязычных» читателей «Вестей» (интересно, а есть ли такие?), я в одной из своих следующих статей попробую рассказать об этом по-русски и подробно. Забегая вперёд, скажу только, что демон непрерывного фонового индексирования, который умно и быстро отслеживает все изменения в проиндексированных папках, запускается командой recollindex -m

anonymous
()
Ответ на: комментарий от Deleted

hdd.

Вообще, я ещё почему к оптанам приглядывался. Возникло подозрение, что это hdd принципиально тормозит на мелких операциях. Сейчас чем больше думаю, тем больше похоже, что так. Потому что ну нечему больше. Диски разные, ОС разные (впервые ещё несколько лет назад пробовал, но забросил тогда). Есть конечно вариант каких-то программных глюков.

Однако похоже 280Гб оптана будет мало по-любому =) А на 480 и тем более терабайтную версию денег всё же нет.

Тут ещё что получается. Я как-то SSD вообще до сих пор мимо пропустил. Ну не стремился ускорить загрузку ОС, в остальном как бы и некритично было. Большие проекты не компилировал и всё такое.

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

Принципиальная особенность в том, что дешёвые диски видимо предназначают под такие нагрузки как загрузка ОС и программ, то есть, что-то непрерывано длящееся максимум минуту-другую с длительными перерывами,а тут вроде получается непрерывная работа на несколько часов.

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

А индексируешь как? Рекомендуют так:

Запустил и напустил Update Index на сборище файлов. Смотрю и жду что получается.

Хочешь сказать, что он просто сам уменьшает скорость? Непохоже. Диск с индексами при этом тормозит. То есть, попытка параллельно записать на него что-то (даже мелкий файл) может задержаться на десятки секунд даже.

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

Возникло подозрение, что это hdd принципиально тормозит на мелких операциях.

ssd тоже тормозит на мелких операциях, если что :)

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

то уже неплохо.

Мож тебе надо dirtree тряхануть. Только это уже будет зависеть от фс.

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

Это вряд ли. Ну то есть, какой-то процент может и можно выжать, но скорее всего, как я теперь понимаю, дело просто в апдейтах файлов базы мелкими порциями, образующимися при индексации документов.

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

Даже не понял что сказать про формат.

На предыдущей версии xapian/recoll

$file position.baseA
position.baseA: data[/code]

Более новая

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

6

Ты в какой дирректории?

Пытаюсь проиндексировать для целей полнотекстового поиска около 500 тысяч файлов разного размера

Вот в этой надо, где 500 тысяч.

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

Они сгруппированы в zip-файлы, в которых свои zip могут быть. Но я же говорю, что какое-то время по-любому быстро всё. Два каталога индексируются.

$ time find -type f | wc -l
182

real	0m0.003s
user	0m0.000s
sys	0m0.000s

$ time find -type f | wc -l
3917

real	0m2.187s
user	0m0.012s
sys	0m0.056s

Да, /tmp у меня в tmpfs - так что тут тоже не может быть узкого места.

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

Они сгруппированы в zip-файлы, в которых свои zip могут быть.

Эммм. Какбэ сам пользую fusecompress, поэтому отлично знаю, насколько небыстро такая канитель работает. При этом говоришь, что проц «отдыхает». Но этого не мож быть, потому как независимо от того насколько медленен твой индексатор, распаковка медленней.

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

Они сгруппированы в zip-файлы

Ты мож свои zip-ы хотя бы на нулевом уровне прошманать?:

for tzip in *.zip; do unzip -t "$tzip"; done
anonymous
()
Ответ на: комментарий от anonymous

Тогда уж так

head -c 16 position.glass |hexdump
0000000 0000 0600 0900 093c 013c 1faf 1fe3 1fc6
0000010

head -c 16 position.baseA |hexdump
0000000 1ca8 8005 cd40 94ce 0306 cfec 8562 c39b
0000010

Ибо нечитаемо в ascii

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

А что это даёт? Сколько всего файлов я и так знаю. Скорость распаковки уж поверь на порядки быстрее индексации. В конце-концов, когда первые несколько тысяч файлов индексируются за 15 минут, а потом явно медленнее не зависит от исходных.

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

Ибо нечитаемо в ascii

Ну если нет «волшебства» то и hex тоже в принципе не нужен.

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

А что это даёт?

Меня настораживает что проц «отдыхает». Как будто часть потоков зависает. А на чём зависает? Узнать мож только методом тыка.

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

Так я же говорил, тормозит диск при этом. Вплоть до того, что параллельно ничего не записать на него несколько секунд. Раньше даже тему создавал про «фризы». Тогда показалось было, что замена ext4 на xfs решает, но ошибался.

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

тормозит диск при этом

А уверен, что это не попытки тех самых «зависших» потоков прочитать то, что прочитать они не могут?

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

Тогда бы ошибки

Если что-то не работает, то скорее всего оно сломалось. И вопрос уже не «как?», а «где?».

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

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

У меня друг за такой лайфхак несколько лет назад в одной крупной компании машину премией получил. Рекомендую.

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

Пока что так и не нашёл, где бы ошибки были.

Вообще, если не пытаться в recoll засунуть несколько сотен гигабайт, где-то 20-50Гб он относительно шустро обработает.

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

Даже не понял что сказать про формат.

Что там внутри. Может, sqlite3 убогий, вот и тупит. А может какой-то особый велосипед, который никогда и не тестили на больших объёмах.

Что за файлы индексируются, если не секрет?

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

Может быть дело в какой-то из прог. которые он вызывает для чтения содержимого файлов (ЕМНИП их вроде можно менять)?

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

И ещё. У меня он проседал когда ставил индексировать весь хомяк. Конкретно - на кэшах браузера.

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

Это индексы, а не индексируемые файлы. Да и в контексте индексов это довольно бесполезная информация.

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

Что там внутри. Может, sqlite3 убогий, вот и тупит.

Точно не sqlite3, там похоже что-то своё.

apt-cache depends recollcmd|grep -i depends
  Depends: libc6
  Depends: libchm1
  Depends: libgcc1
  Depends: libstdc++6
  Depends: libx11-6
  Depends: libxapian30
  Depends: libxml2
  Depends: libxslt1.1
  Depends: zlib1g

и

apt-cache depends libxapian30|grep -i depends
  Depends: libc6
  Depends: libgcc1
  Depends: libstdc++6
  Depends: libuuid1
  Depends: zlib1g

Сегодня должны принести SSD Samsung 860 Evo - посмотрю как будет со скоростью. SSD далеко не лучший, но по сравнению с HDD должен где-то минимум на порядок ускорить произвольный доступ.

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

В общем, кому интересно, дело в производительности HDD. И скорее всего кривизне recoll из-за которой бешено растёт объём перезаписываемых данных. Для 55000 обработанных документов (а всего хочу в 10 раз больше) индексные файлы занимают 33 Гб, при этом общее количество (пере)записанных данных на диск - 718 Гб. Сами документы (55000) занимают примерно 60Гб.

Создал тему в Talks где подробно описал, что стало после установки SSD Приключения с полнотекстовым поиском recoll. Или SSD и всё, всё, всё

anonymous_incognito ★★★★★
() автор топика
Последнее исправление: anonymous_incognito (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.