Назад | Перейти на главную страницу

повышение производительности поиска sphinx на архитектуре ec2

Я работаю над экземпляром m1.large в ec2.

m1.large 64-бит

vCPU -2
ECU-4
Memory -7.5GB 
DIsks-2 x 420 
EBS-Optimized - Yes 
Network performance: Moderate

индексные файлы находятся в блоке EBS с 500 (обещанным) IOPS.

У меня один индекс состоит из 3 атрибутов id - uint второй id - строка третий id - строка

Я индексирую 3 больших текстовых поля.

размеры индексного файла:

spa - 68mb
spd - 8.8 gb
sph - 567 bytes
spi - 88 mb
spp - 20gb
sps - 36mb

Моя цель - достичь примерно 0,1 ~ секунды на запрос, однако в настоящее время у меня возникают трудности с достижением этой цели.

ниже журнал запросов -

пришлось замаскировать запросы, поменял каждую букву на 'x'

[Mon Aug 12 06:34:17.569 2013] 0.306 sec [ext2/0/ext 33074 (0,40)] [Index_1] [ios=2891
kb=101461.1 ioms=32.8 cpums=306.5] xxx xxxxxxxxx xxxxx
[Mon Aug 12 06:34:43.105 2013] 0.155 sec [ext2/0/ext 55208 (0,40)] [Index_1] [ios=256
kb=10974.0 ioms=42.7 cpums=120.1] xxxxxx xxx
[Mon Aug 12 06:37:43.063 2013] 0.148 sec [ext2/0/ext 122 (0,40)] [Index_1] [ios=257
kb=17985.1 ioms=6.1 cpums=148.9] xxxxxxxxx xxx xxxxxxxxx xxxx xxxxx xxxx xx xxxxx
[Mon Aug 12 07:00:18.735 2013] 0.179 sec [ext2/0/ext 1409 (0,40)] [Index_1] [ios=246
kb=9872.1 ioms=139.3 cpums=48.3] xxxxxxx xxx xxxxxxx
[Mon Aug 12 07:00:40.811 2013] 2.395 sec [ext2/0/ext 54213 (0,40)] [Index_1] [ios=2360
kb=92897.0 ioms=2004.9 cpums=458.9] xxxx xxxx xxxxxx
[Mon Aug 12 07:04:49.447 2013] 0.358 sec [ext2/0/ext 17698 (0,40)] [Index_1] [ios=696
kb=26975.8 ioms=237.0 cpums=140.2] xxxxx xxxxxx xxxx xxxxx
[Mon Aug 12 07:05:29.542 2013] 0.041 sec [ext2/0/ext 0 (0,40)] [Index_1] [ios=8 kb=1606.5
ioms=26.3 cpums=16.8] xxxxxxxx xxxxxxx xxx xxxxxxxx
[Mon Aug 12 07:05:40.208 2013] 0.244 sec [ext2/0/ext 72176 (0,40)] [Index_1] [ios=376
kb=15216.4 ioms=41.1 cpums=214.0] xxxxxxxx xxxxxxxx xxxxxxxx
[Mon Aug 12 07:13:28.726 2013] 10.177 sec [ext2/0/ext 703 (0,40)] [Index_1] [ios=6235
kb=294854.2 ioms=8724.6 cpums=1723.4] x xxxxx xxxxxxx xxxxxxx xx xxxx xxxxxxx, xxxxxxxxx
a xxxxx xxxxxxx xxxxxx, a xxxxxxx xxxxxxx xxxxxxx xx xxxx xxxxxxxx xxxxxxx xx xxxx xxxxx
xxxxxx xxxxxx
[Mon Aug 12 07:14:16.458 2013] 1.522 sec [ext2/0/ext 703 (0,40)] [Index_1] [ios=6235
kb=294854.2 ioms=100.1 cpums=1523.6] a xxxxx xxxxxxx xxxxxxx xx xxxx xxxxxxx, xxxxxxxxx a
xxxxx xxxxxxx xxxxxx, a xxxxxxx xxxxxxx xxxxxxx xx xxxx xxxxxxxx xxxxxxx xx xxxx xxxxx
xxxxxxx xxxxxx
[Mon Aug 12 07:36:47.737 2013] 1.391 sec [ext2/0/ext 727 (0,40)] [Index_1] [ios=5899
kb=269990.2 ioms=161.8 cpums=1320.6] a xxxxx xxxxxxx xxxxxxx xx xxxx xxxxxxx, xxxxxxxxx a
xxxxx xxxxxxx xxxxxx, a xxxxxxx xxxxxxx xxxxxxx xx xxxx xxxxxxx xxxxx xxxxxx xxxxxx
[Mon Aug 12 07:38:12.832 2013] 1.325 sec [ext2/0/ext 140830 (0,40)] [Index_1] [ios=3264
kb=120011.3 ioms=737.1 cpums=652.5] a xxxxx xxxxxxx xxxxxxx xx xxxx

