Jump to content
Дизайн и модификация IPS Community IPBSkinsBETA
Search In
  • More options...
Find results that contain...
Find results in...
Sign in to follow this  
Haktar

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

Recommended Posts

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

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

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

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

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

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

 

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

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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

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

 

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

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

Share this post


Link to post
Share on other sites

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

 

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

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

 

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

Share this post


Link to post
Share on other sites

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

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

 

 

################################# --- 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
}

 

 

 

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

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

 

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

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

Share this post


Link to post
Share on other sites

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

 

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

Share this post


Link to post
Share on other sites

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

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

 

 

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

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

Share this post


Link to post
Share on other sites

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

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

  • Upvote 1

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

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

 

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' )
}

Share this post


Link to post
Share on other sites

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

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...