1. 程式人生 > >JVM調優總結 -Xms -Xmx -Xmn -Xss(轉自:iteye unixboy)

JVM調優總結 -Xms -Xmx -Xmn -Xss(轉自:iteye unixboy)

  • -XX:PrintHeapAtGC:列印GC前後的詳細堆疊資訊
    輸出形式:
    34.702: [GC {Heap before gc invocations=7:
     def new generation   total 55296K, used 52568K [0x1ebd0000, 0x227d0000, 0x227d0000)
    eden space 49152K,  99% used [0x1ebd0000, 0x21bce430, 0x21bd0000)
    from space 6144K,  55% used [0x221d0000, 0x22527e10, 0x227d0000)
      to   space 6144K,   0% used [0x21bd0000, 0x21bd0000, 0x221d0000)
     tenured generation   total 69632K, used 2696K [0x227d0000, 0x26bd0000, 0x26bd0000)
    the space 69632K,   3% used
     [0x227d0000, 0x22a720f8, 0x22a72200, 0x26bd0000)
     compacting perm gen  total 8192K, used 2898K [0x26bd0000, 0x273d0000, 0x2abd0000)
       the space 8192K,  35% used [0x26bd0000, 0x26ea4ba8, 0x26ea4c00, 0x273d0000)
        ro space 8192K,  66% used [0x2abd0000, 0x2b12bcc0, 0x2b12be00, 0x2b3d0000)
        rw space 12288K,  46% used [0x2b3d0000, 0x2b972060, 0x2b972200, 0x2bfd0000)
    34.735: [DefNew: 52568K->3433K(55296K), 0.0072126 secs] 55264K->6615K(124928K)Heap after gc invocations=8:
     def new generation   total 55296K, used 3433K [0x1ebd0000, 0x227d0000, 0x227d0000)
    eden space 49152K,   0% used [0x1ebd0000, 0x1ebd0000, 0x21bd0000)
      from space 6144K,  55% used [0x21bd0000, 0x21f2a5e8, 0x221d0000)
      to   space 6144K,   0% used [0x221d0000, 0x221d0000, 0x227d0000)
     tenured generation   total 69632K, used 3182K [0x227d0000, 0x26bd0000, 0x26bd0000)
    the space 69632K,   4% used 
    [0x227d0000, 0x22aeb958, 0x22aeba00, 0x26bd0000)
     compacting perm gen  total 8192K, used 2898K [0x26bd0000, 0x273d0000, 0x2abd0000)
       the space 8192K,  35% used [0x26bd0000, 0x26ea4ba8, 0x26ea4c00, 0x273d0000)
        ro space 8192K,  66% used [0x2abd0000, 0x2b12bcc0, 0x2b12be00, 0x2b3d0000)
        rw space 12288K,  46% used [0x2b3d0000, 0x2b972060, 0x2b972200, 0x2bfd0000)
    }
    , 0.0757599 secs]
  • 相關推薦

    JVM調總結 -Xms -Xmx -Xmn -Xssiteye unixboy

    -XX:PrintHeapAtGC:列印GC前後的詳細堆疊資訊 輸出形式: 34.702: [GC {Heap before gc invocations=7:  def new generation   total 55296K, used 52568K [0x1ebd0000, 0x227d0000, 0

    JVM調總結 -Xms -Xmx -Xmn -Xss轉載

    -XX:PrintHeapAtGC:列印GC前後的詳細堆疊資訊 輸出形式: 34.702: [GC {Heap before gc invocations=7:  def new generation   total 55296K, used 52568K [0x1ebd0000, 0x227d0

    JVM調總結 -Xms -Xmx -Xmn -Xss

    都是 直接 並行 span edt 支持 線程 gcs 如果 堆大小設置JVM 中最大堆大小有三方面限制:相關操作系統的數據模型(32-bt還是64-bit)限制;系統的可用虛擬內存限制;系統的可用物理內存限制。32位系統下,一般限制在1.5G~2G;64為操作系統對內存

    java JVM調總結 -Xms -Xmx -Xmn -Xss

    堆大小設定 JVM 中最大堆大小有三方面限制:相關作業系統的資料模型(32-bt還是64-bit)限制;系統的可用虛擬記憶體限制;系統的可用實體記憶體限制。32位系統下,一般限制在1.5G~2G;64為作業系統對記憶體無限制。我在Windows Server 2003 系統,3.5G實體記憶體,JDK5

    JVM調總結 -Xms -Xmx -Xmn -Xss【轉載】

    堆大小設定JVM 中最大堆大小有三方面限制:相關作業系統的資料模型(32-bt還是64-bit)限制;系統的可用虛擬記憶體限制;系統的可用實體記憶體限制。32位系統下,一般限制在1.5G~2G;64為作業系統對記憶體無限制。我在Windows Server 2003 系統,3

    JVM 參數配置及詳解 -Xms -Xmx -Xmn -Xss 調總結

    同事 turn windows系統 程序運行時間 ria 設定 是不是 total 適用於 堆大小設置 JVM 中最大堆大小有三方面限制:相關操作系統的數據模型(32-bt還是64-bit)限制;系統的可用虛擬內存限制;系統的可用物理內存限制.32位系統 下,一般限制在1.

    java jvm 引數 -Xms -Xmx -Xmn -Xss 調總結

    常見配置舉例 堆大小設定 JVM 中最大堆大小有三方面限制:相關作業系統的資料模型(32-bt還是64-bit)限制;系統的可用虛擬記憶體限制;系統的可用實體記憶體限制.32位系統 下,一般限制在1.5G~2G;64為作業系統對記憶體無限制.我在Windows Server 2003 系統,3.5G實體記

    JVM調總結

    clas 時間 filename oca 物理 初始 ati res 大堆 堆大小設置JVM 中最大堆大小有三方面限制:相關操作系統的數據模型(32-bt還是64-bit)限制;系統的可用虛擬內存限制;系統的可用物理內存限制。32位系統下,一般限制在1.5G~2G;64為

    JVM調總結-分代垃圾回收詳述

    web服務器 mar you 數量 不變 all 時間 lis 完成 為什麽要分代 分代的垃圾回收策略,是基於這樣一個事實:不同的對象的生命周期是不一樣的。因此,不同生命周期的對象可以采取不同的收集方式,以便提高回收效率。 在Java程序運行的過程中,會

    JVM調總結-調方法

    圖片 死鎖 ron 詳細信息 ict 時間 最大 bsp 底部 JVM調優工具 Jconsole,jProfile,VisualVM Jconsole : jdk自帶,功能簡單,但是可以在系統有一定負荷的情況下使用。對垃圾回收算法有很詳細的跟蹤。詳細說明參考這裏 JP

    JVM調總結-反思

    pdf col 實現 aio https 重要 簡單 什麽 tps 垃圾回收的悖論 所謂“成也蕭何敗蕭何”。Java的垃圾回收確實帶來了很多好處,為開發帶來了便利。但是在一些高性能、高並發的情況下,垃圾回收確成為了制約Java應用的瓶頸。目

    JVM調總結-垃圾回收面臨的問題

    也會 直接 問題 行程 完成 情況 出現 基本類型 不能 如何區分垃圾 上面說到的“引用計數”法,通過統計控制生成對象和刪除對象時的引用數來判斷。垃圾回收程序收集計數為0的對象即可。但是這種方法無法解決循環引用。所以,後來實現的垃圾判斷算法

    JVM調總結-基本垃圾回收算法

    會有 width 順序 系統 不知道 對待 循環引用 compact 垃圾回收算法 可以從不同的的角度去劃分垃圾回收算法: 按照基本回收策略分 引用計數(Reference Counting): 比較古老的回收算法。原理是此對象有一個引用,即增加一個計數,刪除一

    JVM調總結十一-反思

    垃圾回收的悖論     所謂“成也蕭何敗蕭何”。Java的垃圾回收確實帶來了很多好處,為開發帶來了便利。但是在一些高效能、高併發的情況下,垃圾回收確成為了制約Java應用的瓶頸。目前JDK的垃圾回收演算法,始終無法解決垃圾回收時的暫停問題,因為這個暫停嚴重影響了程式

    JVM調總結-調方法

    JVM調優工具 Jconsole,jProfile,VisualVM   Jconsole : jdk自帶,功能簡單,但是可以在系統有一定負荷的情況下使用。對垃圾回收演算法有很詳細的跟蹤。詳細說明參考這裡   JProfiler:商業軟體,需要付費。

    JVM調總結-分代垃圾回收詳述2

    分代垃圾回收流程示意     選擇合適的垃圾收集演算法 序列收集器   用單執行緒處理所有垃圾回收工作,因為無需多執行緒互動,所以效率比較高。但是,也無法使用多處理器的優勢,所以此收集器適合單處理器機器。當然,此收集

    JVM調總結-分代垃圾回收詳述1

    為什麼要分代     分代的垃圾回收策略,是基於這樣一個事實:不同的物件的生命週期是不一樣的。因此,不同生命週期的物件可以採取不同的收集方式,以便提高回收效率。       在Java程式執行的過程中,會產生大量的物件

    JVM調總結(轉載)

    轉載:https://blog.csdn.net/wuzhilon88/article/details/49201891 一.堆大小設定  JVM 中最大堆大小有三方面限制:相關作業系統的資料模型(32-bt還是64-bit)限制;系統的可用虛擬記憶體限制;系統的可用實體記憶體限制。32位系統下,一般限制在

    JVM調總結-----一些概念

    Java物件的大小     基本資料的型別的大小是固定的,這裡就不多說了。對於非基本型別的Java物件,其大小就值得商榷。     在Java中,一個空Object物件的大小是8byte,這個大小隻是儲存堆中一個沒有任何屬性的物件的

    JVM調總結(目前看過最全的)

    Xms 是指設定程式啟動時佔用記憶體大小。一般來講,大點,程式會啟動的快一點,但是也可能會導致機器暫時間變慢。 Xmx 是指設定程式執行期間最大可佔用的記憶體大小。如果程式執行需要佔用更多的記憶體,超出了這個設定值,就會丟擲OutOfMemory異常。 Xss 是指設定每個執行緒的堆疊大小。