在Mac OSX啟用單鍵拖曳

從Mac OSX 10.9開始，內建的觸控版手勢就取消了單鍵拖曳的功能，改成用三指拖曳。不過我覺得不是那麼直覺好用，還是覺得單鍵拖曳好用。所幸，還是可以重新開啟此功能。
只要到「系統偏好設定」-->「輔助使用」-->「滑鼠與觸控式軌跡板」中，打開「觸控式軌跡板選項」，將「啟用拖移」打勾後，就可以在要拖曳的目標上用單指連點兩下後拖移。該選項還有設定：帶拖移鎖定、不帶拖移鎖定，主要是指拖移時如果放開手指，拖移鎖定是否仍然保留。若選擇「不帶拖移鎖定」，則放開後就解除，要再拖移，就得重新單指雙擊目標。

Java GC Tuning Guide episode 1 - GC logging

Java的GC讓開發人員減少處理記憶體配置的負擔，但是GC的運作方式與調整也關係到整個Java程式的運作效率與穩定性。先前一直有點半逃避的忽視這部份的東西，大都是用網路搜尋到的一些既有調整參數直接設了，不過該來的終究是要來，只靠一些別人的設定與調整方法，果然還是難以達到最佳的情況。要設定針對自己開發的程式/系統的最佳GC設定，還是得自己來追蹤與分析。

既然要自己追蹤與分析GC的情況，首先就必須有可以分析的資料，而最直接有用的就是GC log。以下說明如何透過JVM option啟用GC log來紀錄GC的內容：

• -XX:+PrintGCDetails
• 啟用此參數可讓JVM輸出所有詳細的GC行為，包含GC的類型(一般 or Full, Full GC會造成程式/系統暫停)，以及JVM內各記憶體配置區塊的GC動作情況與耗費時間等，資訊相當完整。
• -XX:+PrintGCTimeStamps 與-XX:+PrintGCDateStamps
• 這兩個參數是讓JVM在輸出GC log時，也順便加上時間資訊；PrintGCTimeStamps 是以程式啟動時間的相對時間做紀錄，而PrintGCDateStamps則是以系統的絕對時間做紀錄。兩者可擇一或並存。加上時間紀錄有助於分析與判斷。
• -Xloggc:<file name>
• 預設啟用gc log時，是輸出到console上，但是這樣不便於閱讀與分析，所以此參數可以指定輸出到檔案上
• -XX:+UseGCLogFileRotation
• 使用上一個參數時，會將所有的gc log寫到同一個檔案。如果不想讓檔案不斷成長，可以使用此參數將gc log檔固定在一定數量大小。注意：使用此參數，也必須搭配以下兩個參數才能正確運作
• -XX:NumberOfGCLogFiles=<number of files>
• 指定要保留的gc log檔數量，預設為1
• -XX:GCLogFileSize=<file size>
• 指定要保留的單一gc log檔大小，預設512K，可用M or K指定大小，如128M。

設定好之後啟動程式，即可在指定檔案中存下完整的gc log。以下是gc log範例(注意：輸出格式可能因不同JVM版本而有所出入)：

 0.011: [G1Ergonomics (Heap Sizing) expand the heap, requested expansion amount: 128974848 bytes, attempted expansion amount: 128974848 bytes]
