改善ec2架构上的狮身人面像search性能

我正在研究ec2中的m1.large实例。

m1.large 64位

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

索引文件位于具有500个(承诺的)IOPS的EBS块中。

我有一个索引包含3个属性id – uint第二id – string第三id – string

我正在索引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 

狮身人面像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 }‏ 

你有任何build议或build议,以提高查询速度? 如果你需要任何其他信息,请问,我会附上。

谢谢!

TL / DR

以下是我的build议综述(参见下面的标题以获得更多的解释)

  • 在DiskIO /内存/ CPU使用率上产生统计信息
  • 尝试更多的IOPS,这是否对查询时间有重大影响?
  • 狮身人面目前正在使用多less内存?
  • 调查问题查询(打开详细日志logging)
  • 利用同一台计算机上的多个CPU内核

有用的信息收集

你检查过你的EC2的performance,看看它可能在哪里挣扎(如果有的话)? 我想DiskIO,内存,CPU将是很好的指标检查。

在这种情况下,看看增加的IOPS是否会显着提高性能会很有趣,您是否尝试了几个不同的IOPS值来了解如何提高性能?

内存 – 我希望你使用的远远less于7GB

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

本文通过排除.spd和.spp文件来计算内存。 所以你的内存消耗应该在200MB左右。

您可能还需要考虑rt_mem_limit&mem_limit。 话虽如此,看起来不太可能会消耗超过7GB的内存。

您可以使用以下命令SHOW INDEX myindex STATUS来确认您的内存使用情况

这里有一个想法:如果你不需要那么多的内存,但可以做更多的CPU,你可能会更好使用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 

然后重新启动狮身人面像守护进程,你应该得到更多有用的输出。

这里的想法是使用这些数据,并寻找问题的线索(一个特定的查询可能导致一个问题,你可能想尝试和具体优化)。

multithreadingsearch – 利用多个CPU核心

你可能想看看狮身人面像分布式searchfunction,它可以帮助一些查询types。 您可以将其configuration为利用m1.large中的两个CPU核心

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

另外,你会得到一个奖励:一旦你为分布式searchconfiguration服务器,你也可以做并行索引!

谨慎的话:虽然这种技术将改善大多数types的search查询,但有一些并不会从并行执行中获益。

如果数据节点返回大量数据进行后期处理,由于其单线程性质,聚合器可能会成为一个瓶颈