精华内容
下载资源
问答
  • CPU核数越多数据库运行越快的讨论

    千次阅读 2014-10-27 23:39:24
    1. CPU核数越多,数据库运行越快? 参见ITPUB 论坛:http://www.itpub.net/forum.php?mod=viewthread&tid=1872572&page=1#pid22420300

    很好的问题。


    1. CPU核数越多,数据库运行越快?

    参见ITPUB 论坛:http://www.itpub.net/forum.php?mod=viewthread&tid=1872572&page=1#pid22420300


    2. 上述问题又可以引伸为 “内存越大,数据库运行越快?”;    “带宽越宽,数据库运行越快?”    

    展开全文
  • 1. 对共享资源的锁定问题:这个问题比较好理解,如果多个并行任务尝试操作被锁定的内存位置,那么后来的肯定要等待,对于考虑不很周到的代码,其结果就是比串行机制还慢. 2. 循环体内的对象运行机制问题  在...


          在.net framework4.0以后,出现了并行编程的概念,使用 Parallel.For(0, N, i =>{  ... },很容易就可以实现我们自定义的并行化循环操作,在并行循环体中,还可以操作外部的变量,这个特性是很多其他语言所没有的,当然其他语言,诸如JAVA之类,完全可以采用我们在第二篇所介绍的方法自己生成并行化操作。

        由于.net framework使用环境的局限性,以及“庞大的身躯”,和安装时必须向微软“报到”的限制。很多开发商并不喜欢用,完全可以采用我所介绍的方式实现并行化,与微软的并行化的区别只是他的循环体是使用了lamda表达式,而我的方式是使用委托而已。再发散一下,我个人认为微软的并行化操作在并行化优化方面,多处理器利用方面会更有优势些,性能会更好。

         但.Net FrameWork中对并行化并行化的最大线程数貌似并没有进行个性化限定,运行起来自然是并行任务能开多少开多少了。就并行线程数的问题,我们在某个项目中做了一个实验,具体的并行任务中既有数据库操作,又有通信操作,还包括了若干锁定资源操作,以下就是实验结果敲打

                   

      最大线程数

       程序平均执行时间

        单线程

    31470 ms

        15线程

     20042 ms

        5线程

    20307 ms

        3线程

    18745 ms

        2线程

    18523 ms


         从这个有趣的实验结果可以看出,某些应用下,似乎线程数越多,执行时间反而越慢了, 很多情况下,并行化的程序性能可能反而不如顺序执行,甚至会出现一些死锁等问题,这在微软的说明中提到了很多(见http://technet.microsoft.com/zh-cn/magazine/dd997392(VS.110).aspx),从这篇文章,我们可以看到,影响性能的因素主要有两大类:
    1. 对共享资源的锁定问题:这个问题比较好理解,如果多个并行任务尝试操作被锁定的内存位置,那么后来的肯定要等待,对于考虑不很周到的代码,其结果就是比串行机制还慢.
    2. 循环体内的对象运行机制问题
     在微软的说明中,提到了“不安全的对象”并行化的问题,比如filestream, ui对象等,

      另一个有趣的操作是数据库操作及通信操作, 其特征是自身就具有不可控的性能瓶颈,最好通过优化数据库的命令,如连表查询、存储过程等处理。
      但对于懒人,或者不需要再精细优化的情况下,并行任务占据的线程数越少,对整体资源及其他任务的影响也越少,所以我们可以对已经封装的并行化类进行一下最大线程数的限制:

       class ParaLoop
        {
             ....
            private int _MaxThreadQty;
    
            private int _CurrentThreadQty;
            private ManualResetEvent ReqThreadEvent = new ManualResetEvent(false);
            private object _SynthreadQty = new object();
    
            public ParaLoop(int mtq)
            {
                _MaxThreadQty = mtq;
            }
    
            private void ReleaseThread()   //使用完后释放线程,并通知可以申请新线程
            {
                lock (_SynthreadQty )
                {
                    _CurrentThreadQty--;
                    ReqThreadEvent.Set();
                }
            }
    
    
             ~ParaLoop()
            {
                ReqThreadEvent.Set();
            }
     
            private MyParaThread RequestThread()   // 申请线程,如果达到最大数则等待,直到有新的线程可用
            {
                lock (_SynthreadQty)
                {
                    if (_CurrentThreadQty < _MaxThreadQty)
                    {
                        _CurrentThreadQty++;
                        return new MyParaThread();
                    }
                    else
                    {
                        ReqThreadEvent.Reset();
                    }
                }
    
                ReqThreadEvent.WaitOne();
    
                lock (_SynthreadQty)
                {
                    _CurrentThreadQty++;
                    return new MyParaThread();
                }            
            }
    
           public object ParaCompute(MyParaLoopTaskHandler loopTask, object[] inArg, int loopQty)
            {
                ...
    
                for (int i = 0; i < _TotalQty; i++)
                {
                    MyParaThread u = RequestThread();  //由直接新建线程改为申请线程
                 //   MyParaThread u = new MyParaThread();
                    
                }
                _ParaEvent.WaitOne();
    
                return _ParaLoop_Return;
            }
      
    
           void u_EndTaskCallBack(bool taskRst, object retVal)
            {
               ... 
    
                ReleaseThread();   //有返回值表示可以释放线程了
             }
        }
    
     
    
    }
    



     

    展开全文
  • 不用在意剩余内存的大小,其实很多人都是把使用其他系统的习惯带过来来了。...这些保留在内存中的进程通常情况下不会影响整体系统的运行速度并且当用户再次激活这些进程时,提升了进程的启动速度。 那Android什么时
    不用在意剩余内存的大小,其实很多人都是把使用其他系统的习惯带过来来了。

            Android采取了一种有别于Linux的进程管理策略,有别于Linux的在进程活动停止后就结束该进程,Android把这些进程都保留在内存中,直到系统需要更多内存为止。这些保留在内存中的进程通常情况下不会影响整体系统的运行速度并且当用户再次激活这些进程时,提升了进程的启动速度。
    那Android什么时候结束进程?结束哪个进程呢?之前普遍的认识是Android是依据一个名为LRU(last recently used 最近使用过的程序)列表,将程序进行排序,并结束最早的进程。

    其实安卓的内存管理机制是这样的,如下:
    1.系统会对进程的重要性进行评估,并将重要性以“oom_adj”这个数值表示出来,
    赋予各个进程;(系统会根据“oom_adj”来判断需要结束哪些进程,一般来说,“oom_adj”的值越大,该进程被系统选中终止的可能就越高)

    2.前台程序的“oom_adj”值为0,这意味着它不会被系统终止,
    一旦它不可访问后,会获得个更高的“oom_adj”,我们推测“oom_adj”的值是根据软件在LRU列表中的位置所决定的;

    3.Android不同于Linux,有一套自己独特的进程管理模块,这个模块有更强的可定制性,
    可根据“oom_adj”值的范围来决定进程管理策略,比如可以设定“当内存小于X时,结束“oom_adj”大于Y的进程”。这给了进程管理脚本的编写以更多的选择。

    Android将进程分为六大类:
    1.前台进程(foreground):目前正在屏幕上显示的进程和一些系统进程。
    举例来说,Dialer Storage,Google Search等系统进程就是前台进程;
    再举例来说,当你运行一个程序,如浏览器,当浏览器界面在前台显示时,浏览器属于前台进程(foreground)
    但一旦你按home回到主界面,浏览器就变成了后台程序(background)。我们最不希望终止的进程就是前台进程。

    2.可见进程(visible):可见进程是一些不再前台,但用户依然可见的进程,
    举个例来说:widget、输入法等,都属于visible。
    这部分进程虽然不在前台,但与我们的使用也密切相关,
    我们也不希望它们被终止(你肯定不希望时钟、天气,新闻等widget被终止,那它们将无法同步,你也不希望输入法被终止,否则你每次输入时都需要重新启动输入法)

    3.次要服务(secondary server):目前正在运行的一些服务(主要服务,如拨号等,是不可能被进程管理终止的,故这里只谈次要服务),

    举例来说:谷歌企业套件,Gmail内部存储,联系人内部存储等。
    这部分服务虽然属于次要服务,但很一些系统功能依然息息相关,我们时常需要用到它们,所以也太希望他们被终止

    4.后台进程(hidden):虽然作者用了hidden这个词,但实际即是后台进程(background)
    就是我们通常意义上理解的启动后被切换到后台的进程,如浏览器,阅读器等。
    当程序显示在屏幕上时,他所运行的进程即为前台进程(foreground),
    一旦我们按home返回主界面(注意是按home,不是按back),程序就驻留在后台,成为后台进程(background)。
    后台进程的管理策略有多种:有较为积极的方式,一旦程序到达后台立即终止,这种方式会提高程序的运行速度,但无法加速程序的再次启动;
    也有较消极的方式,尽可能多的保留后台程序,虽然可能会影响到单个程序的运行速度,但在再次启动已启动的程序时,速度会有所提升。
    这里就需要用户根据自己的使用习惯找到一个平衡点

    5.内容供应节点(content provider):没有程序实体,进提供内容供别的程序去用的,比如日历供应节点,邮件供应节点等。在终止进程时,这类程序应该有较高的优先权

    6.空进程(empty):没有任何东西在内运行的进程,有些程序,比如BTE,在程序退出后,
    依然会在进程中驻留一个空进程,这个进程里没有任何数据在运行,作用往往是提高该程序下次的启动速度或者记录程序的一些历史信息。这部分进程无疑是应该最先终止的。
          简单来说,就是选择退出程序时,并不是完全退出程序,该程序仍然会在后台驻留一个进程,以便下次更快的打开。
          那什么时候完全关闭该程序呢?这取决于该程序的类型(就是上面讲的那几个类型)。
          系统会给每个类型的程序一个内存值阈(阀门),也就是说当运行内存低于某个值时,系统会自动按照打开的先后顺序来关闭该类型的程序。
           例如,当运存小于24MB时,系统才会自动关闭空进程这一类型的程序,释放出更多的内存来供新程序使用,已保证新开程序的正常运行。

           综上所述,我们不难看出,很多时候我们没必要过多的去关注系统的空闲内存(RAM)是多少,也没必要特意的去杀掉后台程序,因为系统会自动分配内存,以保证新程序的运行.以前也经常纠结刷了V4后运行内存突然就少了很多,自从明白这个问题,不用去纠结啦~
           当然,特殊情况除外,比如你马上就要开一个非常大的游戏,需要更多的内存,这个时候就可以手动杀掉一些后台程序,以保证游戏的流畅。还有就是在后台也偷流量又时常要用不能删的程序,一定要关
      这是借用其他论坛的好帖子。
    展开全文
  • 文章目录目录前文列表内存Linux 的内存大页的实现原理内存配置透明巨型页 THP页面对内存的影响内存的性能问题 前文列表 内存 在页式虚拟存储器中,会在虚拟存储空间和物理主存空间都分割为一...

    目录

    前文列表

    大页内存

    在页式虚拟存储器中,会在虚拟存储空间和物理主存空间都分割为一个个固定大小的页,为线程分配内存是也是以页为单位。比如:页的大小为 4K,那么 4GB 存储空间就需要 4GB/4KB=1M 条记录,即有 100 多万个 4KB 的页。我们可以相待,如果页太小了,那么就会产生大量的页表条目,降低了查询速度的同时还浪费了存放页面的主存空间;但如果页太大了,又会容易造成浪费,原因就跟段式存储管理方式一般。所以 Linux 操作系统默认的页大小就是 4KB,可以通过指令查看:

    $ getconf PAGE_SIZE
    4096
    

    但在某些对性能要求非常苛刻的场景中,页面会被设置得非常的大,比如:1GB、甚至几十 GB,这些页被称之为 “大页”(Huge Page)。大页能够提升性能的主要原因有以下几点:

    • 减少页表条目,加快检索速度。
    • 提升 TLB 快表的命中率,TLB 一般拥有 16 ~ 128 个条目之间,也就是说当大页为 1GB 的时候,TLB 能够对应 16GB ~ 128GB 之间的存储空间。

    值得注意的是,首先使用大页的同时一般会禁止主存-辅存页面交换(Swap),原因跟段式存储管理方式一样,大容量交换会让辅存读写成为 CPU 处理的瓶颈。 虽然现今在数据中心闪存化的环境中,这个问题得到了缓解,但代价就是昂贵的 SSD 存储设备。再一个就是大页也会使得页内地址检索的速度变慢,所以并非是页面的容量越大越好,而是需要对应用程序进行大量的测试取得页面容量与性能的曲线峰值才对。

    启用 HugePage 的优点

    • 无需交换,不存在页面由于内存空间不足而换入换出的问题。
    • 减轻 TLB Cache 的压力,也就是降低了 CPU Cache 可缓存的地址映射压力。
    • 降低 Page Table 的负载。
    • 消除 Page Table 地查找负载。
    • 提高内存的整体性能。

    启用 HugePage 的缺点

    • HugePages 会在系统启动时,直接分配并保留对应大小的内存区域
    • HugePages 在开机之后,如果没有管理员的介入,是不会释放和改变的。

    Linux 的大页内存

    在 Linux 中,物理内存是以页为单位来管理的。默认的,页的大小为 4KB。 1MB 的内存能划分为 256 页; 1GB 则等同于 256000 页。 CPU 中有一个内置的内存管理单元(MMU),用于存储这些页的列表(页表),每页都有一个对应的入口地址。4KB 大小的页面在 “分页机制” 提出的时候是合理的,因为当时的内存大小不过几十兆字节。然而,当前计算机的物理内存容量已经增长到 GB 甚至 TB 级别了,操作系统仍然以 4KB 大小为页面的基本单位的话,会导致 CPU 中 MMU 的页面空间不足以存放所有的地址条目,则会造成内存的浪费。

    同时,在 Linux 操作系统上运行内存需求量较大的应用程序时,采用的默认的 4KB 页面,将会产生较多 TLB Miss 和缺页中断,从而大大影响应用程序的性能。当操作系统以 2MB 甚至更大作为分页的单位时,将会大大减少 TLB Miss 和缺页中断的数量,显著提高应用程序的性能。

    为了解决上述问题,自 Linux Kernel 2.6 起,引入了 Huge pages(巨型页)的概念,目的是通过使用大页内存来取代传统的 4KB 内存页面, 以适应越来越大的内存空间。Huge pages 有 2MB 和 1GB 两种规格,2MB 大小(默认)适合用于 GB 级别的内存,而 1GB 大小适合用于 TB 级别的内存。

    大页的实现原理

    为了能以最小的代价实现大页面支持,Linux 采用了 hugetlb 和 hugetlbfs 两个概念。其中,hugetlb 是记录在 TLB 中的条目并指向 hugepages,而 hugetlbfs 则是一个特殊文件系统(本质是内存文件系统)。hugetlbfs 主要的作用是使得应用程序可以根据需要灵活地选择虚拟存储器页面的大小,而不会全局性的强制使用某个大小的页面。在 TLB 中通过 hugetlb 来指向 hugepages,可以通过 hugetlb entries 来调用 hugepages,这些被分配的 hugepages 再以 hugetlbfs 内存文件系统的形式提供给进程使用

    • Regular Page 的分配:当一个进程请求内存时,它需要访问 PageTable 去调用一个实际的物理内存地址,继而获得内存空间。
      在这里插入图片描述
    • Huge Page 的分配:当系统配置 Huge pages 后,进程依然通过普通的 PageTable 来获取到实际的物理内存地址。但不同的是,在 Process PageTable 和 System PageTable 第增加了 Hugepage(HPage)属性。
      在这里插入图片描述
      可见,进程当需要使用 Huge pages 时,只需要声明 Hugepage 属性,让系统分配 PageTable 中的 Huge pages 条目即可实现。所以,实际上 Regular page 和 Huge page 是共享一个 PageTable 的,这就是所谓的以最小的代码来支持 Huge pages。

    使用 Huge pages 的好处是很明显的,假设应用程序需要 2MB 的内存,如果操作系统以 4KB 作为分页的单位,则需要 512 个页面,进而在 TLB 中需要 512 个表项,同时也需要 512 个页表项,操作系统需要经历至少 512 次 TLB Miss 和 512 次缺页中断才能将 2MB 应用程序空间全部映射到物理内存;然而,当操作系统采用 2MB 作为分页的基本单位时,只需要一次 TLB Miss 和一次缺页中断,就可以为 2MB 的应用程序空间建立虚实映射,并在运行过程中无需再经历 TLB Miss 和缺页中断(假设未发生 TLB 项替换和 Swap)。

    此外,使用 Huge pages 还能减少系统管理和处理器访问内存页的时间(扩大了 TLB 快页表查询的内存地址范围),Linux 内核中的 Swap(内存交换)守护进程也不会管理大页面占用的这部分空间。合理设置大页面能减少内存操作的负担,减少访问页表造成性能瓶颈的可能性,从而提升系统性能。由此,如果你的系统经常碰到因为 Swap 而引发的性能问题,或者你的计算机内存空间非常大时,都可以考虑启用大页内存。

    大页内存配置

    大页面配置需要连续的内存空间,因此在开机时就分配是最可靠的设置方式。配置大页面的参数有:

    • hugepages :在内核中定义了开机启动时就分配的永久大页面的数量。默认为 0,即不分配。只有当系统有足够的连续可用页时,分配才会成功。由该参数保留的页不能用于其他用途。

    • hugepagesz: 在内核中定义了开机启动时分配的大页面的大小。可选值为 2MB 和 1GB 。默认是 2MB 。

    • default_hugepagesz:在内核中定义了开机启动时分配的大页面的默认大小。

    • Step 1. 查看 Linux 操作系统是否启动了大页内存,如果 HugePages_Total 为 0,意味着 Linux 没有设置或没有启用 Huge pages。

    $ grep -i HugePages_Total /proc/meminfo
    HugePages_Total:       0
    
    • Step 2. 查看是否挂载了 hugetlbfs
    $ mount | grep hugetlbfs
    hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
    
    • Step 3. 如果没有挂载则手动挂载
    $ mkdir /mnt/huge_1GB
    $ mount -t hugetlbfs nodev /mnt/huge_1GB
    
    $ vim /etc/fstab
    nodev /mnt/huge_1GB hugetlbfs pagesize=1GB 0 0
    
    • Step 4. 修改 grub2,例如为系统配置 10 个 1GB 的大页面
    $ vim /etc/grub2.cfg
    # 定位到 linux16 /vmlinuz-3.10.0-327.el7.x86_64 在行末追加
    default_hugepagesz=1G hugepagesz=1G hugepages=10
    

    NOTE:配置大页面后,系统在开机启动时会首选尝试在内存中找到并预留连续的大小为 hugepages * hugepagesz 的内存空间。如果内存空间不满足,则启动会报错 Kernel Panic, Out of Memory 等错误。

    • Step 5. 重启系统,查看更详细的大页内存信息
    $ cat /proc/meminfo | grep -i Huge
    AnonHugePages:   1433600 kB     # 匿名 HugePages 数量
    HugePages_Total:       0        # 分配的大页面数量
    HugePages_Free:        0        # 没有被使用过的大页面数量
    HugePages_Rsvd:        0        # 已经被分配预留但是还没有使用的大页面数目,应该尽量保持 HugePages_Free - HugePages_Rsvd = 0
    HugePages_Surp:        0        # surplus 的缩写,表示大页内存池中大于 /proc/sys/vm/nr_hugepages 中值的大页面数量
    Hugepagesize:       1048576 kB     # 每个大页面的 Size,与 HugePages_Total 的相乘得到大页面池的总容量
    

    如果大页面的 Size 一致,则可以通过 /proc/meminfo 中的 HugepagesizeHugePages_Total 计算出大页面所占内存空间的大小。这部分空间会被算到已用的内存空间里,即使还未真正被使用。因此,用户可能观察到下面现象:使用 free 命令查看已用内存很大,但 top 或者 ps 中看到 %mem 的使用总量加起来却很少。

    • Step 6. 如果上述输出看见 Hugepagesize 已经设置成 1GB,但 HugePages_Total 还是为 0,那么需要修改内核参数设定大页面的数量
    $ sysctl -w vm.nr_hugepages=10
    
    # 或者
    $ echo 'vm.nr_hugepages = 10' > /etc/sysctl.conf 
    $ sysctl -p
    

    NOTE:一般情况下,配置的大页面可能主要供特定的应用程序或服务使用,其他进程是无法共享这部分空间的(如 Oracle SGA)。 请根据系统物理内存和应用需求来设置合适的大小,避免大页面使用的浪费;以及造成其他进程因竞争剩余可用内存而出现内存溢出的错误,进而导致系统崩溃的现象。默认的,当存在大页面时,会在应用进程或者内核进程申请大页内存的时候,优先为它们分配大页面,大页面不足以分配时,才会分配传统的 4KB 页面。查看哪个程序在使用大页内存:

    grep -e AnonHugePages /proc/*/smaps | awk '{if(2>4)print0}' | awk -F "/" '{print0;system("ps−fp"3)}'
    

    透明巨型页 THP

    Transparent Huge pages(THP,透明大页) 自 RHEL 6 开始引入。由于传统的 Huge pages 很难手动的管理,对于程序而言,可能需要修改很多的代码才能有效的使用。THP 的引入就是为了便于系统管理员和开发人员使用大页内存。THP 是一个抽象层,能够自动创建、管理和使用传统大页。操作系统将大页内存看作是一种系统资源,在 THP 开启的情况下,其他的进程也可以申请和释放大页内存。

    Huge pages 和 Transparent Huge pages 在大页内存的使用方式上存在区别,前者是预分配的方式,而后者则是动态分配的方式,显然后者更适合程序使用。需要注意的是,THP 虽然方便,但在某些场景种仍然会建议我们关闭,这个需要结合实际应用场景慎重考虑。

    手动关闭 THP

    $ echo never > /sys/kernel/mm/transparent_hugepage/enabled 
    $ echo never > /sys/kernel/mm/transparent_hugepage/defrag
    
    $ cat /sys/kernel/mm/transparent_hugepage/enabled
    [always] madvise never
    
    # - [always] 表示启用了 THP
    # - [never] 表示禁用了 THP
    # - [madvise] 表示只在 MADV_HUGEPAGE 标志的 VMA 中使用 THP
    

    永久关闭 THP

    vim /etc/grub2.cfg
    
    # 在 cmdline 追加:
    transparent_hugepage=never
    

    大页面对内存的影响

    需要注意的是,为大页面分配的内存空间会被计算到已用内存空间中,即使它们还未真正被使用。因此,你可能观察到下面现象:使用 free 命令查看已用内存很大,但 top 或者 ps 指令中看到 %MEM 的使用总量加起来却很少。

    例如:总内存为 32G,并且分配了 12G 大页面的 free 如下

    [root@localhost ~]# free -g
                  total        used        free      shared  buff/cache   available
    Mem:             31          16          14           0           0          14
    Swap:             3           0           3
    

    命令 top 输出, Shift+m 按内存使用量进行排序:
    在这里插入图片描述
    命令 ps -eo uid,pid,rss,trs,pmem,stat,cmd,查看进程的内存使用量:
    在这里插入图片描述
    这种情况就导致了一个问题,如果盲目的去提高大页内存空间的占比,就很可能会出现胖的胖死,饿的饿死的问题。导致大页内存空间的浪费,因为普通程序是未必能够使用大页内存的

    大页内存的性能问题

    在页式虚拟存储器中,会在虚拟存储空间和物理主存空间都分割为一个个固定大小的页,为线程分配内存是也是以页为单位。比如:页的大小为 4K,那么 4GB 存储空间就需要 4GB/4KB=1M 条记录,即有 100 多万个 4KB 的页。我们可以相待,如果页太小了,那么就会产生大量的页表条目,降低了查询速度的同时还浪费了存放页面的主存空间;但如果页太大了,又会容易造成浪费,原因就跟段式存储管理方式一般。所以 Linux 操作系统默认的页大小就是 4KB,可以通过指令查看:

    $ getconf PAGE_SIZE
    4096
    

    但在某些对性能要求非常苛刻的场景中,页面会被设置得非常的大,比如:1GB、甚至几十 GB,这些页被称之为 “大页”(Huge Page)。大页能够提升性能的主要原因有以下几点:

    • 减少页表条目,加快检索速度。
    • 提升 TLB 快表的命中率,TLB 一般拥有 16 ~ 128 个条目之间,也就是说当大页为 1GB 的时候,TLB 能够对应 16GB ~ 128GB 之间的存储空间。

    值得注意的是,首先使用大页的同时一般会禁止主存-辅存页面交换,原因跟段式存储管理方式一样,大容量交换会让辅存读写成为 CPU 处理的瓶颈。再一个就是大页也会使得页内地址检索的速度变慢,所以并非是页面的容量越大越好,而是需要对应用程序进行大量的测试取得页面容量与性能的曲线峰值才对。

    展开全文
  • python程序慢与内存泄漏

    千次阅读 2019-05-25 20:00:21
    问题:运行python程序的时候,在100轮以后时间从初始的3S一次,慢慢变为1分钟一次,越来越慢。 处理方法:查询资料得,这种问题的出现基本是由于程序内存泄漏。所以需要监测内存占用情况。 监测内存需要: memory_...
  • java程序运行时如何分配内存

    千次阅读 2015-09-18 17:52:41
    Java 虚拟机(JVM)是可运行Java代码的假想计算机。只要根据JVM规格描述将解释器移植到特定的计算机上,就能保证经过编译的任何Java代码能够在该系统上运行。本文首先简要介绍从Java文件的编译到最终执行的过程,随后...
  • 平时大家接触最多的应该是普通内存,也就是我们所说的PC内存,一般来说,内存,可用的缓存就越,电脑的运行速度就越快。用在服务器上是同理,服务器的内存,可用缓存就越,网站的速度也越快。 ...
  • 面试的时候谈到 JVM,也有很多面试官喜欢问,为啥 Java 程序越执行越快呢? 一般人都能回答上来,类加载,缓存预热等等,但是深入下去,最重要的却没有答上来,今天本系列文章就来帮助大家理解这个问题的关键。本篇...
  • 深入理解Java虚拟机-Java内存区域与内存溢出异常

    万次阅读 多人点赞 2020-01-03 21:42:24
    文章目录概述运行时数据区域程序计数器(线程私有)Java虚拟机栈(线程私有)局部变量表操作数栈动态链接方法返回地址小结本地方法栈(线程私有)Java堆(全局共享)方法区(全局共享)运行时常量池直接内存HotSpot...
  • 虚拟内存,页表,表,多级页表,倒排页表

    千次阅读 多人点赞 2018-05-03 11:45:10
    需要运行的程序往往内存无法容纳,而且必然需要系统能够支持多个程序同时运行,即使内存可以满足其中单独一个程序的需要,但总体来看,它们仍然超出了内存大小。交换技术(swapping)并不是一个有吸引力的解决...
  • spark是借鉴了Mapreduce,并在其基础上发展起来的,... (1)spark把运算的中间数据(shuffle阶段产生的数据)存放在内存,迭代计算效率更高,mapreduce的中间结果需要落地,保存到磁盘 (2)Spark容错性高,它通过...
  • 语言低级,运行效率就高吗?

    千次阅读 2004-09-07 01:42:00
    我不同意大家关于语言低级,运行效率就高的说法。语言低级,编译器能够决定的东西就少,就不能很好的优化执行代码。大家想想为什么c语言编译器,一般都忽略register关键字,C++一般都忽略inline关键字? 很...
  • Android内存优化总结

    万次阅读 2018-11-14 15:57:44
    寄存器(Registers):速度最的存储场所,因为寄存器位于处理器内部,我们在程序中无法控制 栈(Stack):存放基本类型的数据和对象的引用,但对象本身不存放在栈中,而是存放在堆中 堆(Heap):堆内存用来...
  • 【Linux】Linux的虚拟内存详解(MMU、页表结构)

    万次阅读 多人点赞 2018-07-16 20:16:28
    如何在有限的内存空间运行的应用程序,曾是困扰人们的一个难题。为解决这个问题,人们设计了许多的方案,其中最成功的当属虚拟内存技术。Linux作为一个以通用为目的的现代大型操作系统,当然也毫不例外的采用了...
  • 不管存储器有多,程序大小的增长速度比内存容量的增长速度要的多。下面我们就来探讨一下操作系统是如何创建内存并管理他们的。 经过多年的研究发现,科学家提出了一种 分层存储器体系(memory hierarchy),下面是...
  • ANDROID内存优化(汇总——全)

    万次阅读 多人点赞 2014-09-11 00:17:27
    ANDROID内存优化汇总完全版,涵盖内存介绍,内存计算,减少内存,重用内存,回收内存内存优化总结。
  • 内存抖动是指在短时间内有大量的...不会造成严重内存抖动这样可以接受也不可避免,频繁的话就很内存抖动很严重),内存抖动的影响是如果抖动很频繁,会导致垃圾回收机制频繁运行(短时间内产生大量对象,需要大量内存
  • 指针变量占用内存的大小

    千次阅读 2018-05-14 12:30:21
    字长越计算机的处理数据的速度就越快 。早期的微机字长一般是8位和16 位,386以及更高的处理器大多是32位。目前市面上的计算机的处理器部分已达到64位。   字长由微处理器(CPU)对外数据通路的数据总线条数...
  • android内存优化

    千次阅读 2014-06-27 22:29:26
    Android的应用被限制为最多占用16m的内存,至少在T-Mobile G1上是这样的(当然现在已经有几百兆的...Android能在内存中保持的应用越多,用户在切换应用的时候就越快。作为我的一项工作,我仔细研究了Android应用的内存
  • ANDROID内存优化(汇总——中)

    万次阅读 多人点赞 2014-08-29 00:08:25
    ANDROID内存优化汇总,从各个方面去介绍如何减少内存开销和重用资源
  • 听说,你想让自己的Go程序运行的更

    千次阅读 多人点赞 2016-04-22 15:07:57
    这主要是一篇,关于运行速度,而不是开发速度的文章——这两种速度是有区别的。 我曾经和很多聪明的人一起工作。我们很多人都对性能问题很痴迷,我们之前所做的是尝试逼近能够预期的(性能)的极限。应用引擎有一些...
  • ANDROID内存优化(汇总——上)

    万次阅读 多人点赞 2014-08-15 00:20:00
    ANDROID内存优化以及原理汇总,本文包括内存简单介绍,堆栈特性对比,分析Android系统内存和堆内存的方法工具介绍。
  • 充分利用大内存提升电脑速度

    千次阅读 2011-07-04 13:18:48
    内存,机器越快?我想大多数人的回答都是肯定的,从256M到512M的提示是明显的,所以想当然的,从512M到1G的提升也会很明显吧。但是我用我的亲身经历告诉你,1G的内存比512M还慢,当然前提是你什么都不设置。  ...
  • MySQL内存调优

    万次阅读 2014-05-28 20:50:05
    原文链接: MySQL Memory Allocation -- by Rick James 原文日期: Created 2010; Refreshed Oct, 2012, Jan, 2014  翻译人员: 铁锚 翻译日期: 2014年5月28日 MySQL 内存分配—— 快速设置方案 ...为可用内存的20%,(再
  • vm options里面输入:-server -XX:PermSize=128M -XX:MaxPermSize=256m我的电脑只有4G运行内存,采用默认的idea配置,内存在30分钟内会飚到 >80% ,同时会发生OOM ! Chrome 就不敢打开!通过上面的配置可以将内存...
  • Android内存管理机制详解

    万次阅读 多人点赞 2012-12-13 10:37:33
    与windows内存区别 在Linux中经常发现空闲...主要特点是,无论物理内存有多,Linux都将其充份利用,将一些程序调用过的硬盘数据读入内存,利用内存读写的高速特性来提高Linux系统的数据访问性能。而Windows是只在
  • 在Java中,内存的分配是由程序完成的,而内存的释放是由垃圾收集器(Garbage Collection,GC)完成的,程序员不需要通过调用函数来释放内存,但也随之带来了内存泄漏的可能
  • App内存占用优化

    千次阅读 2017-01-12 18:47:04
    RAM(Random-access memory)在任何软件开发中都是非常宝贵的资源,移动操作系统由于其物理内存的局限性更是如此。尽管ART(Android Runtime)与Dalvik虚拟机会执行常规的垃圾回收,但这并不意味着可以忽略App中的...
  • 如何把开发机器运行速度搞

    千次阅读 2013-05-09 01:43:49
    工欲善其事,必先利其器。作为开发人员,天天和电脑打交道,电脑就是我们混饭吃的工具了。...首先硬件是根本,现在硬件也便宜,4G内存才不到两百,1T硬盘也才450不到,几千块钱能折腾出很好的机器。记得我们读
  • Java内存区域与内存溢出

    千次阅读 2020-02-09 17:27:55
    Java与C语言针对“内存管理”有很的不同。 在C语言中,开发者需要维护对象的出生和死亡,往往需要为每个new出来的对象编写配套的delete/free代码来释放内存,否则可能发生内存泄漏或溢出。 而在Java中,内存由JVM...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 177,918
精华内容 71,167
关键字:

内存越大运行越快吗