2014-10-27T13:49:46.166+0800: 1.114: [GC pause (young) 1.114: [G1Ergonomics (CSet Construction) start choosing CSet, _pending_cards: 2283, predicted base time: 23.70 ms, remaining time: 176.30 ms, target pause time: 200.00 ms]
 1.114: [G1Ergonomics (CSet Construction) add young regions to CSet, eden: 14 regions, survivors: 0 regions, predicted young region time: 356.52 ms]
 1.114: [G1Ergonomics (CSet Construction) finish choosing CSet, eden: 14 regions, survivors: 0 regions, old: 0 regions, predicted pause time: 380.22 ms, target pause time: 200.00 ms]
, 0.0200610 secs]
   [Parallel Time: 13.7 ms, GC Workers: 4]
      [GC Worker Start (ms): Min: 1113.8, Avg: 1117.5, Max: 1123.2, Diff: 9.4]
      [Ext Root Scanning (ms): Min: 0.0, Avg: 1.3, Max: 2.8, Diff: 2.8, Sum: 5.3]
      [Update RS (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0]
         [Processed Buffers: Min: 0, Avg: 2.8, Max: 11, Diff: 11, Sum: 11]
      [Scan RS (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.1]
      [Code Root Scanning (ms): Min: 0.0, Avg: 0.2, Max: 0.6, Diff: 0.6, Sum: 0.7]
      [Object Copy (ms): Min: 0.4, Avg: 5.6, Max: 10.8, Diff: 10.4, Sum: 22.6]
      [Termination (ms): Min: 0.0, Avg: 2.6, Max: 3.8, Diff: 3.8, Sum: 10.4]
      [GC Worker Other (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.1]
      [GC Worker Total (ms): Min: 4.1, Avg: 9.8, Max: 13.6, Diff: 9.5, Sum: 39.2]
      [GC Worker End (ms): Min: 1127.3, Avg: 1127.3, Max: 1127.5, Diff: 0.2]
   [Code Root Fixup: 0.3 ms]
   [Code Root Migration: 1.1 ms]
   [Clear CT: 0.1 ms]
   [Other: 4.8 ms]
      [Choose CSet: 0.0 ms]
      [Ref Proc: 4.6 ms]
      [Ref Enq: 0.0 ms]
      [Free CSet: 0.0 ms]
   [Eden: 14.0M(14.0M)->0.0B(15.0M) Survivors: 0.0B->2048.0K Heap: 14.0M(123.0M)->4084.5K(123.0M)]
 [Times: user=0.03 sys=0.01, real=0.02 secs] 

透過這些log資訊，就可以了解程式/系統運作時的gc行為，進而調整至最適合的設定。
當然，以人工方式來分析gc log，是很困難的，因此也有一些工具可以幫忙。 目前個人使用GCViewer來幫忙處理與分析，雖然不算是很完美，但是也幫了不少忙。

Ubuntu gnome-panel設定方式與注意事項

Ubuntu從11.10後續的新版的UI都改用Unity。如果不喜歡Unity，可以自行安裝gnome-panel與gnome-session來調整。但是後來新版的gnome-panel的設定方式與原本有些差異：

• 設定：新版gnome-panel要設定的話，是不能直接在上頭按右鍵叫出選單的。必須按住鍵盤的Windows鍵+Alt，再按右鍵
• 如果在增加與設定gnome-applet時，發生問題，可以用：

  dconf reset -f /org/gnome/gnome-panel/    

  來重設整個gnome-panel，不過此方法似乎只適用於Ubuntu 13.04之後

建議設定完畢後重新登入或是使用killall gnome-panel來重啟gnome-panel

JVM參數調教

官方的JDK裡的JVM已經越來越成熟，效能也越來越好，但是還是有可調教的空間。可調教的參數也跟著JDK演進而有所不同。根據網路上一些文章，大概比較普遍的調教參數有以下幾個：

• -XX:+AggressiveOpts
• -XX:+UseCompressedOops
• -XX:+DoEscapeAnalysis
• -XX:+UseBiasedLocking
• -XX:+EliminateLocks

其中，第一個參數是用來調整一些預設的效能參數，啟用之後相當於調整了AutoBoxCacheMax, BiasedLockingStartupDelay, EliminateAutoBox, OptimizeFill, OptimizeStringComcat這幾個參數。第二個參數則是使用在64bit環境中，可以降低JVM在64-bit環境裡的記憶體使用量，並提升效能。後三個參數則是用來減少lock的使用情況，以提升效能。

另外還有一些參數也可能可以改善效能，但是因為沒有太多實務案例，所以無法100%肯定。

• -XX:MaxGCPauseMillis：設定GC的暫停時間目標值，此數值可限制JVM的GC造成的暫停時間，但是無法精準限制。降低此數值可以減少JVM的延遲，但是可能會造成過多的GC與Throughput下降。
• -XX:+UseG1GC：啟用JDK7以後新增加的G1GC功能，據說效果比原本的CMS好
• -XX:+UseStringCache：就名稱來看應該是跟String有關的，但是實際效果不明，有人提過可搭配-XX:+PrintStringTableStatistics 和 -XX:StringTableSize=來調整StringCache大小
• -XX:CompileThreshold=n：設定method在多少次呼叫後，轉換為機械碼。此數值越大，代表有越多profile資訊來轉換，可轉換出越高效率的機械碼。越低的話，代表越快進行轉換。JVM預設如果是client模式為1000，server模式為10000
• -XX:+TieredCompilation：使用多層式的機械碼轉換方式。啟用此設定，可改設原本一次性轉換後的機械碼效率。在server模式預設啟用。
• -XX:+UseLargePages：啟用Large Page的記憶體存取能力，需要OS支援。
• -XX:MaxInlineSize=n：設定在n byte內的method會被用inline方式編譯，此數值越大，越能改善執行效率。但過大的數值會造成JVM的記憶體佔用過大。
• -XX:ReservedCodeCacheSize=n：設定預設保留的CodeCache大小。當設定-XX:MaxInlineSize=n較大，或是-XX:CompileThreshold=n較小時，最好可以將此數值加大，否則可能會發生問題。
• -XX:+UseCodeCacheFlushing：會將CodeCache進行清理，但實際上怎麼清理並不清楚。
• -XX:+UseFastAccessorMethods, -XX:+UseFastEmptyMethods, -XX:+UseFastJNIAccessors：加速這些method的呼叫與執行
• -Dawt.nativeDoubleBuffering=true：在GUI模式下，使用Double buffering來改善繪製效能
• -Djava.net.preferIPv4Stack=true：讓JVM優先使用IPv4。可避免部分因IPv6造成的問題，以及改善連線效能。
• -Djdk.map.althashing.threshold=n：啟用JDk7u6的新Hash function演算法，可改進效能。n值是指當Set或Map的大小達到時，才使用新演算法。若n=0，則表示強制使用新演算法。注意：新演算法可能造成在iterator順序上的改變(對LinkedHashSet與LinkedHashMap不造成影響)。
• -XX:SoftRefLRUPolicyMSPerMB=n：指Soft Reference物件的生命週期。預設為1000ms，此數值設定越小，可加快Soft Reference物件被回收的速度。

以上是目前大略整理出的一些參數。上述參數的預設值可能因版本不同而有所不同。可以下列命令列出目前JVM支援的參數與預設值：

java -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal -version

或是

java -XX:+UnlockDiagnosticVMOptions -XX:+UnlockExperimentalVMOptions -XX:+PrintFlagsFinal -version (包含實驗性功能)

可另用pipeline將結果輸出至檔案。

以下是一些參考資料：

Hotspot JVM Options - The complete reference

Useful JVM Flags – Part 6 (Throughput Collector)

Java HotSpot VM Options

JVM performance options. How it works?

Other JVM Options To Consider

Do Java 6 threading optimizations actually work?

Speedup Your Collections with Improved Hashing Function from Java7

Redmine 效能改進

在公司的虛擬機上安裝的Bitnami Redmine stack一直在新增與更新issue時會有等待很長時間的問題。在搜尋了一下，研究了一下。有以下兩種解法，此兩種可同時搭配：

• Phusion Passenger module的問題

• 這問題是出在Passenger module預設是300秒idle之後就會自動關閉。解決方法就是在apache/conf/bitnami/passenger.conf加上 PassengerPoolIdleTime 0，讓他永遠不會被關閉。當然也可加上額外設定。可參考：PassengerPoolIdleTime , 或是Ubuntu + Redmine + Apache2 + Passenger + Enterprise Ruby + MySQL 

• email send的問題

•  此問題是因為Redmine預設使用同步的email發送機制，所以當連線mail server需要時間較久或連不上時，就會導致整個回應變慢。解決方法就是在configuration.yml裡將原本的:smtp改為async_smtp即可。可參考：Asynchronous Email Delivery

以上作法在修改後都必須重新啟動Redmine

在Linux上啟用Tomcat JMX Remote之二三事

對於Tomcat要啟動JMX Remote的功能，只要遵照官網說明，在catalina.sh or catalina.bat設定系統參數就可以。
不過，在Linux上在啟用就麻煩多了。首先，在linux上可能無法正確的bind到正確的ip，所以如果發現設定後無法連上JMX MBean，就在catalina.sh中，多加一個系統參數

-Djava.rmi.server.hostname=<正確的host ip>

此處的ip不可為localhost或是127.0.0.1。
如果Linux是有開防火牆的話，就會更麻煩。因為JMX預設的情況是會使用一個固定的port作為registry用，另外會再使用一個隨機的port作為service通訊用。registry用的port，可以透過系統參數指定，但是service通訊用的卻不行，所以在此情況下，是無法開通防火牆的。所幸，Tomcat有提供一個元件可以來設定。到Tomcat下載頁面下載Tomcat JMX Remote jar，並放到lib資料夾中，然後修改conf/server.xml，加入以下內容

<Listener className="org.apache.catalina.mbeans.JmxRemoteLifecycleListener" rmiRegistryPortPlatform="10001" rmiServerPortPlatform="10002" />

，其中rmiRegistryPortPlatform就是指registry port, 而rmiServerPortPlatform就是指真正service通訊用的port

只要將這兩個port在防火牆中開通，就可以從外部來監控Tomcat了。

改變Ubuntu中使用者家目錄下的預設資料夾名稱

忘記從哪一版的Ubuntu開始，只要選擇安裝繁體中文版的Ubuntu，則使用者的家目錄(/home/[user id])裡的預設資料夾，如「影片」「圖片」等，都會以中文名稱建立...從GUI介面來操作可能還不是大問題，但是如果是從console操作，就變得很麻煩了....

之前版本的Ubuntu還可以透過更改語系(繁體中文<->英文)的方式，觸發一個GUI程式，詢問是否改變這些預設資料夾的名稱。只要先切換到英文語系，就會詢問是否改成英文名稱，此時選擇「是」；然後再切換回繁體中文語系，一樣會再次詢問，此時只要選擇「保留舊名稱」，就可以在繁體中文環境裡有英文的預設資料夾名稱了

但是這招在Ubuntu卻不管用了...還好透過Google search，找到解決方法，而且感覺也蠻簡單的。步驟如下：

1. 打開console視窗，先使用以下指令確認目前語系：echo $LANG
2. 然後輸入export LANG=en_US，將語系變更為「英文」
3. 接著輸入xdg-user-dirs-gtk-update，此時就會出現前述所提到的GUI的資料夾更名程式，然後選擇「更名」，就可以將預設資料夾改為英文
4. 完成更名後，在console視窗中輸入export LANG=[步驟1記下的語系設定]，然後再做一次步驟3，此時要選擇「保留舊名稱」，這樣就大功告成了！

上述作法是參考：Ubuntu一開始最討人厭的資料夾名稱