提高软件CPU占用率

案例:

独立线程以5ms一包的速率接收指令(一共大概70-80种指令类型),并放入一个队列A

主线程中,根据定时器去队列A中取数据,并解析/计算/显示(速率:200包/秒)

现象:按理说这个收/发的频率是能保持平衡的,也就是收多少就处理多少,延迟会很小(可能就是一个指令的传输时间),但是实际现象是,随着时间的推移,队列A越来越大。

发现:调试的时候发现是处理数据的时候,判断数据包类型,并进行解析模块比较费时间(注释掉这块内容就不存在延迟了)。因此排除了代码本身的问题;

代码没问题,那就只能从设备方下手

解决方案:提高软件的优先级,让CPU优先处理我这个软件的计算处理


    //REALTIME_PRIORITY_CLASS  实时
    //HIGH_PRIORITY_CLASS      高
    //ABOVE_NORMAL_PRIORITY_CLASS 高于正常
    //NORMAL_PRIORITY_CLASS  正常
    //BELOW_NORMAL_PRIORITY_CLASS 低于正常
    //IDLE_PRIORITY_CLASS 空闲

    GetCurrentProcess():当前软件进程


int main(int argc, char *argv[])
{
    SetPriorityClass(GetCurrentProcess(), REALTIME_PRIORITY_CLASS );
}

查看进程的当前CPU优先级:

