Notes about process and thread

本文探讨了多线程技术在数据库操作中的应用及其性能优化策略,重点关注多线程如何提高资源使用效率和多任务响应质量。通过实例分析,展示了在不同场景下多线程请求与单线程请求的性能对比,强调了数据库commit时间对效率的影响,并提出了避免脏读脏写和合理使用线程池的方法。此外,文章还讨论了sqlbulkcopy与多线程结合的性能考量,以及如何通过调整批插入数据大小和增加进程数来提升数据库插入性能。

从逻辑角度来看,多线程的意义在于一个应用程序中,有多个执行部分可以同时执行。但操作系统并没有将多个线程看做多个独立的应用,来实现进程的调度和管理以及资源分配。这就是进程和线程的重要区别。


多线程是为了同步完成多项任务,不是为了提高运行效率,而是为了提高资源使用效率来提高系统的效率。线程是在同一时间需要完成多项任务的时候实现的。


·通常块模型数据是在多个线程间共享的,需要一个合适的锁系统替换掉数据共享


refer to http://blog.youkuaiyun.com/runnerrunning/article/details/613849

如果采用nocatch则客户端每select s_Test1.Nextval from dual一次数据库端都要执行,因此10000次操作在数据库的响应端其时间是相同的,这时候比较主要取决于客户端请求时间的频率了,基于结果分析应该是多线程的请求时间比单线程快5倍

1 insert commit的多线程也比1 insert commit的单线程快5 - 8倍,随则10000次数的增加速度也许会更快。
但是10000 insert commit的多线程也比10000 insert commit的单线程速度竟然基本相同,可能还要慢一些,分析可能是数据库的连接多线程需要建立多个连接和断开连接吧,变化10000为20000也是这个结果,可见又是数据库缓存的问题,因为事务使用了数据的缓存机制,当数据写入数据时候只有在commit的时候才真正写入数据,如果10000次commit一次则每次的响应时间基本相同。
基本结论:数据库的commit时间才是影响效率的主要因素,因此在使用数据库时多使用catch ,transaction commit等,使用线程的性能也是很显著的。


refer to http://bbs.youkuaiyun.com/topics/390616280?page=1

线程池肯定是没必要的。

 让主程序接收命令行参数:查询时间范围
就可以变成多进程模式进行试验了。

然后依次启动多个主程序,给以不同的时间范围就可以了。Process.Start()即可,此方法启动进程后立刻返回,不等待进程结束

A good example for multiple process:

http://www.codeproject.com/Articles/36934/Multi-Process-Architecture-with-C


线程是并行的,但是如果你不同的线程用的是一个数据库操作对象,可以说就没有起作用。

用多线程操作数据库查询时,建议引用脏读脏写。
能用异步的地方,不建议用线程。
用Parallel.Foreach()遍历数据并执行操作


小结1:sqlbulkcopy 本身已经支持事务处理,也就是说本身支持多线程处理,如果额外用线程包装sqlbulkcopy,只会跟原来产生的线程进行资源争夺(I/O,CPU,SQL connection etc.)所以性能是不会有任何的提升,对于线程之间上下文的转换还会增加了性能的损耗,反而表现更差。所以,建议着重于调整每批插入的数据大小。如果没法调至最优,可以增加一到两个线程进行资源抢夺(把剩余的资源也彻底利用),但绝不能多。

另外的一个方法是增加进程数进行处理,因为线程是独立占用所有分配的资源,不会影响别的进程,所以总体插入的性能会得到较好的提高。我最大试过可以达到 400,000 rows/sec 的速度。


总结: 线程并非着重于提高整体的性能,而是着重于提高多任务的响应质量(用户体验)

  

