Перейти к публикации
Дизайн и модификация IPS Community IPBSkinsBETA
Поиск в
  • Дополнительно...
Искать результаты, содержащие...
Искать результаты в...
Trotor

Cron даёт нагрузку при индексации sphinx

Рекомендованные сообщения

На форуме установлен и включен поиск Сфинкс. Всё хорошо, но есть одно НО.

При выполнение переиндексации форума посредством крон-задачи на сервере, форум зависает на 2 минуты.

Вот задача крона:

/usr/bin/indexer --config /var/www/имя домена/data/sphinx/имя домена.conf --all --rotate

Поделиться сообщением


Ссылка на сообщение

Настроить ranged-queries для сообщений как там советуют пробовали?

Ну или ставьте крон на время когда меньше всего посетителей на сайте, например в 4 часа утра. Две минуты не критичное время.

Поделиться сообщением


Ссылка на сообщение

Настроить ranged-queries для сообщений как там советуют пробовали?

Да. Как и sql_range_step. Итог всегда одинаковый.

 

Ну или ставьте крон на время когда меньше всего посетителей на сайте, например в 4 часа утра. Две минуты не критичное время.

Таки да. Утром стоит. Дело даже не в этих 2 минутах, просто почему такую нагрузку даёт. Именно на таблицу сообщений (кол-во записей - более полтора миллиона)

Поделиться сообщением


Ссылка на сообщение

Верно настроили? range step уменьшить пробовали?

 

Нагрузка потому, что таблица большая и для ее индексации требуются ресурсы.

Поделиться сообщением


Ссылка на сообщение

Верно настроили? range step уменьшить пробовали ?

Да, до 100. Думаете попробовать уменьшить до 10?

 

Нагрузка потому что таблица большая и для ее индексации требуются ресурсы.

Причём нагрузка идёт именно на апач (процессы увеличиваються в разы), мускул нормально работает, не перегружается.

Поделиться сообщением


Ссылка на сообщение

Покажите ради интереса конфиг сообщений.

 

Думаете попробовать уменьшить до 10?

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

 

Как вариант, можно создать отдельный индекс для индексации только новых сообщений с момента последнего сообщения из основного индекса, так называемый "дельта индекс". А всю таблицу целиком индексировать раз в неделю. Перестроения 1500K сообщений довольно накладная операция, нужно учитывать что сообщения являются большим объемом данных по сравнению с остальными сущностями. Какой смысл дергать полтора миллиона записей в каждый день, когда можно индексировать только несколько десятков новых сообщений в день, таким образом за неделю вы получить индекс размером примерно тысячу записей, по сравнению в несколько миллионов цифра просто смешная.

Поделиться сообщением


Ссылка на сообщение

Покажите ради интереса конфиг сообщений.

Вот конфиг отвечающий за сообщения:

 

 

################################# --- FORUM --- ##############################
source forums_search_posts_main : ipb_source_config
{
# Set our forum PID counter
sql_query_pre	= REPLACE INTO imperiall_cache_store VALUES( 'sphinx_forums_counter_posts', (SELECT max(pid) FROM imperiall_posts), '', 0, UNIX_TIMESTAMP() )

# Query posts for the main source
sql_query		= SELECT p.pid, p.pid as search_id, p.author_id, p.post_date, p.post, p.topic_id, p.queued, \
						 t.tid, t.title, t.title as tordinal, t.views, t.posts, t.forum_id, t.last_post, t.state, t.start_date, t.starter_id, t.last_poster_id, t.topic_firstpost, \
						CASE WHEN t.approved = -1 THEN 1 ELSE 0 END AS soft_deleted, \
						CASE WHEN t.approved = -1 THEN 0 ELSE t.approved END AS approved, \
						CONCAT(t.last_post, '.', t.tid ) as last_post_group \
				  FROM imperiall_posts p \
				  LEFT JOIN imperiall_topics t ON ( p.topic_id=t.tid )

# Fields	
sql_attr_uint			= queued
sql_attr_uint			= approved
sql_attr_uint			= soft_deleted
sql_attr_uint			= search_id
sql_attr_uint			= forum_id
sql_attr_timestamp	    = post_date
sql_attr_timestamp	    = last_post
sql_attr_timestamp	    = start_date
sql_attr_uint			= author_id
sql_attr_uint			= starter_id
sql_attr_uint			= tid
sql_attr_uint			= posts
sql_attr_uint			= views
sql_attr_str2ordinal	= tordinal
sql_attr_str2ordinal	= last_post_group

sql_ranged_throttle	= 0
}

source forums_search_posts_delta : forums_search_posts_main
{
# Override the base sql_query_pre
sql_query_pre = 

# Query posts for the delta source
sql_query		= SELECT p.pid, p.pid as search_id, p.author_id, p.post_date, p.post, p.topic_id, p.queued, \
						 t.tid, t.title, t.title as tordinal, t.views, t.posts, t.forum_id, t.last_post, t.state, t.start_date, t.starter_id, t.last_poster_id, t.topic_firstpost, \
						 CASE WHEN t.approved = -1 THEN 1 ELSE 0 END AS soft_deleted, \
					 	 CASE WHEN t.approved = -1 THEN 0 ELSE t.approved END AS approved, \
						CONCAT(t.last_post, '.', t.tid ) as last_post_group \
				  FROM imperiall_posts p \
				  LEFT JOIN imperiall_topics t ON ( p.topic_id=t.tid ) \
				  WHERE p.pid > ( SELECT cs_value FROM imperiall_cache_store WHERE cs_key='sphinx_forums_counter_posts' )
}

