Исполнился год с того момента, когда я приступил к запуску узла YaCy.
Вот список ошибок, или того, что я принял за ошибки в силу своего незнания или неумения правильно настроить.
Но мне простительно, поскольку никакой подробной информации по YaCy не существует, обучиться негде.
Возможно, что в новых версиях, вышедших за это время, некоторые ошибки уже исправлены, но я не имел сил и возможностей успеть проверить новые версии.
Всё ниже описанное относится к ver. 1.924/10079 работающей под Windows XP, 1GHz, 1Gb.
Для YaCy было выделено 870Mb RAM.
Большинство настроек оставлены по умолчанию.
Самая худшая трудность заключалась в быстром переполнении памяти. Мне так и не удалось решить эту проблему путем настройки YaCy. Пришлось написать собственную утилиту, сбрасывающую память когда это требуется. (Об этом я уже давал тему, которая никого не заинтересовала).
Итак, наблюдал следующие ошибки и глюки:
-
При достижении максимума памяти останавливается индексатор (а не только DHT).
-
По случаю исчерпания памяти: после очистки индекса, освобождения памяти и перезапуска ядра Solr, интерфейс все равно продолжал тормозить очень сильно - до полного перезапуска YaCy.
-
После исчерпания памяти или лимита дискового пространства, YaCy не могла перезагрузиться - Не стартует, пока файлы индекса не будут удалены в ручную.
Явление наблюдалось при излишне большом индексе. Опыт показал, что при выделенных 870Mb RAM, YaCu не может обрабатывать существенно больше 10Gb данных (хотя диск вмещает 20Gb). Поэтому дисковая квота для YaCy была сокращена до 8Gb. -
Выдано сообщение “Свободной памяти меньше, чем 27 MB. DHT-in отключен. Пожалуйста, исправьте. Потребуется перезапуск YaCy.”
На самом деле остановлен краулер, а DHT продолжается! -
Состояние исчерпанности памяти не отображено в /api/status_p.xml
-
Почему при переполнении памяти пользователь должен нажимать появляющуюся кнопку “Сбросить состояние”? Программа самостоятельно не может нажать эту кнопку, когда она появилась?
-
При периодическом сбросе переполнений памяти YaCy вошла в следующее состояние: интерфейс доступен, краулеры остановлены, команда очистки индекса не исполняется, кривая графика использования памяти везде равна точному нулю, но в списке общий расход памяти отображается правдоподобно.
Состояние сохранялось до перезапуска. -
Нужен параметр “максимальный размер очереди” или автоматическое ограничение очереди при приближении расхода памяти к предельному.
-
Независимо от того, сколько памяти оставлено в запас, на некоторых сайтах всё равно происходит переполнение памяти и интерфейс зависает.
-
Перегрузка кэша. Установлен размер кэша слов 9К, и в целом он балансирует в пределах 10К, но появляются отдельные пики, доходящие до 70К. Впрочем, каких-либо сбоев это не вызывает.
-
Несовпадение масштабов графиков Network History.
“Count of all Active Peers Per Day” в среднем в районе 390, а “Count of all Active Peers Per Week” за этот день - в районе 630. А на графике “Count of all Active Peers Per Month” этот же день приходится около 1400.
Форма кривой на недельном и месячном графике подобна: с учетом нужного растяжения по горизонтали.
А на годовом - ход кривой не совпадает с месячным, ход кривых в принципе различен. -
Неправильные даты столбчатой диаграммы внизу страницы Index Browser. На странице результатов поиска даты диаграммы тоже неправильные.
-
Ошибка с отрисовкой графов. Рисунок не появляется. Удаление из индекса не работает. Ошибка наблюдалась после авторегуляции при заполнении дисковой квоты, или при большом индексе.
Ошибка сбрасывается после перезагрузки.
“Удаление ошибок загрузки” периодически не работает.
Удаление индекса в этом состоянии вообще не работает, требуется перезагрузка или перезапуск ядра Solr.
Ошибка не происходит, если не установлен флажок Авторегулирования. -
Index Browser не показывает список хостов. Состояние возникает (предположительно) во время исчерпания памяти или дисковой квоты и продолжается после освобождения памяти, до перезагрузки.
Во время этого сбоя диаграмма в Application Status также не отображает изменения размера индекса, нарушается также работа Планировщика с индексом.
Похоже, некорректно работает авторегуляция.
Причем сбой происходит не сразу, сначала авторегуляция несколько раз срабатывает нормально. -
В индексе 708 документов. Занимают на диске 4.42Гб (по индикации в Status.html) после оптимизации базы и полного рестарта.
Ссылки показываются в Просмотре индекса, но режимы на странице IndexDeletion_p.html не находят документов для удаления (0 документов), Работает только Удаление по возрасту. После удаления и оптимизации, занятое на диске место заметно не уменьшилось.
Состояние произошло предположительно в результате использования Авторегуляции.
Затем было удалено в ручную около 4 тыс файлов в каталоге DATA/INDEX/freeworld/SEGMENTS/default -
При запуске краулера через “Расширенную индикацию” не работает авторегуляция использования диска. Вместо освобождения дискового пространства краулер просто отключается. (Не paused, а останавливается совсем).
Суммарное впечатление: функция авторегуляции неработоспособна, ее использование ломает базу индекса. -
IndexControlURLs_p.html, Statistics about the top-100 domains in the database:
“delete all” - адрес убирается из списка только после второго нажатия. -
По истечении 14 дней индекс становится неактивен, поиск по нему ничего не находит, но эта потеря активности никак не отражена, никаких сообщений об этом не выдается.
Более того: пока попытка поиска не произведена, продолжаются автоподсказки при наборе в строке поиска, хотя индекс уже не активен. -
Глюки с удалением индекса.
Открываю “Просмотр индекса”. Копирую в буфер обмена одно из имен присутствующих хостов. Перехожу в Удаление индекса по совпадению. Вставляю из буфера взятое имя хоста - совпадения не найдено, 0 документов. -
Удаление документов из коллекции user через Планировщик, приводит к нарушению базы индекса и исчерпанию памяти. Индексируемые после этого документы хотя и показываются, но не обнаруживаются для deletion regex .*
Эти последствия можно ликвидировать только очисткой базы (Cleanup). -
Удаление индекса не освобождает дисковое место. “Удалением по возрасту” было удалено 80 тыс документов, затем была сделана оптимизация базы. Занятое на диске пространство не уменьшилось в течение 10 часов.
Обнаружено, что место занимают файлы в каталоге \DATA\INDEX\freeworld\SEGMENTS\default и \DATA\HTCACHE\file.array
Эти файлы не удаляются программно. -
Нарушение отображения графика размера индекса. Связано с переполнением пула соединений. Исчезало также отображение графика количества узлов сети. Однако связь с самими узлами оставалась и они отображались на карте сети и в окне Монитора производительности.
Состояние не исправляется самопроизвольно.
Состояние не исправляется перезапуском ядра Solr.
Кнопки перезапуска и выключения не работают.
Узел был перезапущен вызовом непосредственно Steering.html, сбой исправился.
В этом состоянии краулер не в паузе, но имеет скорость ноль. На графике не отображается работа, как в паузе. Форма кривой памяти показывает, что индексирование не совершается, но оно запустилось фактом удаленного открытия административного интерфейса.
Этот сбой мог предположительно иметь причиной повторный запуск через планировщик индексации по списку адресов, когда еще не завершилась уже запущенная индексация по этому заданию. -
По шаблону .* и оптимизации после этого, индекс удаляется весь, но дисковое пространство не освобождается. Возобновление индексации очень быстро снова приводит к остановке по исчерпанию дисковой квоты. Размер нового собранного индекса при этом незначителен.
Другие способы удаления (записываемые в Планировщик) тоже не освобождают дисковое пространство.
Как выяснилось, это место занимают очереди краулера в каталоге YaCy/DATA/INDEX/freeworld/QUEUES/CrawlerCoreStacks -
Crawler_p.html сообщения об остановке краулера продолжают висеть, когда они уже не актуальны. (Очень мешает!)
-
Не ясно, как работает краулер. То он может загрузить 200 тыс страниц с форума, на котором только 40тыс, то может не проиндексировав до конца, прекратить работу и сбросить все очереди в ноль.
-
Автокраулер включен, но его работа не проявилась ни разу.
-
“мгновенная неглубокая индексация” работает только, если найдены какие-то результаты из других узлов.
Если запрошенный host отсутствует в индексе везде, и результатов 0, то его немедленная индексация не происходит. -
В Расширенном индексировании применение любого фильтра с опцией “запретить запуск домена” выдает ошибку “фильтр индексирования “(smb|ftp|https?)://(www.)?)” не совпадает с корень индексирования “-UNRESOLVED_PATTERN-”.”
(При этом “Запретить часть пути” с регулярным выражением - работает.) -
Документы, помещенные в htroot\www не доступны (в том числе через YaCy-прокси) по www.[peername].yacy , они доступны по www.[peername].yacy/www/, [peername].yacy/www/ и [ip.adress]/www/
При доступе через YaCy-прокси: если в адресе конечное www не завершается слэшем, это вызывает ошибку (хотя в каталоге www присутствует Index.html ). -
API Network.xml?page=5 не работает, заполнено сообщением -UNRESOLVED_PATTERN-
-
выдается ошибка на просмотр get_bookmarks.xml
-
Не отображается параметр “загрузка процессора” (Всё время -1).
-
Отмечено самопроизвольное закрытие YaCu. Причины неизвестны.
-
Проверка регулярного выражения застревает. По-видимому некоторые проверяемые комбинации способны вызывать внутреннюю ошибку.
-
Некоторые выражения черного списка приводят к вылетанию в ошибку страницы Blacklist_p.html
-
Страница “Управление черным списком”: Около поля выбора операции (внизу списка) поле выбора файла черного списка не активно и при двух файлах показывает не тот файл, который редактируется.
-
Самопроизвольно сбрасываются флажки эвристики “Оператор ‘site’: мгновенная неглубокая индексация” и “Загрузка результатов внешнего поиска из списка активных систем”. Моменты и причины сбрасывания не выяснены. Наблюдалось неоднократно, никакие другие настройки при этом повреждены не были.
-
Действия по установке этих флажков хотя и записываются в Планировщик, но при попытке их выполнить в Планировщике - не выполняются, status 404:
404 http://localhost:8090/ConfigHeuristics.html?site_on=&apicall_pk=000000000249
404 http://localhost:8090/ConfigHeuristics.html?opensearch_on=&apicall_pk=000000000250
(уважаемый автор забыл, что добавил _p в имени файла) -
Планировщик. Table_API_p.html Не удалялись записи все сразу с установкой галочки “все”.
В некоторые моменты не удается удалить выбранное действие. Через некоторое время удаление опять становится возможным. -
При запуске индексирования одновременно нескольких сайтов, в поле “Comment” Планировщика указан только один адрес, что приводит к недопониманию. Надо или указывать все, или указывать: “группа”.
-
Действие, запланированное на выполнение ежедневно, выполняется каждый раз сразу четырехкратно (показание счетчика запусков). Дата последнего запуска при этом не обновляется.
-
По неизвестной причине не удалялось действие в планировщике. Возвращает пустую страницу; при повторном обращении показывает не удаленное действие. Интерфейс подтормаживает.
Сбой исчез после рестарта. -
Функционирование планировщика непонятно. Если задано повторение, то “нет события”, а если задать триггер события, то устанавливается “не повторять” в недоступном поле.
Недостаточно событий планировщика. Не записывается “Очистка индекса”. Нужны события по переполнению памяти или дисковой квоты.
Нужно, чтобы записывались также действия: ручной сброс переполнения памяти, очистка очередей, удаление ошибок загрузки из индекса.
Так как большинство ошибочных состояний выправляются только полным перезапуском YaCy, требуется возможность задания рестарта по любому из событий.
В целом управление Планировщиком оформлено нелогично: большинство изменений в таблице применяются немедленно, а редактирование даты почему-то с подтверждением.
По-нормальному надо было бы применять с сохранением все изменения в странице целиком, кнопкой “Сохранить”. -
при использовании транслятора (Translator_p.html) невозможно просмотреть (view it) страницы yacysearchitem.html и yacysearchtrailer.html
-
На странице результатов поиска невозможно перевести через Translation Editor заголовки блоков слева: Location Provider, Wiki Name Space, Language, Authors, а также выпадающие подсказки к элементам. Текст информации об RSS доступен для перевода не весь (неправильное положение английского текста в теге).
Не переводятся сообщения об ограничении поиска, и др. -
При клике по полю поиска на странице результатов, надпись на кнопке сменяется на непереведенную.
Вообще, недоперевод и глюки со страницей результатов поиска особенно постыдны, так как это - лицо узла, эту страницу видят посетители. Это должно быть исправлено и отлажено в самую первую очередь. -
Неоднозначное поведение страницы результатов поиска. То на ней есть переключатель P2P/Stells, то этого переключателя нет.
Неясно, почему иногда ищет только в локальном индексе. -
Эффект фильтра по странам практически незаметен.
-
Поиск через активные open-search системы не происходит, хотя флажки установлены.
-
Для того, чтоб удалить open-search систему, требуется заполнить поле URL, абсурдное требование.
-
При большом количестве результатов не показывается список страниц:
“1-10 из 2 763 ; (2 635 локально, 128 удалённо из 16 узлов YaCy)”. -
Сбои при поиске изображений. Нет показа результатов, в т.ч. сообщение “10-10 из 0”.
Наблюдалось, если произведен первый клик по первому недоступному превью (thumbnails), следующие страницы перестают показывать результаты.
Сбой сложно воспроизводимый. Предположительно это связано с исчерпанием памяти в процессе такого поиска.
Режим: расширенный, поиск из других узлов. -
Во время поиска, пока результаты еще не получены, на странице результатов не должно быть надписи “0 результатов из 0 узлов”, потому что она воспринимается как неудачный поиск и побуждает посетителя не ждать дальше, а закрыть страницу.
Вместо той должна быть надпись “происходит поиск…”. -
Точный поиск фразы в кавычках дает несоответствующие результаты, совпадающие частично. В Гугле и Яндексе уже ЗАМУЧИЛО такое!!! ИСПРАВЬТЕ!!! ОЧЕНЬ ПРОШУ!!!
-
Не работает точный поиск. Например: я задал поиск фразы:
“Время было но его больше не будет”. На что получаю сообщение:
“Следующие слова являются стоп-словами и были исключены из поиска: [больше, будет, было, его, не, но].” - то есть, вместо искомой цельной фразы осталось только одно слово “Время”. Это неправильно.
Из суммы выше наблюдавшегося неизбежен вывод, что в этих условиях YaCy 1.924/10079 в принципе не способна к полноценной длительной автономной работе. Такой вывод подтверждается и взглядом на таблицу активных узлов: время непрерывной работы многих из них составляет единицы дней только.