Утечки памяти в Sphinx

Возникла ситуация, когда sphinx потреблял большое количество памяти и от этого падал. Всё дело в параметре max_matches. Более подробно ниже:

‘max_matches’ – integer (per-query max matches value)

Maximum amount of matches that the daemon keeps in RAM for each index and can return to the client. Default is 1000.

Introduced in order to control and limit RAM usage, max_matches setting defines how much matches will be kept in RAM while searching each index. Every match found will still be processed; but only best N of them will be kept in memory and return to the client in the end. Assume that the index contains 2,000,000 matches for the query. You rarely (if ever) need to retrieve all of them. Rather, you need to scan all of them, but only choose «best» at most, say, 500 by some criteria (ie. sorted by relevance, or price, or anything else), and display those 500 matches to the end user in pages of 20 to 100 matches. And tracking only the best 500 matches is much more RAM and CPU efficient than keeping all 2,000,000 matches, sorting them, and then discarding everything but the first 20 needed to display the search results page. max_matches controls N in that «best N» amount.

This parameter noticeably affects per-query RAM and CPU usage. Values of 1,000 to 10,000 are generally fine, but higher limits must be used with care. Recklessly raising max_matches to 1,000,000 means that searchd will have to allocate and initialize 1-million-entry matches buffer for every query. That will obviously increase per-query RAM usage, and in some cases can also noticeably impact performance.

В ранних версиях sphinx это значение можно было указывать как в конфиге, так и во время построения запроса. Причем в запросе можно было указать значение не больше, чем в конфиге. Сейчас разработчики sphinx убрали этот параметр из конфига, и приложение может указать любое значение этого параметра.

Приложение генерировало запрос со слишком большим значением max_matches. Сделали патч.

Использование большого значение max_matches у нас вызвано необходимостью группировать много записей, например, для поиска «похожих» записей. Больше информации доступно по ссылке: http://sphinxsearch.com/docs/current.html#clustering

Вот пример для общего случая, с использованием интерфейса SphinxQL:

mysql>select * from pmx where match('therapy') option max_matches=90000;

Здесь, очевидно, max_matches большое число и может быть источником проблем. В документации сказано, что до 10000 нормально, если больше – нужно аккуратно.
Поймать такой тяжелый запрос можно включив query_log в sphinx.

Related posts:

  1. CISCO ASA 5510: утечки памяти В релизе IOS’а 8.2(1)11, как утверждает cisco.com есть некоторые баги,...
  2. Виктор Пелевин Generation «П» Лет десять назад новая пара кроссовок, привезенная дальним родственником из-за...
  3. Установка приоритетов для процессов в linux: nice Команду nice можно также использовать для запуска процесса с другим...
  4. FreePBX: Too many files error message in recordings / call monitor Обычно многие админы видят подобную ошибку в веб-интерфейсе записи разговоров...
  5. Какие процессы используют больше всего памяти и CPU Выведем список ТОП 15 самых прожорливых до памяти Linux сервера...
You can leave a response, or trackback from your own site.

Оставить комментарий

*