Не удается подключиться к Solr с запуском Jetty на Ubuntu 10

Я пытаюсь настроить Solr на нашем Linode под управлением Ubuntu 10 LTS. У нас еще нет домена для этого сервера, поэтому я просто подключаюсь через IP-адрес, который я использовал Solr в другом проекте без каких-либо проблем. Я безуспешно пытался запустить solr (1.4) как с причалом, так и с tomcat из пакетов. Сервера запускаются, но я не могу подключиться к ним в браузере. Я также загрузил пример tar solr (3.5) с веб-сайта apache, который не запускается полностью. У меня есть такое внутреннее чувство, что это как-то связано с отсутствием доменного имени, но кажется странным, что это не будет разрешено только по IP-адресу.

Я надеюсь, что кто-то может дать мне некоторые идеи о том, что может быть не так в моей конфигурации.

ТИА


jetty tomcat solr ubuntu-10.04
person bikedorkseattle    schedule 21.02.2012    source источник
comment
Можете ли вы пропинговать его ip? Солр работает? Видите ли вы ошибки в лог-файле?   -  person javanna    schedule 21.02.2012
comment
Я могу засвидетельствовать обратное. Мой сервер Ubuntu 10.04 на Linode может получить доступ к Solr как xyz.members.linode.com:8080/solr (до того, как Solr был защищен брандмауэром для общего доступа). Можешь сделать curl http://localhost:1234/solr   -  person Jesvin Jose    schedule 21.02.2012
comment
Я могу свернуть локлахост, но не могу получить доступ к xyz.members.linode.com:8080. В каком файле журнала следует искать ошибки? Я не человек Java; есть ли где-нибудь лог-файл со всеми ошибками?   -  person bikedorkseattle    schedule 24.02.2012

Ответы (1)


arrow_upward
0
arrow_downward

Вы используете Oracle Java? Загрузите Oracle Java JRE с веб-сайта Oracle и установите его. Удалите любую другую версию Java с вашего сервера и повторите попытку.

Похоже, это может быть проблема с оперативной памятью. Вы вкладываете в него МНОГО документов? Вы контролируете это с помощью top (нажмите клавишу M, чтобы отсортировать по использованию памяти), пока вы это делаете? Если у вас мало оперативной памяти, скорее всего, это и есть корень проблемы.

SOLR полностью хранит свой индекс в оперативной памяти. Вам нужно выделить достаточно оперативной памяти для всего индекса, а также немного больше для кэширования запросов. У меня есть база данных 9G, работающая на машине с 12G RAM, и если я запускаю запрос типа : для 1 миллиона строк, у меня заканчивается RAM и происходит сбой. Это связано с тем, что когда SOLR кэширует запрос, он загружает все неиндексированные поля для выбранных документов в ОЗУ.

Вы не можете эффективно запустить SOLR на маленьком сервере LINODE. Вам нужно получить самые большие размеры. На самом деле, если ваши данные помещаются в ОЗУ небольшого сервера LINODE, вы можете просто создать свой собственный индекс ОЗУ, потому что вы не получите большой выгоды от SOLR.

person Michael Dillon    schedule 21.02.2012
comment
Я только что установил Oracle Java 7, и загруженный пример Solr с запуском причала все еще зависает. У меня никогда не было проблем с этим раньше. - person bikedorkseattle; 24.02.2012
comment
Вы говорите, что загрузили архив SOLR с Apache.org и запустили пример сервера по адресу http://localhost:8983/solr/admin/? Вы запускаете сервер из консоли? java -jar start.jar 2>logfile Затем вы можете просмотреть файл журнала, чтобы увидеть, есть ли что-то ненормальное. Кроме того, вы можете попробовать вместо этого Java 6. SOLR — одно из многих приложений, которые столкнулись с проблемами при работе с Java 7. - person Michael Dillon; 24.02.2012
comment
Правильно, я просто использую пример сервера, запущенного из консоли. Я обращал внимание на вывод, и нет ничего, что указывало бы на то, почему он останавливается. Я пробовал несколько разных сред Java, включая OpenJDK 1.6. Поскольку у меня это работает на сервере Debian, я собираюсь попробовать это на нем. - person bikedorkseattle; 27.02.2012
comment
Я смог запустить это за считанные минуты при установке Debian. Рам не имел никакого отношения к этому вопросу, поскольку это было относительно небольшое количество документов. - person bikedorkseattle; 28.03.2012