MR采集汇总部署经验总结线程.docVIP

MR汇总与采集部署经验总结 V2.0 2009年7月2日 此文档中不包括部署手册中的内容，说了一些其他事情。 V1.0中通过参考广州、山东、河南、河北的部署，部署的采集和汇总的性能问题、存储问题基本解决。 V2.0 中，参考深圳、北京的多进程部署运行情况，加入了采集、汇总的多进程运行方式，对机器选择适应性更广，在多核的HP Unix、Solaris操作系统机器上，性能提高更为显著。 采集方案 广州的最初和山东，碰到的都是采集性能问题，由于定位算法对cpu的贪婪，定位时间总是太长。 机器选择 通过广州、深圳、河南的经验，表明，一台4450（2个2.8G至强CPU，16个虚拟核）可以采集定位两台中创MR前端机，而M5000（64个虚拟核，2.4G主频）和T5240（128个虚拟核，主频1.2G）采集定位两台MR前端机就非常吃力（此时，单进程多任务的采集程序，CPU利用率很低，不能充分利用机器能力，但多进程部署，可以使该问题得到明显改善），最终4450是最佳选择。 在山东，Sun4450，在采集潍坊、烟台数据时，可以处理4台前端机，由于前端机数据量较小，也可以很好工作。 但是，Sun4450在采集青岛海尔路数据时，由于数据量较大，依然不能完成两个前端机数据的采集定位。 幸好，河北也面临采集机不够的问题，他们创造性地将采集程序部署到了前端机上。 联通项目的中创M2400前端机，配有2个Intel至强E5405 2.0GCPU，共8核，信令采集程序和MR回放程序分别可以使用两个核（正常时，程序CPU利用率都在80%以上），系统可以运行给采集程序使用 8-2-1 = 5个任务同时处理的能力。 于是，青岛海尔路的两台前端机，部署了java采集程序，最大任务数为5。最后，发现前端机自己也处理不过来，就把每台前端机的一半任务分配给了一台4450。 但是，在前端机配置采集，并非一个十分好的方案，而是一个不得已而为之的方案，它提供了计算能力的同时，降低了前端机的可靠性，并在必要的重启时，需要中断任务。 任务数配置 性能调整可以通过任务数来控制，但各种任务方式的努力没有收获更好的结果，最终最合理的任务数为 4小时16任务。 任务配置的原理是，每个前端机15分钟数据，16个任务每15分钟启动一个，采集一个前端机的15分钟MR数据。根据闲时忙时数据，每个任务处理时间短的0.2-0.5小时，长的可能处理1-3小时。所有任务之间互不相关，独立运行，最终，它们会同时处理。 理想情况下，同时处理的任务越多，处理越快。但是，系统的cpu核数和调度等因素限制了它。 由于每个任务都是一个MR定位处理不断消耗cpu的死循环，直到15分钟MR处理完毕。当有效运行的任务数大于cpu核数时，每个任务和总的性能会大幅下降。 原则上，对于单进程部署，在动态配置文件中，配置maxthreads=，限制其任务数= cpu核数-1。对于4450，这个值为15。 对于多进程部署，所有进程的maxthreads的总和原则上应小于等于cpu核数-1. 由于前端机部署时，尤其是低速连接的前端机，其文件通过nfs拷贝占用执行任务的很大一部分时间，如果前端机的采集程序cpu利用率总是小于500%（8核-前端机程序占用2核-1），可以考虑增加maxthreads。 尽管T5240有128虚拟核，但发现其同时执行的单进程任务数增多时，总体性能大幅下降，cpu利用率降低，无法顺利进行MR定位的关键处理任务，单进程部署依然无法满足需要。 但是，进行多进程处理时，其总体效率回提升很多。 操作系统、CPU、与多进程 在HP Linux、Solaris上实现的线程CPU调度算法与Linux有显著区别。 采集程序在Linux上，单进程中的多线程可以充分利用CPU，Linux的线程的cpu时间调度是以进程的方式对待的。 在Solaris和HP Linux上，显然不是这样，其cpu利用率没有和进程内线程的数量成正比。 对于16核cpu以上的机器，如果不是Linux操作系统，不进行多进程部署，将不能利用机器的强大能力。 内存使用 相比汇总，MR查询服务，采集不会消耗太多内存，但内存大小与sitebase.txt大小、同时运行的任务数密切相关。 每个任务独立地读取sitebase，用于mr定位处理，并根据基站数量，缓存一定的MR数据。 对java最大内存设置过小，可能导致内存紧张，性能急剧下降。 Sitebase应该尽可能地小，比如，一个城市使用一个。青岛前端机定位，在使用全省sitebase（3.2M）时的速度，是只使用青岛sitebase（430K）的70%。 一般情况下，为java虚拟机指定最大2G内存应该够用。 运行时，可以通过命令 cat collect.log | grep mem 查看collect