Управление индексацией
leo
бы понять, можно ли управлять индексацией в ходе её выполнения?
Например, получить статистику по уже проиндексированным данным,
прервать индексацию (не потеряв результатов уже сделанной работы).
Можно ли возобновить индексацию (но чтобы она возобновилась с места её
остановки, а не с начала)?
Можно ли задать максимальное время индексации? Например, я индексирую
огромный сайт (форум) и заранее не знаю, сколько времени это займёт.
Но ставлю параметр, чтобы через Х часов индексация остановилась.
Ещё вопрос о производительности индексации. На вир.машине (1 ядро 2.4
Ггц, канал 5 мбит) скорость примерно 20 Кб/c. Это нормально или можно
как-то улучшить результат?
Maxim Zakharov
Честно говоря мне неизвестно, чтобы кто-то индексировал террабайт
данных используя DataparkSearch.
Основная проблема здесь - SQL сервер. С ростом числа
проиндексированных документов скокрость его работы падает.
Вы можете получить текущую статистику при помощи команды "indexer -S",
выполнять которую можно не останавливая процесс индексирования.
При рестарте индексирования будут индексироваться только новые и
устаревшие документы (для которых истек прериод, заданный командой
Period). Это не совсем с того же места, но уже проиндексирвоанные
страницы индексироваться не будут (опять де если не истек их Period).
Лимит индексирования по времени задается ключом -c для indexer,
который указывает число секунд работы indexer, по превышении которого
indexer акончит индексирование очередного документа и завершит свою
работу.
На скольки индексирующих нитях вы достигли скорости в 20 кбайт/с?
Скорость индексирования также зависит и от скорости работы серверов,
котоыре индексируются, поэтому лучше запускать несколько индексирующих
нитей и использовать рандомизацию выборки очередных страниц при помощи
ключа -r (или -rr), чтобы одновременно индексировались страницы с
разных сайтов.
2011/10/2 leo <bolshak...@ya.ru>:
--
http://www.dataparksearch.org/ - an open source search engine.
leo
индексом + нагрузкой (хотя бы несколько запросов в секунду). Если
выживет, то есть идея поднять на базе DataparkSearch специфический
поисковой ресурс.
Для ускорения SQL базы всё будет на ssd дисках, может быть даже с
интерфейсом pci. Ну и, понятно, многоядерный сервак.
Работал 1 поток без рандомизации. Чем отличаются параметры "r" и
"rr"?
И как правильнее завершить работу indexer? Просто kill -hup? Или есть
какие-то нюансы?
Maxim Zakharov
-r генерируется случайное число и для индексации выбираются документы,
чей seed (случайное число, генериремое при добавлении в базу
поисковика) равен этому случайному числу. При указании двух -rr
выбираются документы с seed меньшим (или большим, направление
выбирается случайным образом) случйаным образом выбранного значения.
Для завершения работы indexer ему необходимо послать сигнал -INT.
По сигналу -HUP он перечитывает файлы конфигурации и продолжает работу.
2011/10/3 leo <bolshak...@ya.ru>:
--
itJunky
В кроне стоит такое задание
30 */3 * * * /www/find.zet/dpsearch/sbin/
indexer -drW -N 3 -c 1000 > /dev/null 2>&1
Тоесть каждые три часа запускается индексер в три потока и обходит
ссылки 1000 секунд. После чего происходит запись URL и лимитов. Это
работало, причём с таймингом не 1000, а 4000, до тех пор пока
количество собранных ссылок не увеличилось до миллиона. Теперь же за
1000 секунд собирается смешное количество урлов(порядка 500-1000 на
каждый из трёх потоков), а затем почти все три оставшихся часа
происходит запись URL и лимитов.... Причём замечено, что этот
последний этап занимает примерно одно и то же время вне зависимости от
того собрал ли я 3000 урлов или 15000... Конечно, время обработки
слегка увеличивается, если количество собранных урлов увеличивать в
раз или два раза, но не значительно.
Отсюа вопрос, как бы так красивее это организовать? Собирать урлы весь
день и потом всю ночь их обрабатывать можно, но слишком долгим будет
время обновления выдачи, получится примерно раз в сутки. Есть ли
способы как-то оптимизировать этот момент?
itJunky
параметрами:
dpsearch@find ~ $ /www/find.zet/dpsearch/sbin/indexer -mr -N 15 -n
100000
А вот результат:
indexer[25828]: {12} Done (91388 seconds, 6257 documents, 171892216
bytes, 1.84 Kbytes/sec.)
indexer[25828]: {05} Done (91376 seconds, 6180 documents, 169086946
bytes, 1.81 Kbytes/sec.)
indexer[25828]: {03} Done (91360 seconds, 6250 documents, 173406755
bytes, 1.85 Kbytes/sec.)
indexer[25828]: {09} Done (91360 seconds, 6315 documents, 174401465
bytes, 1.86 Kbytes/sec.)
indexer[25828]: {06} Done (91352 seconds, 6244 documents, 171543730
bytes, 1.83 Kbytes/sec.)
indexer[25828]: {07} Done (91360 seconds, 6213 documents, 170018534
bytes, 1.82 Kbytes/sec.)
indexer[25828]: {04} Done (91376 seconds, 6325 documents, 172235507
bytes, 1.84 Kbytes/sec.)
indexer[25828]: {08} Done (91376 seconds, 6265 documents, 172717559
bytes, 1.85 Kbytes/sec.)
indexer[25828]: {15} Done (91353 seconds, 6183 documents, 171412717
bytes, 1.83 Kbytes/sec.)
indexer[25828]: {10} Done (91376 seconds, 6294 documents, 173353430
bytes, 1.85 Kbytes/sec.)
indexer[25828]: {02} Done (91376 seconds, 6247 documents, 172966097
bytes, 1.85 Kbytes/sec.)
indexer[25828]: {01} Done (91376 seconds, 6170 documents, 172620434
bytes, 1.84 Kbytes/sec.)
indexer[25828]: {13} Done (91376 seconds, 6136 documents, 170441721
bytes, 1.82 Kbytes/sec.)
indexer[25828]: {11} Done (91376 seconds, 6128 documents, 169363376
bytes, 1.81 Kbytes/sec.)
indexer[25828]: {14} Done (91352 seconds, 6384 documents, 171381968
bytes, 1.83 Kbytes/sec.)
indexer[25828]: {00} Total 131901 seconds, 93591 documents, 2576842455
bytes, 19.08 Kbytes/sec, 1.41 sec/doc, 27533 bytes/doc.
indexer[25828]: {00} Neo PopRank: 93197 documents, 65890 pas, 0.00
Kpas/sec, 1.42 sec/doc, 0.71 pas/doc.
indexer[25828]: {00} Sun 09 06:15:26 [25828] Flushing all buffers...
indexer[25828]: {00} Done
Ну и скрин(кстати, можно ли здесь вставить скрин в текст сообщения?)
работы заббикса с последним большим пиком обработки этих ста тысяч
урлов:
Там же видно какую пилу делает запуск /www/find.zet/dpsearch/sbin/
indexer -drW -N 3 -c 1000 каждые три часа.
itJunky
itJunky
При последнем запуске он успел пройтись всего по 50-ти ссылкам, а
времени прошло уже 7 часов с тех пор как он написал мне в консоли
Oct 13 11:12:34 find indexer[8022]: {14} SIGINT received. Terminating.
Please wait...
Oct 13 11:12:38 find indexer[8022]: {02} Done (13 seconds, 5
documents, 440022 bytes, 33.05 Kbytes/sec.)
Oct 13 11:12:38 find indexer[8022]: {01} Done (10 seconds, 8
documents, 528374 bytes, 51.60 Kbytes/sec.)
Oct 13 11:12:38 find indexer[8022]: {12} Done (10 seconds, 1
documents, 88860 bytes, 8.68 Kbytes/sec.)
Oct 13 11:12:38 find indexer[8022]: {07} Done (10 seconds, 4
documents, 160806 bytes, 15.70 Kbytes/sec.)
Oct 13 11:12:38 find indexer[8022]: {09} Done (10 seconds, 2
documents, 99327 bytes, 9.70 Kbytes/sec.)
Oct 13 11:12:38 find indexer[8022]: {04} Done (10 seconds, 5
documents, 310675 bytes, 30.34 Kbytes/sec.)
Oct 13 11:12:38 find indexer[8022]: {13} Done (10 seconds, 1
documents, 90212 bytes, 8.81 Kbytes/sec.)
Oct 13 11:12:38 find indexer[8022]: {06} Done (10 seconds, 6
documents, 251695 bytes, 24.58 Kbytes/sec.)
Oct 13 11:12:38 find indexer[8022]: {08} Done (10 seconds, 3
documents, 110458 bytes, 10.79 Kbytes/sec.)
Oct 13 11:12:38 find indexer[8022]: {05} Done (10 seconds, 5
documents, 308008 bytes, 30.08 Kbytes/sec.)
Oct 13 11:12:38 find indexer[8022]: {10} Done (10 seconds, 3
documents, 194775 bytes, 19.02 Kbytes/sec.)
Oct 13 11:12:38 find indexer[8022]: {14} Done (9 seconds, 0 documents,
0 bytes, 0.00 Kbytes/sec.)
Oct 13 11:12:38 find indexer[8022]: {03} Done (10 seconds, 9
documents, 491418 bytes, 47.99 Kbytes/sec.)
Oct 13 11:12:38 find indexer[8022]: {15} Done (9 seconds, 0 documents,
0 bytes, 0.00 Kbytes/sec.)
Oct 13 11:12:38 find indexer[8022]: {11} Done (10 seconds, 2
documents, 179057 bytes, 17.49 Kbytes/sec.)
Должен же быть способ как-то скоратить время этой обработки. А то я
чувствую при 2 миллионах ссылок в базе он у меня после одного
документа будет три дня завершаться =(
itJunky
Oct 13 11:12:38 find indexer[8022]: {11} Done (10 seconds, 2
documents, 179057 bytes, 17.49 Kbytes/sec.)
documents, 3253687 bytes, 0.07 Kbytes/sec, 790.30 sec/doc, 60253
bytes/doc.
Oct 13 23:03:41 find indexer[8022]: {00} Neo PopRank: 54 documents,
117 pas, 0.00 Kpas/sec, 790.30 sec/doc, 2.17 pas/doc.
Oct 13 23:03:41 find indexer[8022]: {00} Thu 13 23:03:41 [8022]
Flushing all buffers...
Oct 13 23:03:41 find indexer[8022]: {00} Done
Maxim Zakharov
же количества на пустой базе), это 50 ссылок добавлялось в уже
существующую базу поиска.
В случае большой базы и кратковременных запусков indexer лучше
использовать cached или старый режим работы, когда результаты работы
сбрасываются в log-файлы с последующей обработкой run-splitter.
2011/10/14 itJunky <alpha...@gmail.com>:
> 12 часов заняла обработка каких-то жалких 50-ти ссылок =((((
>
--
itJunky
растянулся по времени.
itJunky
некоторые ссылки проходятся каждым из запущенных индексеров вместо
того чтобы при обработке указать этот урл обрабатываемым и не
подхватывать его другим индексером...
Запускал индексеры так "sbin/indexer -me -N 1 -n 10000"
Maxim Zakharov
Какое значение у команды MarkForIndex в вашем indexer.conf ?
http://www.dataparksearch.org/dpsearch-perf.ru.html#MARKFORINDEX-CMD
Если указано no, то такая пометка не производится. Если же стоит yes
(и это же значение по-умолчанию), в этом случае нужно запускать каждый
indexer со сдвигом по времени от другого, примерно на время первой
выборки документов к индексированию (от вывода сообщения о старте до
начала показа обрабатываемых URL).
2011/12/1 itJunky <alpha...@gmail.com>:
--
itJunky
Поменял, но остаётся вопрос: получается, что есть разница между
запуском одного индексера с ключём -N 2 и двух отдельных индексеров?
На мой взгляд это не совсем удобно, необходимо использовать один
механизм проверки в обоих случяаях, чтобы не нужно было ждать
прохождения ранее запущенного индексера по всем линкам до запуска
второй копии индексера.