通用广告引擎的索引设计和性能优化.ppt

通用广告引擎的索引设计和性能优化阿里妈妈事业部师陀Agenda•背景•索引设计和实现•遇到的问题•下一步工作•性能优化过程•性能优化小结•Q&A背景•广告引擎的基本状况–层级结构：•广告主->广告计划->广告商品->竞价词背景•广告引擎的基本状况–层级结构：•广告主->广告计划->广告商品->竞价词–广告查询流程•Query解析-> 倒排查询->过滤->算分->排序->拼装结果返回背景•广告引擎的基本状况–层级结构：•广告主->广告计划->广告商品->竞价词–查询流程•Query解析-> 倒排查询->过滤->算分->排序->拼装结果返回–索引数据：•每天重建全量￿+￿实时更新增量背景•广告引擎的基本状况–层级结构：•广告主->广告计划->广告商品->竞价词–查询流程•Query解析-> 倒排查询->过滤->算分->排序->拼装结果返回–索引数据：•每天重建全量￿+￿实时更新增量–多条产品线，引擎技术有通用性背景•一年前：–使用搜索引擎isearch的索引内核 + 自己开发的辅表结构–相对实现复杂，正排读接口不清晰–性能问题背景•一年前：–使用搜索引擎isearch的索引内核 + 自己开发的辅表结构–相对实现复杂，正排读接口不清晰–性能问题•重构：新的通用广告引擎（一期）–索引支持主辅表结构–只做广告引擎需要的功能–目标：性能和可维护性索引设计•倒排：全量 + 增量–Payload字段可配置–增量的多级可回收内存池索引设计•正排：主/辅表结构–多种值类型：bit/int8/int16/…/float/string–多种字段类型：单值/固定多值/变长多值–定长字段和变长字段的紧密存储–Package–表的关联–字段平铺索引设计•正排：主/辅表结构–多种值类型：bit/int8/int16/…/float/string–多种字段类型：单值/固定多值/变长多值–Package–表的关联–字段平铺索引设计•正排–多种值类型：bit/int8/int16/…/float/string–多种字段类型：单值/固定多值/变长多值–定长字段和变长字段的紧密存储–Package–表的关联–字段平铺–主/辅表 + keyId->docId的hash表 + DeleteMap索引实现索引实现索引实现索引实现索引实现•其他–TableWriter的其他成员•DeleteMap•KeyIdHashTable–相关小工具：indexLibPrinter遇到的问题（1）•Mmap的得失–天然的弱持久化方案–利用系统page cache管理数据局部性遇到的问题（1）•Mmap的得失–天然的弱持久化方案–利用系统page cache管理数据局部性–脏页回写不可控遇到的问题（1）•Mmap的得失–天然的弱持久化方案–利用系统page cache管理数据局部性–脏页回写不可控•短期解决方案内核：flush_mmap_pages=0遇到的问题（1）•Mmap的得失–天然的弱持久化方案–利用系统page cache管理数据局部性–脏页回写不可控•短期解决方案内核：flush_mmap_pages=0–Page cache换入换出不可控遇到的问题（1）•Mmap的得失–天然的弱持久化方案–利用系统page cache管理数据局部性–脏页回写不可控•短期解决方案内核：flush_mmap_pages=0–Page cache换入换出不可控•mlock：不符合极端情况的异常处理需求遇到的问题（1）•Mmap的得失–天然的弱持久化方案–利用系统page cache管理数据局部性–脏页回写不可控•短期解决方案内核：flush_mmap_pages=0–Page cache换入换出不可控•mlock：不符合极端情况的异常处理需求•另外的解决方案：使用shm替换mmap，主动控制持久化和故障恢复遇到的问题（2）•稳定性–每天build全量的过程牵涉的系统太多太复杂–故障恢复的能力需要加强–解决方案：索引重整 + 索引压缩遇到的问题（2）•稳定性–每天build全量的过程牵涉的系统太多太复杂–故障恢复的能力需要加强–解决方案：索引重整能力 + 索引压缩•数据灵活性–跟分布式build的结合–批量更新能力下一步工作•广告引擎设计时的各项指标优先级–稳定性–正确性–灵活性–问题定位能力–性能下一步工作•一期的新引擎还是很像搜索引擎dispatchersearchNodesearchNodesearchNodemerger下一步工作dispatchersearchNodesearchNodesearchNodemerger分布式引擎索引数据中心服务化的searchNode集群•期望的广告引擎性能优化•目标：–searchNode的单机qps优化，主要是cpu优化•方法：–Perf 热点分析–代码优化–业务层优化–索引数据层优化–Cpu资源利用最大化性能优化过程全量qps全量rt增量qps增量rtBASE71526msstrncpy  memcpy109117ms增加结果初选178011msPartial_sort优化182311ms增加进程个数351521ms249130ms辅表数据平铺+bitFilter合并387919ms274327ms性能优化小结•工具帮助理解分析性能瓶颈，但不要仅对热点进行代码优化–推荐Intel vtune的top-down视图性能优化小结•工具帮助理解分析性能瓶颈，但不要仅对热点进行优化–推荐Intel vtune的top-down视图•针对内核/硬件特性的优化需谨慎性能优化小结•工具帮助理解分析性能瓶颈，但不要仅对热点进行优化–推荐Intel vtune的top-down视图•针对内核/硬件特性的优化需谨慎•关注数据局部性和整体代码质量（CPI）性能优化小结•工具帮助理解分析性能瓶颈，但不要仅对热点进行优化–推荐Intel vtune的top-down视图•针对内核/硬件特性的优化需谨慎•关注数据局部性和整体代码质量（CPI）•Cpu压不上去的几种原因：–并发压力不够–网卡跑满/某个线程or进程的cpu跑满–锁竞争–strace + pstack + taskset + 逐个调高并发数性能优化的下一步•数据局部性：全量数据重排•小库化：适应nehalem架构•资源管理系统谢谢 Q&A。