sphinx conf -

{
source = DB
path = /home/ubuntu/sphinx_drive/sphinxdata/index/IndexMain
docinfo = extern
charset_type = sbcs
stopwords = /home/ubuntu/sphinx_drive/sphinxdata/stopwords
morphology = stem_en
min_word_len = 3
html_strip = 1
}


searchd
{
mysql_version_string = 5.0.37
listen = 0.0.0.0:9999:mysql41
log = /home/ubuntu/sphinx_drive/sphinxdata/log/searchd.log
query_log = /home/ubuntu/sphinx_drive/sphinxdata/log/query.log
read_timeout = 5
max_children = 30
pid_file = /home/ubuntu/sphinx_drive/sphinxdata/searchd.pid
max_matches = 1000
seamless_rotate = 1
preopen_indexes = 1
unlink_old = 1
workers = threads
binlog_path = /home/ubuntu/sphinx_drive/sphinxdata/data
compat_sphinxql_magics = 0
}‏

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

Спасибо!

TL / DR

Вот сводка моих советов (более подробное объяснение см. В заголовках ниже)

  • Производите статистику использования вашего DiskIO / памяти / процессора
  • Попробуйте увеличить количество операций ввода-вывода в секунду, сильно ли это влияет на время запроса?
  • Сколько памяти сейчас использует Sphinx?
  • Изучить проблемные запросы (включить подробное ведение журнала)
  • Воспользуйтесь преимуществами нескольких ядер ЦП на одном компьютере

Полезная информация для сбора

Вы проверили производительность вашего EC2, чтобы увидеть, где он может бороться (если вообще)? Я думаю, что DiskIO, Memory, CPU были бы хорошими индикаторами для проверки.

Было бы интересно посмотреть, приводит ли увеличение IOPS к значительному увеличению производительности в этом случае. Вы пробовали несколько разных значений IOPS, чтобы увидеть, как это может улучшить производительность?

Память - я думаю, вы используете гораздо меньше 7 ГБ

http://sphinxsearch.com/blog/2011/11/11/sphinx-memory-consuming/

В этой статье объем памяти рассчитывается путем исключения файлов .spd и .spp. Таким образом, потребление памяти должно быть около 200 МБ.

Вам также может потребоваться учетная запись rt_mem_limit и mem_limit. Сказав это, маловероятно, что вы будете использовать более 7 ГБ памяти.

Вы можете подтвердить использование памяти с помощью следующей команды SHOW INDEX myindex STATUS

Вот мысль: если вам не нужно столько памяти, но можно обойтись с большим количеством ЦП, вам может быть лучше использовать 2x c1.medium (0,183 доллара США) вместо 1x m1.large (0,320 доллара США).

Отследите этот запрос

http://sphinxsearch.com/blog/2011/10/27/sphinx-performance-know-your-queries-time/

query_log_format = sphinxql
query_log = query.log

Затем перезапустите демон Sphinx, и вы получите гораздо более полезный результат.

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

многопоточный поиск - использование нескольких ядер ЦП

Вы можете изучить функцию распределенного поиска sphinx, она может помочь для некоторых типов запросов. Вы можете настроить его так, чтобы использовать преимущества обоих ядер ЦП, которые есть в m1.large.

http://www.mysqlperformanceblog.com/2013/01/16/sphinx-search-performance-optimization-multi-threaded-search/

Кроме того, вы получаете бонус: после настройки сервера для распределенного поиска вы также можете выполнять индексацию параллельно!

...

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

...

если узлы данных возвращают большие объемы данных для постобработки, агрегатор вполне может стать узким местом из-за своей однопоточной природы