首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    php定时任务框架

    taskPHP基于原生态php开发的定时计划任务框架,利用多进程实现任务的分配和运行,利用原生态php内存共享实现进程间通信,支持linux和windows。有较好的伸缩性、扩展性、健壮稳定性而被多家公司使用,同时也希望开源爱好者一起贡献。 项目地址 github地址: https://github.com/qq8044023/taskPHP oschina地址: http://git.oschina.net/cqcqphper/taskPHP 框架概况 框架目录结构: taskPHP 根目录 |-- core 框架系统目录 | |-- lib 框架核心文件目录 | | |-- .... 众多的框架核心类库文件 | |-- guide.php 框架引导文件 | |-- distribute_listen.php 任务派发进程入口 | |-- worker_listen.php 任务执行进程入口 |-- logs 日志目录 |-- tasks 用户任务目录 | |-- demo demo任务 | | |-- Lib demo任务的扩展目录 | | |-- demoTask.php demo任务类文件 | | |-- config.php demo任务配置文件 | | ... 更多任务 | |-- config.php 全局配置文件 |-- main.php 框架入口文件 |-- windows_single.cmd windows快速启动文件 框架说明 linux下子进程执行任务,修改脚本无需重启后台服务立即生效,windows下修改任务脚本后需重启后台脚本 但往系统添加执行不受影响 使用内存共享实现进程通信,堵塞式消息队列,整个框架的运行无需第三方扩展。 任务派发及具体任务执行不在同个进程[distribute_listen.php]和[worker_listen.php],windows和linux下启用入口文件[main.php],windows下可运行[windows_single.cmd]快速启动 执行时间语法跟crontab类似实现crontab的运行规则,并有辅助工具在Utils类,且支持秒设置. 添加任务简单,只需继承Task基类,实现任务入口run方法 注意事项 由于任务存在派发时间,所以任务运行的时间可能会有1-2秒的误差。 windows下执行任务在循环里,编写任务有问题或调用exit将导致后台脚本停止,linux下无此问题。 使用说明 时间配置格式说明: * * * * * * * //格式 :秒 分 时 天 月 年 周 10 * * * * * * //表示每一分钟的第10秒运行 /10 * * * * * * //表示每10秒运行 系统命令说明: mian.php [start] 启动 可不带参数 mian.php close 结束 main.php reload 重新加载任务 main.php delete demo 删除任务 main.php select 查看任务列表 Windows 命令操作 调试启动程序 D:\phpStudy\wwwroot\ostaskphp>php main.php ------------------------- taskPHP ------------------------------ taskPHP version:1.0 PHP version:5.6.1 ------------------------- taskPHP PROCESS ---------------------- listen processes status distribute N [OK] worker

    02

    [linux][atop]atop的改进和在统计io上遇到的问题

    前言 互联网公司一般都会运行着几千到几万的服务器。一般的监控会采用类似ganglia/falcon类似的工具,在本地启动一个agent,把数据统计上报到集中式的服务器中,用来监控和分析系统的问题。 另外,有atop这样的工具,可以运行在服务器上,在本地写下record文件,atop命令本身也可以分析record文件,其中保存的数据的粒度更加细致,可以精确到线程级别,还有IPC,主频等等。 经验来看,atop每天生成的record文件大约500M左右,保存最近的一段时间,似乎也不是问题。用集中式的监控,配合上atop,对于问题分析来说,会有一些帮助。 分析 1,atop的改进 atop的代码量本身并不大,官方的代码在: https://github.com/Atoptool/atop.git 在使用atop的过程中,遇到了一些问题,作者也做了相应的修改: https://github.com/bytedance/atop 在bytedance-features分支上。作者把patch发送给maintainer,但是maintainer一直没有回复。在这里,列举一下改动的内容,如下。 2,smaps的优化 尝试使用smaps_rollup代替smaps,用来提高atop收集进程的PSS内存使用的效率。这个patch会在4.14上有所提升。一般情况下,建议在atop收集的时候不要加上-R选项。因为在atop读/proc/PID/smaps的时候,会walk整个PID进程的页表,期间会lock住内存页表的锁。如果在这期间PID进程发生了page fault,也需要lock,就会造成锁的进程。影响PID进程的性能。 3,数据破损问题 atop使用裸数据的方式保存record文件,其中包括三部分:raw record,就是头信息; scompbuf,是系统状态信息的数据; pcompbuf,是task级的状态信息数据,大小和task数量有关系。为了减小record文件的大小,对于 scompbuf和pcompbuf还采用了压缩。所以,数据必须完整的 rr,scompbuf,pcompbuf顺序写下去的,否则atop无法识别数据。 good case : ... rr,scompbuf,pcompbuf ... rr,scompbuf,pcompbuf ... bad case : ... rr,scompbuf[missing] ... rr,scompbuf,pcompbuf … 例如上面的例子,在写完rr,scompbuf之后,atop发生了crash,再重新启动,就会丢失后面的 pcompbuf,造成了整个record文件的不可用。 在patch中,作者使用writev进行写入数据,要么都写入成功,要么都写入不成功,用来防止这种case发生。 4,IPC造成的虚拟机性能抖动 IPC,instructions per cycle。可以用来衡量CPU运行的效率。通常是通过perf采集的数据。 提到perf,就要说明一下它的工作原理:intel的CPU上集成了PMU,用来采集硬件的信息。可以收集的硬件信息很多,可以通过perf list | grep Hardware来看。但是硬件的寄存器有数量限制,所以需要通过wrmsr指令告诉CPU收集哪些具体的事件,再通过rdpmc指令来读取对应的数据。 在虚拟化场景下,在虚拟机中使用PMU又复杂了一下,在虚拟机中执行wrmsr和rdpmc的时候,都需要虚拟机从none-root模式退出,影响了虚拟机的性能。 在patch中,作者让atop支持perfevents的配置,支持三种模式:enable模式,启用perf收集IPC。disable模式,禁用perf收集IPC。auto模式,在启动的时候,atop自动检查是否在虚拟机中运行,如果在虚拟机中,禁用;在物理级中,启用。默认是auto模式。 5,减小record文件 如果是大规格的服务器,40CPU,甚至到96CPU,通常运行大量的docker,里面运行了很多的task。其中很多task占用资源很少,但是依然会占用atop的record文件。 在patch中,支持了配置参数recordcputop & recordmemtop。用来配置收集cpu和内存的topN。其他的task可以忽略。作者测试线上的服务器36CPU, about 500 processes的场景,大约节省了40%的磁盘空间。 6,加速读record 一般在ganglia上看到系统抖动,例如下午三点十分,在对应的服务器上执行: atop -r / var/log/atop/atop_xxxx -b 15:10 如前文所述,因为rawrecord的原因,则会从头读到尾,直到匹配到对应的时间。对于log盘的使用,尤其是虚拟化场景,会限制IOPS。这

    02
    领券