任务管理器-鼠标右键(软件进程)-转到详细详细-鼠标右键(软件进程)-设置进程优先级

 然后,你启动软件的时候就会发现,应用程序优先级,由默认的正常,改成了你需要的!

  • 1
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
-------------------------------------------------------------------------------------- 最新更新情况: 0.260 新内核的正式版,也是UDA的第三个正式版.对新内核进行了极大的优化,使压缩率/时间比 比上一个正式版有了质的飞跃,默认压缩模式0的压缩率已经完全战胜UHARC,速度比原来 的模式3仅慢了不到10%.并大大减轻高模式的内存占用过多耗时过多的问题. 比较上一版本(0.250),速度有了10%的提升,程序又减少了1KB!压缩率变化轻微. [此版本的压缩包与以前任何版本都不兼容] 0.250 在上一版本的基础上更新了内核,重新设置并精简了压缩模式,使得速度和内存占用比 以前的各个模式都有了很大的改善,此版本的默认模式0的压缩率和压缩时间相当于上 一版本的模式3和4之间,但内存占用与上一版本模式3相当,以解决以前版本资源占用过 多的问题.[此版本的压缩包与以前任何版本都不兼容] 0.242 此版本彻底解决了所有的命令行(包括自解压)长文件/目录名问题,包括汉字和空格的 支持,其中含空格时需要用双引号把整个文件名括起来. [0.24x版的压缩包(包括自解压)之间相互兼容.但与以前版本均不兼容.] 0.241 此版本在0.240的基础上修正了命令中不能含有汉字的bug.加入了不存在解压路径时显 示错误信息.readme.txt中增添一些遗漏的说明. 0.240 UDA的第二个正式版,比上一个正式版(0.230)有以下提高:(1)在功能不减并加入解压时 可自定解压缩路径和使用示例的前提下,把自身体积减小到16K!(2)大力度优化了内核, 速度比0.230版提高了10%左右.(3)改善了内存的分配,节约内存占用5%-15%.(4)增强了 异常错误处理以及改善很多细节设定.(5)经过了大量测试,保证了压缩/解压的稳定性. 0.231 加入了解压时自定解压缩文件的路径.出现错误时立即停止程序而不继续压缩/解压. 优化内核程序使压缩/解压速度提高了4%.增加了使用示例.修正了几个不重要的小bug. 0.230l 由0.230完整版修改而成. 0.230 UDA的第一个非测试版.改善了界面,加入了制作自解压的功能. (取消简化版开发,压缩文件扩展名仍然使用uda.) -------------------------------------------------------------------------------------- 名称:UDA高压缩率文件压缩器 版本:0.260 Final 类型:免费软件(free software) 日期:2004.4.2 大小:15KB 要求:内存最低32M,建议64M以上,推荐256M以上 CPU最低486DX,建议PentiumII以上,推荐1G以上 平台:Windows95OSR2/98/ME/2000/XP,推荐Windows2000/XP (命令行窗口,但不支持纯DOS) 作者:Dwing 联系:[email protected] 主页:http://dwing.51.net http://dwing.go.nease.net(镜象站) -------------------------------------------------------------------------------------- 特性:1.极高的无损压缩率,但比其他常用工具较慢. 2.软件极小,只有15K. 3.支持长文件名. 4.支持通配符. 5.支持固实压缩技术. 6.支持制作自解压功能,并能在两种格式之间相互转换. -------------------------------------------------------------------------------------- 描述:本压缩工具不像其他的压缩工具使用常见的zip,rar等格式,而是使用专用的UDA格式. 最大的特点是使用了以最新的ContextModelMixing为基础的算术编码压缩技术和固实 压缩技术,因此压缩率极高,几乎可以排到世界第一位,尤其是多文件压缩!唯一的缺点 是压缩速度比其他格式较慢.后面给出各个常用的压缩工具压缩单文件和多文件的结果. -------------------------------------------------------------------------------------- 说明:1.程序文件名为uda.exe,压缩包默认扩展名为UDA. 2.建议使用各个版本压缩时都尽量制作自解压的压缩包(此版本自解压包比普通压缩包多15K). 3.由于用本压缩工具压缩的压缩包数据非常紧密,所以不支持压缩包内文件的增添,删除, 修改文件等功能,只有解压缩并整理后再重新压缩. 4.当给出解压目录时,此目录必须已经存在,否则将显示错误. 5.用"l"命令列出压缩包内文件列表时左边显示的十六进制数据是时间戳,以供解压时还原. (Windows9x环境下解压含目录的压缩包时可能不会还原目录的时间) 6.当压缩或解压显示以下错误时,只有三个按键可选择:Y--是,N--否,Q--放弃退出. (有时不能选择"否"(N);一般需要一定的处理才能选"是"(Y),如增加磁盘剩余空间) "Error Open: Retry?[Y/Q]"---压缩时无法打开待压缩的文件,确认是否重试 "Error Read: Retry?[Y/Q]"---压缩时无法读取待压缩的文件,确认是否重试 "Err:Retry?"---解压时无法建立压缩包中的文件或目录,确认是否重试 "Overwrite?"---解压时出现了同名文件,确认是否覆盖 "ErW:Retry?"---解压时无法写入解压缩的文件,确认是否重试 以上错误的原因可能为以下几个情况: (1)剩余空间不足(2)有同名目录或文件(3)磁盘写保护(4)向光盘写数据 (5)欲覆盖的文件是只读属性(6)磁盘损坏无法读取或写入数据 其他严重的错误会直接退出,而且提示比较详细,不再赘述. 7.压缩模式与内存具体需求关系见下表(非常重要!必读!): -------------------------------------------------------------------------------------- 模式(默认:3): 0 1 2 3 (PS:压缩和解压的时间和内存需求相同,内存不足会导致所) 最小内存需求: 32M 64M 128M 256M ( 用时间因使用虚拟内存而急剧增加,使用时一定注意!!) 注:以上是在前台运行的最小内存需求,有其他大程序运行时还需要更多内存.所以压缩或解压时尽量 不要运行其他程序特别是大程序,否则应选择内存要求较低的模式. -------------------------------------------------------------------------------------- 用法(与RAR命令行版类似,自解压压缩包也可以进行同样的操作): (1)使用方法为:uda 命令 选项(可选) 压缩包文件名 待压缩的文件名/解压缩目录名(可选) (2)命令:a表示压缩,x表示解压,l表示列出压缩包中文件,c表示转换压缩包格式): (3)选项:-n(n是一个数字)表示选择压缩模式,-r表示压缩文件包含子目录中的匹配文件, -s表示制作自解压压缩包 注:在命令行中输入的文件名含有空格时需要把文件名用双引号括起来,如uda a "x y z1" *.* -------------------------------------------------------------------------------------- 示例: (1)把文件abc.txt压缩成backup.uda(".uda"可省略输入): uda a backup.uda abc.txt (2)把c:\win目录中的文件及目录最快速压缩成winbak.uda: uda a -0 -r winbak c:\win\*.* (3)把当前目录中所有*.c文件压缩成自解压文件cbak.exe: uda a -s cbak *.c (4)把已压缩的文件my program.uda解压缩: uda x "my program.uda" (5)把已压缩的文件myfiles.uda解压缩到c:\windows中: uda x myfiles c:\windows (6)列出已压缩的文件my backup.uda中包含的文件: uda l "my backup" (7)把已压缩的文件mybak.uda转化成自解压文件mybak.exe: uda c mybak.uda mybak.exe (8)把自解压文件mybak.exe还原成压缩文件mybak.uda: uda c mybak.exe mybak.uda (9)把自解压文件mybak.exe解压到当前目录中: mybak (10)把自解压文件mybak.exe解压到d:\my中(已存在此目录):mybak x mybak.exe d:\my (11)列出自解压文件mybak.exe中文件: mybak l mybak.exe -------------------------------------------------------------------------------------- PS:由于软件算法复杂,制作时间紧张.如果发现BUG、问题、新的测试结果、更强悍的压缩工具 以及建议,欢迎给我发邮件([email protected],由于最近的垃圾邮件过多,所以邮件主题请尽量 用汉字,并尽量不用附件)或在我的网站上留言! 另外可直接访问http://dwing.go.nease.net/download/查看和下载网站资源. -------------------------------------------------------------------------------------- 以前更新历史(目前不再支持这些版本): 0.10 第一个版本(只有压缩和解压一个文件的功能). 0.11 加入时间累积功能,设置文件缓冲,使压缩和解压速度提高5%. 0.12 修正一些BUG(WIN9x运行不正常,包含路径的压缩文件名等BUG),并精简了源程序. 0.20 增加多文件固实压缩成一个压缩文件的功能,支持通配符,增加列出文件功能以及8种 压缩方案,能以百分比显示压缩进度,文件时间和属性的还原仍有bug(不影响主要功能). 0.21 采用了更新的内核,大多数情况会使0-3模式时间更少(-20%),压缩率更高, 4-6模式时间较长20%,压缩率更高,需内存多20%.另外修正非默认模式的文件列表错误. 0.211 修正了文件属性和时间的还原及目录属性的还原,目录时间的还原还没有解决. 0.212 加入了一些细节问题,如文件数,压缩率,压缩速度,文件列表的现实方式等. 0.213 修正了目录时间的还原.使默认扩展名为uda. 0.214 修正了一些小bug. 0.215 解压时加入已存在文件的选项. 0.220 重新整理了外壳程序,并暂时停止开发,转向简化版的开发. 0.220l 0.220版的简化版,只支持0-3模式,并除去exe模型,与以前版本不兼容,默认扩展名为udz. 0.220lx 0.220l版的专用解压工具. -------------------------------------------------------------------------------------- 常见问题解答: 1.问:使用UDA的哪个模式来压缩最好? 答:此版本UDA一共有4个压缩模式,编号为0-3,数字越大,压缩率越高,速度越慢.建议使用默认 的模式0,它的压缩率比UHARC的最高压缩率还高(速度约是UHARC的1/3~1/4).压缩时以内存 大小决定,千万不要在内存不足的情况下使用较高的模式压缩或解压,否则会出现内存不足 的错误或者速度会大大降低以至无法忍受. 2.问:用UDA压缩或解压时为什么很慢? 答:UDA使用的压缩技术比较复杂,为增大压缩率而需要很多的运算,我已经为此尽可能地优化 源程序.实际上,内存读写速度的提高要比CPU提速还有用,所以较大的Cache对压缩/解压的 速度提高很有利.据我测试,AthlonXP 1700+的压缩/解压速度比Pentium4 1.7G快不少.UDA 的浮点运算比例仅占约0.1%,所以浮点运算能力对UDA无影响.另外,解压的速度比压缩只快 了不到10%,内存需求相同,压缩时要考虑解压时的内存是否充足. 3.问:UDA有那些局限性? 答:UDA最多可以一次压缩所有文件的信息(包括相对目录名,文件名,大小,时间,属性)总和为 1MB的文件量(约几万个文件),因此不要一次压缩太多文件,遇到这种情况可以分成几部分 各个压缩.解压时文件和目录的属性和时间都会被还原(Windows9x可能不能还原目录时间). 4.问:UDA能否使用窗口界面? 答:由于UDA的压缩解压速度原因,使得它现在不可能在实际应用中常被使用.所以可以说它目前 只是实验性质的工具.现在的开发重点不是界面,而是它的压缩内核,况且被人称作压缩率之 王的UHARC现在仍然使用命令行模式.未来CPU和内存有了较大发展后,UDA才有可能象今天 WINRAR一样实用,那时我会对它的界面进行重点开发. 5.问:为什么文件可以被压缩? 答:文件一般是有很多冗余数据的,即使不能很容易察觉.有的文件冗余数据多(如BMP图象),有的 文件很少(如JPG图象,压缩电影等),所以不同种类的文件压缩率是有很大不同的.不能说一个 压缩软件能把一个10M的文件压缩成1M就说这个压缩软件压缩率高.只能用各种不同的压缩工 具压缩同样的文件并对比才能说明压缩率高还是低.一般来说,象JPG,压缩电影(RM,AVI等格 式)这些已经经过高度有损压缩的文件再进行压缩已经没什么意义了(压缩率极低),所以用一 些压缩率较高的文件(如BMP,TXT,DOC等大多数格式文件)测试比较有意义. 6.问:目前各压缩软件的压缩性能如何? 答:每种压缩软件都使用至少1种压缩格式,有的压缩软件有自主的格式,如WINRAR,WINZIP,WINACE 等等(格式各为RAR,ZIP,ACE).而有的压缩软件只提供一些常见格式的压缩/解压缩.因为WINRAR 压缩的ZIP格式文件和WINZIP压缩的ZIP格式文件相同,所以压缩性能(压缩率与压缩时间)的比较 只能以各种格式来比较,而不是压缩软件的比较. 下面简单谈谈各种压缩格式的比较: ZIP:从DOS时代到现在一直保持兼容路线,所以压缩率很低,速度极快. ARJ,LZH等:也是DOS时代的格式,与ZIP压缩率相当,又由于使用不如ZIP广泛,现在已淘汰. RAR:DOS时代就有RAR压缩工具了,而且压缩率比DOS时代的ZIP等格式高,并且支持固实压缩技术, 到WIN9X时代WINRAR(2.9以上版本)有了新的算法,使用较多的内存来压缩,因此ZIP格式与新的 RAR格式的差距有加大了很多. ACE,CAB,JAR,PAR,IMP,ARJ32等:WIN9X时代的一些压缩格式,同RAR类似使用了大量内存和固实压缩, 压缩率与新RAR略低或相同,但速度没有能和WINRAR相比的. 7ZIP,UHARC:WIN9X时代的少数几个有实力的压缩格式,压缩率均比WINRAR高,其中7ZIP速度比WINRAR 慢一半,但要高压缩率时内存要求很高,UHARC内存要求低,但速度比7ZIP慢很多,综合压缩比 UHARC比7ZIP高一点. 以上都是实用的压缩格式.近两年出现了新的算法(现在仍在实验当中,包括UDA),使得压缩率又有了 很大提高,如SLIM,DURILCA,WINRK等,但大多需要极大的内存,而且速度极慢,不适合实际应用,几年后 较优秀的算法也许会出现在实际应用当中. 以上的说法比较客观,如果有任何意见可以与我交流. --------------------------------------------------------------------------------------
LoadRunner性能测试工具实战视频教程【全套26集】 随机函数 在软件测试工具中如何巧用LoadRunner的随机函数。 LoadRunner有自带的随机函数,如果巧妙的加以采用,能解决一些看似很困难的实际问题。 一个项目的性能测试。与数据库直连,根据外部传入的SQL ID和SQL参数,从指定数据库中读取SQL模版,拼装成真实的SQL语句、执行,并将得到的结果放入缓存中。目的是减少数据库的压力。 该系统将支撑大量的SQL操作,性能自然成为备受关注的焦点之一。 由于它跟SQL语句相关,在真实环境下,同一时间可能执行着不同类型的SQL,即便是同一类型,其参数也各式各样。那么,怎样才能模拟出最符合实际情况的性能测试场景呢? 首先设计场景,即,在LoadRunner中按照比例随机取到某一类型的SQL,再随机传入参数给它,让最终的每条SQL都是随机生成,各不相同。 从场景中,可以看到,此处涉及双重随机。只采用loadruner的参数设置是无法实现的。此时需要想办法先按设定好的比例随机取到SQL,然后在每条SQL上随机取参数列表中的参数。 于是想到了loadrunner的随机函数。先实现随机取SQL ID,之后再在特定的SQL中随机取参数列表中的参数。 LoadRunner中,随机函数是rand(),它用来产生0到rand_max之间的随机整数。函数原型是 int rand (void); 然而调用rand之前,必须给随机数产生一个随机种子。这个种子由srand()函数产生。其原型是 int srand (seedTime); 2 分析占用率 1. 平均事务响应时间 Average Transaction Response Time 优秀:10s 2. 每秒点击率 Hits per Second LoadRunner分析页面 LoadRunner分析页面 当增大系统的压力(或增加并发用户数)时,吞吐率和TPS的变化曲线呈大体一致,则系统基本稳定。若压力增大时,吞吐率的曲线增加到一定程度后出现变化缓慢,甚至平坦,很可能是网络出现带宽瓶颈,同理若点击率/TPS曲线出现变化缓慢或者平坦,很可能是服务器响应时间增加,观察服务器资源使用情况,确定是否是服务器问题。 3. 请求响应时间 Time to Last Byte 4. 每秒系统处理事务数 Transaction per second 5. 吞吐量 Throughout 6. CPU利用率 Processor / %Processor Time 好:70% 坏:85% 很差:90%+ 7. 数据库操作消耗的CPU时间 Processor / %User Time 如果该值较大,可以考虑是否能通过友好算法等方法降低这个值。如果该服务器是数据库服务器, Processor\%User Time 值大的原因很可能是数据库的排序或是函数操作消耗了过多的CPU时间,此时可以考虑对数据库系统进行优化。 8. 核心态CPU平均利用率 Processor /%Privileged Time 如果该参数值和"Physical Disk"参数值一直很高,表明I/O有问题。可考虑更换更快的硬盘系统 9. 处理队列中的线程数 Processor / Processor Queue Length 如果该值保持不变(>=2)个并且%Processor Time 超过90%,那么可能存在处理器瓶颈。如果发现超过2,而处理器的利用率却一直很低,那么或许更应该去解决处理器阻塞问题,这里处理器一般不是瓶颈。 10. 文件系统缓存 Memory / Cache Bytes 50%的可用物理内存 11. 剩余的可用内存 Memory / Avaiable Mbytes 至少要有10% 的物理内存值 12. 每秒下载页数 Memory / pages/sec 好:无页交换 坏:CPU每秒10个页交换 很差:更多的页交换 13. 页面读取操作速率 Memory / page read/sec 如果页面读取操作速率很低,同时 % Disk Time 和 Avg.Disk Queue Length的值很高,则可能有磁盘瓶径。但是,如果队列长度增加的同时页面读取速率并未降低,则内存不足。 14. 物理磁盘利用率 Physical Disk / %Disk Time 好:<30% 坏:<40% 很差:<50%+ 15. 物理磁盘平均磁盘I/O队列长度 Physical Disk / Avg.Disk Queue Length 该值应不超过磁盘数的1.5~2 倍。要提高性能,可增加磁盘 16. 网络吞吐量 Network Interface / Byt
使用说明: 1.VfpDecoder V1.5 支持Visual FoxPro Runtime Library 的版本为: 6.0.8961.0, 7.0.0.9465, 8.0.0.3117, 9.0.0.2412 2.VfpDecoder 利用Hook的原理进行工作。V1.5使用的钩子与V1.1不同, 提高了切入VFP程序的成功率,但缺点是无法判断出VFP程序的主文件,所以FileList.TXT中没有MainFile一项,另外对系统资源(主要是CPU)的占用率也有所增大。 3.V1.5比V1.1增加了一个Stop按钮,当不需要解析时按下它即可,不用退出VfpDecoder。 4.运行时有两种方法: (1).先启动VfpDecoder,按下后再运行VFP程序,在此期间可对一些参数进行调整,用修改,注意有的程序修改了标准运行库的文件名,要在中填入正确的DLL文件名;有的程序可能会直接进入到界面而VfpDecoder没有动作,那么继续在VFP程序中任意进行一些操作,一般会有结果的。 (2).先运行VFP程序,再启动VfpDecoder,按下后再在VFP程序中任意进行一些操作,有时多试几次可能就会有较理想的结果。 5.有些VFP程序,把FXP及MPX文件的Size改成天文数字,所以我在V1.5中作了限制,最大400K,(一般的程序不会有这么大的FXP文件),如果得到的FXP文件是400K,那么它是由一个正常的FXP文件和后面一些垃圾数据组成,没关系,用FoxTools可以正确反编译的。 6.本程序是在Windows XP下编译测试的,估计在2000及NT环境中能正常工作,98下就不确定了。
软件系统平台运维服务技术方案主要包括以下几个方面: 监控和报警:通过各种监控工具和技术,实时监控软件系统平台的各项性能指标,如CPU使用率、内存占用率、磁盘空间等。一旦发现异常情况,及时发出报警,通知相关人员处理。 备份和恢复:定期对软件系统平台的数据和配置进行备份,确保数据的安全性。一旦发生故障或数据丢失,能够迅速恢复系统和数据,保证业务的连续性。 安全保障:采取多种安全措施,如设置防火墙、定期更新补丁、进行安全审计等,确保软件系统平台的安全稳定运行。 故障处理:建立故障处理机制,对发生的故障进行快速定位和修复,减少对业务的影响。同时分析故障原因,预防类似故障再次发生。 性能优化:根据业务需求和系统负载情况,对软件系统平台进行性能优化,提高系统的处理能力和响应速度。 文档管理:建立文档管理制度,整理和保存软件系统平台的各类文档,如系统架构图、配置参数、操作手册等。方便开发和维护人员查阅和参考。 培训服务:提供培训服务,帮助用户了解和掌握软件系统平台的使用和管理技能,提高用户的技术水平和操作能力。 以上是一个基本的软件系统平台运维服务技术方案,具体实施时可以根据实际情况进行调整和优化。通过该方案的实施,可以提高软件系统平台的可用性和稳定性,保障业务的正常运行。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值