Solr убивает мой сервер, забирая много ресурсов

У меня есть сервер Ubuntu 9.10 с RAID на 12 ГБ / Quad Core / HD 80 ГБ. и я установил на него solr lucidworks-enterprise-installer-1.7 для индексирования небольшой базы данных (около 20 тыс. статей).
как только наши редакторы начинают использовать функции solr для поиска конкретной статьи (наши редакторы, которые используют solr, всего 5 редакторов), нагрузка на сервер увеличивается экспоненциально!!

$ top
вверх - 08:29:29 до 25 дней, 20:04,  1 пользователь, средняя загрузка: 46.23, 59.69, 38.29
Задачи: всего 2695, 1 работает, 2693 спит,   0 остановлен, 1 зомби
ЦП: 14,2% сша, 2,6% с.и.,   0,0% н.и., 45,7%id, 35,9% у.а.,   0,1%hi,  1,4% с.и.,   0,0%st
Память: всего 12331880 тыс., Использовано 12245716 тыс., Свободно 86164 тыс., Буферы 3140 тыс.
Обмен: всего 3229024 КБ, использовано 3228600 КБ, свободно 424 КБ, кэшировано 139184 КБ.

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+ КОМАНДА                                                                                                                                     
17448 корень 20   0 3710 м 1,4 г 3300 S   61 11,7  37:32,39 Java     

РЕДАКТИРОВАТЬ
в моем dataconfig.xml


      
      
      
    

и таблица в базе данных mysql

mysql> desc article;
+------------------+--------------+------+-----+------------------ + ------- +
| Поле | Тип | Null | Ключ | По умолчанию | Extra |
+------------------+--------------+------+-----+ ------------------+-------+
| id               | int(255)     | НЕТ | PRI |                   |       | 
| нид | int(11)      | НЕТ | MUL | 0                 |       | 
| title_id         | int(11)      | НЕТ | MUL | 0                 |       | 
| language_id      | int(255)     | НЕТ | MUL |                   |       | 
| заголовок | Варчар (255) | ДА |     | NULL              |       | 
| резюме | текст | ДА |     | NULL              |       | 
| тело | текст | ДА |     | NULL              |       | 
| автор | Варчар (255) | ДА |     | NULL              |       | 
| дата | дата | ДА | MUL | NULL              |       | 
| parsed_at        | дата и время | ДА | MUL | NULL              |       | 
| updated_at       | дата и время | ДА |     | NULL              |       | 
| last_update_time | метка времени | НЕТ |     | CURRENT_TIMESTAMP |       | 
+------------------+--------------+------+-----+------------------ + ------- +
12 рядов в наборе (0,02 сек)

mysql> выберите количество (*) из статьи;
+----------+
| считать (*) |
+----------+
|    19560 | 
+----------+
1 ряд в наборе (0,00 сек)

Также я нашел 7 экземпляров строки ниже, применив ps aux | grep "DlucidworksHome = / etc / solr" | grep -v grep

java -server -DlucidworksHome = / etc / solr -XX: MaxPermSize = 256m -DSTOP.PORT = 8887 -DSTOP.KEY = stopLucidWorks -Djava.awt.headless = true -Dlog4j.configuration = файл:conf/log4j.xml -Dorg.restlet.engine.loggerFacadeClass=org.restlet.ext.slf4j.Slf4jLoggerFacade -Duser.language=en -Duser.country=US -Duser.timezone=UTC -Dfile.encoding=UTF-8 -Djetty.port=8888.home=jetty -jar ./jetty/start.jar ./jetty/etc/jetty.xml ./jetty/etc/jetty-ssl.xml

Любая идея о том, что может вызвать это... (Solr занимает 11,7% от 12G Ram!). обычно моя средняя нагрузка составляет около 3-5, но как только я начинаю solr, он становится 40-70
я не прав и solr нормально делать такую ​​загрузку??
Прошу прощения за мое невежество в solr:)
Спасибо за вашу помощь

1 ответ

(Я публикую это как ответ вместо комментария из-за длины)

На последней работе у нас был Lucene, который проиндексировал более 500000 статей на виртуальном сервере с 1 ЦП и 3 ГБ ОЗУ.

Я начинаю думать, что с тем, как вы взаимодействуете со своими статьями, что-то ужасно не так... Возможно, выполняется ли полный индекс каждый раз, когда обновляется / создается одна статья? У вас очень много ожидания ввода-вывода на вашем процессоре, что заставляет меня думать, что база данных убивает ваш рейд.

Это, конечно, только предположения, но ни в коем случае это не проблема с вашей операционной системой.

Вам, вероятно, следует обратиться к solr, так как это слишком узко для обычного сайта Q/A.

Другие вопросы по тегам