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

Вывод 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

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

Посмотрите, как часто делает fsync процесс.

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

Не знаю. Как вариант — запустите из-под eatmydata. Если всё заметно ускорится, то дело в fsync.

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

Диск hdd или ssd?

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

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

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

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

hdd.

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

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

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

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

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

Ok. Попробую чуть позже.

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

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

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

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

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

Но если он тормозит раз в 10 быстрее, то уже неплохо.

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

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

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

В каком формате там индексы?

Это вряд ли.

Всё же попробуй:

cd you-path
time find -type f | wc -l

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

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

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

Более новая

$file file position.glass 
position.glass: data

Так там вообще мало файлов

$ time find -type f | wc -l
6

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

: data

Дай тогда:

$ head -c 16 position.baseA

6

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

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

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

Они сгруппированы в 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 - так что тут тоже не может быть узкого места.

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

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

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

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

for tzip in *.zip; do unzip -t "$tzip"; done

Тогда уж так

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

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

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

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

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

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

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

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

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

Тогда бы ошибки в strace вылезли.

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

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

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

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

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

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

Ну машина мне не светит, я тут сам за себя.

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

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

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

если не секрет?

Не секрет. Всё уже давно в топе.

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

Там ни слова, кроме бесполезных размеров.

Там ни слова, кроме бесполезных размеров.

Тебя прям носом тыкать надо, чтоле?

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

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

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

Что там внутри. Может, 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 должен где-то минимум на порядок ускорить произвольный доступ.

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

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