private Watchdog() { mThread = new Thread(this::run, "watchdog"); // Initialize handler checkers for each common thread we want to check. Note // that we are not currently checking the background thread, since it can // potentially hold longer running operations with no guarantees about the timeliness // of operations there. // // Use a custom thread to check monitors to avoid lock contention from impacted other // threads. ServiceThread t = new ServiceThread("watchdog.monitor", android.os.Process.THREAD_PRIORITY_DEFAULT, true /*allowIo*/); t.start(); mMonitorChecker = new HandlerChecker(new Handler(t.getLooper()), "monitor thread", mLock); mHandlerCheckers.add(withDefaultTimeout(mMonitorChecker)); mHandlerCheckers.add( withDefaultTimeout( new HandlerChecker(FgThread.getHandler(), "foreground thread", mLock))); // Add checker for main thread. We only do a quick check since there // can be UI running on the thread. mHandlerCheckers.add( withDefaultTimeout( new HandlerChecker( new Handler(Looper.getMainLooper()), "main thread", mLock))); // Add checker for shared UI thread. mHandlerCheckers.add( withDefaultTimeout(new HandlerChecker(UiThread.getHandler(), "ui thread", mLock))); // And also check IO thread. mHandlerCheckers.add( withDefaultTimeout(new HandlerChecker(IoThread.getHandler(), "i/o thread", mLock))); // And the display thread. mHandlerCheckers.add( withDefaultTimeout( new HandlerChecker(DisplayThread.getHandler(), "display thread", mLock))); // And the animation thread. mHandlerCheckers.add( withDefaultTimeout( new HandlerChecker( AnimationThread.getHandler(), "animation thread", mLock))); // And the surface animation thread. mHandlerCheckers.add( withDefaultTimeout( new HandlerChecker( SurfaceAnimationThread.getHandler(), "surface animation thread", mLock))); // Initialize monitor for Binder threads. addMonitor(new BinderThreadMonitor()); mInterestingJavaPids.add(Process.myPid()); //#ifdef OPLUS_EXTENSION_HOOK //Runsheng.Pei@ANDROID.STABILITY, 2020/02/08, Add for decouple: //Jianqing.Wu@ANDROID.ARCH, 2021-08-25 : create ocsi object mWdtExt = ExtLoader.type(IWatchdogExt.class).base(this).create(); //#endif /*OPLUS_EXTENSION_HOOK*/ // See the notes on DEFAULT_TIMEOUT. assert DB || Build.IS_USERDEBUG || DEFAULT_TIMEOUT > ZygoteConnectionConstants.WRAPPED_PID_TIMEOUT_MILLIS; //#ifdef MTK_ONLY_FEATURE_AEE mWdtSocExt.getExceptionLog(); //#endif /* MTK_ONLY_FEATURE_AEE */ mTraceErrorLogger = new TraceErrorLogger(); }解释构造函数都做了什么,
09-16
private Watchdog() { 511 mThread = new Thread(this::run, "watchdog"); 512 513 // Initialize handler checkers for each common thread we want to check. Note 514 // that we are not currently checking the background thread, since it can 515 // potentially hold longer running operations with no guarantees about the timeliness 516 // of operations there. 517 // 518 // Use a custom thread to check monitors to avoid lock contention from impacted other 519 // threads. 520 ServiceThread t = new ServiceThread("watchdog.monitor", 521 android.os.Process.THREAD_PRIORITY_DEFAULT, true /*allowIo*/); 522 t.start(); 523 mMonitorChecker = new HandlerChecker(new Handler(t.getLooper()), "monitor thread", mLock); 524 mHandlerCheckers.add(withDefaultTimeout(mMonitorChecker)); 525 526 mHandlerCheckers.add( 527 withDefaultTimeout( 528 new HandlerChecker(FgThread.getHandler(), "foreground thread", mLock))); 529 // Add checker for main thread. We only do a quick check since there 530 // can be UI running on the thread. 531 mHandlerCheckers.add( 532 withDefaultTimeout( 533 new HandlerChecker( 534 new Handler(Looper.getMainLooper()), "main thread", mLock))); 535 // Add checker for shared UI thread. 536 mHandlerCheckers.add( 537 withDefaultTimeout(new HandlerChecker(UiThread.getHandler(), "ui thread", mLock))); 538 // And also check IO thread. 539 mHandlerCheckers.add( 540 withDefaultTimeout(new HandlerChecker(IoThread.getHandler(), "i/o thread", mLock))); 541 // And the display thread. 542 mHandlerCheckers.add( 543 withDefaultTimeout( 544 new HandlerChecker(DisplayThread.getHandler(), "display thread", mLock))); 545 // And the animation thread. 546 mHandlerCheckers.add( 547 withDefaultTimeout( 548 new HandlerChecker( 549 AnimationThread.getHandler(), "animation thread", mLock))); 550 // And the surface animation thread. 551 mHandlerCheckers.add( 552 withDefaultTimeout( 553 new HandlerChecker( 554 SurfaceAnimationThread.getHandler(), 555 "surface animation thread", 556 mLock))); 557 // Initialize monitor for Binder threads. 558 addMonitor(new BinderThreadMonitor()); 559 560 mInterestingJavaPids.add(Process.myPid()); 561 562 //#ifdef OPLUS_EXTENSION_HOOK 563 //Runsheng.Pei@ANDROID.STABILITY, 2020/02/08, Add for decouple: 564 //Jianqing.Wu@ANDROID.ARCH, 2021-08-25 : create ocsi object 565 mWdtExt = ExtLoader.type(IWatchdogExt.class).base(this).create(); 566 //#endif /*OPLUS_EXTENSION_HOOK*/ 567 568 // See the notes on DEFAULT_TIMEOUT. 569 assert DB || Build.IS_USERDEBUG || 570 DEFAULT_TIMEOUT > ZygoteConnectionConstants.WRAPPED_PID_TIMEOUT_MILLIS; 571 572 //#ifdef MTK_ONLY_FEATURE_AEE 573 mWdtSocExt.getExceptionLog(); 574 //#endif /* MTK_ONLY_FEATURE_AEE */ 575 mTraceErrorLogger = new TraceErrorLogger(); 576 } 577 578 /** 579 * Called by SystemServer to cause the internal thread to begin execution. 580 */ 581 public void start() { 582 //#ifdef OPLUS_EXTENSION_HOOK 583 //#Daibo.Le@ANDROID.STABILITY, 2023/03/16, add for closing watchdog in hwasan or hightempaging build 584 if (mWdtExt.checkIfNeedCloseWdt()) { 585 return; 586 } 587 //#endif /*OPLUS_EXTENSION_HOOK*/ 588 mThread.start(); 589 }这是watchdog的构造函数请帮我解释一下代码的作用
07-26
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值