index forums_search_posts_main
{
source			= forums_search_posts_main
path			= /var/log/sphinxsearch/forums_search_posts_main

docinfo			= extern
mlock			= 0
morphology		= stem_enru
min_word_len	= 2
charset_type	= utf-8
html_strip		= 0
#infix_fields    = post, title
#min_infix_len   = 3
#enable_star     = 1
}

index forums_search_posts_delta : forums_search_posts_main
{
  source			= forums_search_posts_delta
  path				= /var/log/sphinxsearch/forums_search_posts_delta
}

 

 

 

Как вариант, можно создать отдельный индекс для индексации только новых сообщений с момента последнего сообщения из основного индекса, так называемый "дельта индекс".

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

 

когда можно индексировать только несколько десятков новых сообщений в день

Примерно пол тысячи сообщений в день.

Поделиться сообщением


Ссылка на сообщение

Так у вас уже есть дельта индекс который поддерживается форумом по умолчанию. Обновляйте его раз в день (можно даже чаще), а основной раз в неделю - две.

 

/usr/bin/indexer forums_search_posts_delta --config /var/www/имя домена/data/sphinx/имя домена.conf --rotate

Поделиться сообщением


Ссылка на сообщение

Так у вас уже есть дельта индекс который поддерживается форумом по умолчанию.

Просто в одной статье, по настройке Сфинкса рекомендовали основной поставить раз в сутки. Вообще то да, до самого только что дошло - зачем так часто?

 

 

Обновляйте его раз в день (можно даже чаще), а основной раз в неделю - две.

У меня поставлено каждые 10 минут. Не слишком много?

Поделиться сообщением


Ссылка на сообщение

У меня поставлено каждые 10 минут. Не слишком много?

Слишком часто. Три - четыре раза за сутки оптимально.

  • Upvote 1

Поделиться сообщением


Ссылка на сообщение

Слишком часто. Три - четыре раза за сутки оптимально.

Спасибо, так и сделаю.

Поделиться сообщением


Ссылка на сообщение

Интервальные запросы:

 

source forums_search_posts_main : ipb_source_config
{
   # Set our forum PID counter
   sql_query_pre   = REPLACE INTO imperiall_cache_store VALUES( 'sphinx_forums_counter_posts', (SELECT max(pid) FROM imperiall_posts), '', 0, UNIX_TIMESTAMP() )

   # Ranged Queries
   sql_query_range = SELECT MIN(pid),MAX(pid) FROM imperiall_posts
   sql_range_step  = 5000

   # Query posts for the main source
   sql_query       = SELECT p.pid, p.pid as search_id, p.author_id, p.post_date, p.post, p.topic_id, p.queued, \
                            t.tid, t.title, t.title as tordinal, t.views, t.posts, t.forum_id, t.last_post, t.state, t.start_date, t.starter_id, t.last_poster_id, t.topic_firstpost, \
                           CASE WHEN t.approved = -1 THEN 1 ELSE 0 END AS soft_deleted, \
                           CASE WHEN t.approved = -1 THEN 0 ELSE t.approved END AS approved, \
                           CONCAT(t.last_post, '.', t.tid ) as last_post_group \
                     FROM imperiall_posts p \
                     LEFT JOIN imperiall_topics t ON ( p.topic_id=t.tid ) \
                     WHERE p.pid >= $start AND p.pid <= $end

   # Fields    
   sql_attr_uint           = queued
   sql_attr_uint           = approved
   sql_attr_uint           = soft_deleted
   sql_attr_uint           = search_id
   sql_attr_uint           = forum_id
   sql_attr_timestamp      = post_date
   sql_attr_timestamp      = last_post
   sql_attr_timestamp      = start_date
   sql_attr_uint           = author_id
   sql_attr_uint           = starter_id
   sql_attr_uint           = tid
   sql_attr_uint           = posts
   sql_attr_uint           = views
   sql_attr_str2ordinal    = tordinal
   sql_attr_str2ordinal    = last_post_group

   sql_ranged_throttle = 0
}

source forums_search_posts_delta : forums_search_posts_main
{
   # Override the base sql_query_pre
   sql_query_pre = 

   # Override the base sql_query_range
   sql_query_range = 
   sql_range_step  =

   sql_ranged_throttle = 0

   # Query posts for the delta source
   sql_query       = SELECT p.pid, p.pid as search_id, p.author_id, p.post_date, p.post, p.topic_id, p.queued, \
                            t.tid, t.title, t.title as tordinal, t.views, t.posts, t.forum_id, t.last_post, t.state, t.start_date, t.starter_id, t.last_poster_id, t.topic_firstpost, \
                            CASE WHEN t.approved = -1 THEN 1 ELSE 0 END AS soft_deleted, \
                            CASE WHEN t.approved = -1 THEN 0 ELSE t.approved END AS approved, \
                           CONCAT(t.last_post, '.', t.tid ) as last_post_group \
                     FROM imperiall_posts p \
                     LEFT JOIN imperiall_topics t ON ( p.topic_id=t.tid ) \
                     WHERE p.pid > ( SELECT cs_value FROM imperiall_cache_store WHERE cs_key='sphinx_forums_counter_posts' )
}

Поделиться сообщением


Ссылка на сообщение

Интервальные запросы для основного индекса:

Этим заменить конфиг основного индекса?

Поделиться сообщением


Ссылка на сообщение

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас

  • Сейчас на странице   0 пользователей

    Нет пользователей, просматривающих эту страницу.

×
×
  • Создать...