Повышение производительности поиска сфинксов в архитектуре ec2
Я работаю над экземпляром m1.large в ec2.
m1.large 64-bit
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 с на запрос, однако в настоящее время у меня возникают трудности с достижением этой цели.
ниже находится журнал запросов -
пришлось маскировать запросы, меняя каждую букву на "х"
[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
сфинкс конф -
{
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
}
Есть ли у вас какие-либо предложения или рекомендации по улучшению скорости запроса? если вам нужна какая-либо другая информация, пожалуйста, спросите, и я приложу.
Спасибо!
1 ответ
TL/DR
Вот сводка моих советов (см. Заголовки ниже для большего количества объяснения)
- Создание статистики на вашем DiskIO/ Память / Использование ЦП
- Попробуйте больше IOPS, это оказывает существенное влияние на время запроса?
- Сколько памяти использует Sphinx в настоящее время?
- Исследовать проблемные запросы (включить подробное ведение журнала)
- Воспользуйтесь преимуществами нескольких процессорных ядер на одном компьютере
Полезная информация для сбора
Вы проверили производительность вашего EC2, чтобы увидеть, где он может бороться (если вообще)? Я думаю, что DiskIO, память, процессор были бы хорошими индикаторами для проверки.
Было бы интересно увидеть, если увеличение IOPS приводит к значительному увеличению производительности в этом случае, пробовали ли вы несколько разных значений IOPS, чтобы увидеть, как это может улучшить производительность?
Память - я полагаю, вы используете гораздо меньше, чем 7 ГБ
http://sphinxsearch.com/blog/2011/11/11/sphinx-memory-consumption/
В этой статье вычисляется память путем исключения файлов.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.
Кроме того, вы получаете бонус: как только вы настроите сервер для распределенного поиска, вы также можете выполнять индексирование параллельно!
...
Слово предостережения: хотя этот метод улучшит большинство типов поисковых запросов, есть некоторые, которые не получат значительных преимуществ от параллельного выполнения.
...
если узлы данных возвращают большие объемы данных для последующей обработки, агрегатор вполне может стать узким местом из-за своей однопоточной природы