java - 2つの異なるプラットフォームでのJavaコードの実行時の違い

Question

2つの異なるサーバーにJavaコードをデプロイしました。コードはファイル書き込み操作を実行しています。

ローカルサーバーでは、パラメータは次のとおりです。

uname -a

SunOS snmi5001 5.10 Generic_120011-14 sun4u sparc SUNW,SPARC-Enterprise

ulimit -a

time(seconds)        unlimited
file(blocks)         unlimited
data(kbytes)         unlimited
stack(kbytes)        389296
coredump(blocks)     unlimited
nofiles(descriptors) 20000
vmemory(kbytes)      unlimited

Javaバージョン：

java version "1.5.0_12"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04)
Java HotSpot(TM) Server VM (build 1.5.0_12-b04, mixed mode)

別の（MITとしましょう）サーバー上：

uname -a

SunOS au11qapcwbtels2 5.10 Generic_147440-05 sun4u sparc SUNW,Sun-Fire-15000

ulimit -a

time(seconds)        unlimited
file(blocks)         unlimited
data(kbytes)         unlimited
stack(kbytes)        8192
coredump(blocks)     unlimited
nofiles(descriptors) 256
vmemory(kbytes)      unlimited

javaバージョン

java version "1.5.0_32"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_32-b05)
Java HotSpot(TM) Server VM (build 1.5.0_32-b05, mixed mode)

問題は、MITサーバーでコードの実行速度が大幅に低下することです。2つのOSのnofilesとstackが異なるため、を変更すると違いが生じると思いulimit -sましulimit -nた。問題を確認せずにMITサーバーのパラメーターを変更できないため、ローカルサーバーのulimitパラメーターを減らして再テストしましたが、コードの実行が同時に終了しました。

これを引き起こしている可能性のあるOSパラメータの違いがわかりません。助けていただければ幸いです。誰かが私に何を探すべきか教えてくれたら、私はもっと多くのパラメータを投稿します。

編集：

MITサーバーの場合

CPUの数：psrinfo -p 24 psrinfo -pv

The physical processor has 2 virtual processors (0 4)
  UltraSPARC-IV+ (portid 0 impl 0x19 ver 0x24 clock 1800 MHz)
The physical processor has 2 virtual processors (1 5)
  UltraSPARC-IV+ (portid 1 impl 0x19 ver 0x24 clock 1800 MHz)
The physical processor has 2 virtual processors (2 6)
  UltraSPARC-IV+ (portid 2 impl 0x19 ver 0x24 clock 1800 MHz)
The physical processor has 2 virtual processors (3 7)
  UltraSPARC-IV+ (portid 3 impl 0x19 ver 0x24 clock 1800 MHz)
The physical processor has 2 virtual processors (32 36)
  UltraSPARC-IV+ (portid 32 impl 0x19 ver 0x24 clock 1800 MHz)
The physical processor has 2 virtual processors (33 37)
  UltraSPARC-IV+ (portid 33 impl 0x19 ver 0x24 clock 1800 MHz)
The physical processor has 2 virtual processors (34 38)
  UltraSPARC-IV+ (portid 34 impl 0x19 ver 0x24 clock 1800 MHz)
The physical processor has 2 virtual processors (35 39)
  UltraSPARC-IV+ (portid 35 impl 0x19 ver 0x24 clock 1800 MHz)
The physical processor has 2 virtual processors (64 68)
  UltraSPARC-IV+ (portid 64 impl 0x19 ver 0x24 clock 1800 MHz)
The physical processor has 2 virtual processors (65 69)
  UltraSPARC-IV+ (portid 65 impl 0x19 ver 0x24 clock 1800 MHz)
The physical processor has 2 virtual processors (66 70)
  UltraSPARC-IV+ (portid 66 impl 0x19 ver 0x24 clock 1800 MHz)
The physical processor has 2 virtual processors (67 71)
  UltraSPARC-IV+ (portid 67 impl 0x19 ver 0x24 clock 1800 MHz)
The physical processor has 2 virtual processors (96 100)
  UltraSPARC-IV+ (portid 96 impl 0x19 ver 0x24 clock 1800 MHz)
The physical processor has 2 virtual processors (97 101)
  UltraSPARC-IV+ (portid 97 impl 0x19 ver 0x24 clock 1800 MHz)
The physical processor has 2 virtual processors (98 102)
  UltraSPARC-IV+ (portid 98 impl 0x19 ver 0x24 clock 1800 MHz)
The physical processor has 2 virtual processors (99 103)
  UltraSPARC-IV+ (portid 99 impl 0x19 ver 0x24 clock 1800 MHz)
The physical processor has 2 virtual processors (128 132)
  UltraSPARC-IV+ (portid 128 impl 0x19 ver 0x24 clock 1800 MHz)
The physical processor has 2 virtual processors (129 133)
  UltraSPARC-IV+ (portid 129 impl 0x19 ver 0x24 clock 1800 MHz)
The physical processor has 2 virtual processors (130 134)
  UltraSPARC-IV+ (portid 130 impl 0x19 ver 0x24 clock 1800 MHz)
The physical processor has 2 virtual processors (131 135)
  UltraSPARC-IV+ (portid 131 impl 0x19 ver 0x24 clock 1800 MHz)
The physical processor has 2 virtual processors (224 228)
  UltraSPARC-IV+ (portid 224 impl 0x19 ver 0x24 clock 1800 MHz)
The physical processor has 2 virtual processors (225 229)
  UltraSPARC-IV+ (portid 225 impl 0x19 ver 0x24 clock 1800 MHz)
The physical processor has 2 virtual processors (226 230)
  UltraSPARC-IV+ (portid 226 impl 0x19 ver 0x24 clock 1800 MHz)
The physical processor has 2 virtual processors (227 231)
  UltraSPARC-IV+ (portid 227 impl 0x19 ver 0x24 clock 1800 MHz)

kstat cpu_info：

module: cpu_info                        instance: 231
name:   cpu_info231                     class:    misc
       brand                           UltraSPARC-IV+
       chip_id                         227
       clock_MHz                       1800
       core_id                         231
       cpu_fru                         hc:///component=SB7
       cpu_type                        sparcv9
       crtime                          587.102844985
       current_clock_Hz                1799843256
       device_ID                       9223937394446500460
       fpu_type                        sparcv9
       implementation                  UltraSPARC-IV+ (portid 227 impl 0x19 ver 0x24 clock 1800 MHz)
       pg_id                           48
       snaptime                        19846866.5310415
       state                           on-line
       state_begin                     1334854522

ローカルサーバーの場合、kstat情報しか取得できませんでした：

module: cpu_info                        instance: 0
name:   cpu_info0                       class:    misc
        brand                           SPARC64-VI
        chip_id                         1024
        clock_MHz                       2150
        core_id                         0
        cpu_fru                         hc:///component=/MBU_A/CPUM0
        cpu_type                        sparcv9
        crtime                          288.5675516
        device_ID                       250691889836161
        fpu_type                        sparcv9
        implementation                  SPARC64-VI (portid 1024 impl 0x6 ver 0x93 clock 2150 MHz)
        snaptime                        207506.8330168
        state                           on-line
        state_begin                     1354493257

module: cpu_info                        instance: 1
name:   cpu_info1                       class:    misc
        brand                           SPARC64-VI
        chip_id                         1024
        clock_MHz                       2150
        core_id                         0
        cpu_fru                         hc:///component=/MBU_A/CPUM0
        cpu_type                        sparcv9
        crtime                          323.4572206
        device_ID                       250691889836161
        fpu_type                        sparcv9
        implementation                  SPARC64-VI (portid 1024 impl 0x6 ver 0x93 clock 2150 MHz)
        snaptime                        207506.8336113
        state                           on-line
        state_begin                     1354493292

Similarly total 59 instances .

また、ローカルサーバーのメモリ：vmstat

 kthr      memory            page            disk          faults      cpu
 r b w   swap  free  re  mf pi po fr de sr s0 s1 s4 s1   in   sy   cs us sy id
 0 0 0 143845984 93159232 431 895 1249 30 29 0 2 6 0 -0 1 3284 72450 6140 11 3 86

MITサーバーのメモリ：vmstat

kthr      memory            page            disk          faults      cpu
r b w   swap  free  re  mf pi po fr de sr m0 m1 m2 m3   in   sy   cs us sy id
0 0 0 180243376 184123896 81 786 248 15 15 0 0 3 14 -0 4 1854 7563 2072 1 1 98

MITサーバーの場合はdf-h：

Filesystem             Size   Used  Available Capacity  Mounted on
/dev/md/dsk/d0         7.9G   6.7G       1.1G    86%    /
/devices                 0K     0K         0K     0%    /devices
ctfs                     0K     0K         0K     0%    /system/contract
proc                     0K     0K         0K     0%    /proc
mnttab                   0K     0K         0K     0%    /etc/mnttab
swap                   171G   1.7M       171G     1%    /etc/svc/volatile
objfs                    0K     0K         0K     0%    /system/object
sharefs                  0K     0K         0K     0%    /etc/dfs/sharetab
/platform/sun4u-us3/lib/libc_psr/libc_psr_hwcap2.so.1
                       7.9G   6.7G       1.1G    86%    /platform/sun4u-us3/lib/libc_psr.so.1
/platform/sun4u-us3/lib/sparcv9/libc_psr/libc_psr_hwcap2.so.1
                       7.9G   6.7G       1.1G    86%    /platform/sun4u-us3/lib/sparcv9/libc_psr.so.1
/dev/md/dsk/d3         7.9G   6.6G       1.2G    85%    /var
swap                   6.0G    56K       6.0G     1%    /tmp
swap                   171G    40K       171G     1%    /var/run
swap                   171G     0K       171G     0%    /dev/vx/dmp
swap                   171G     0K       171G     0%    /dev/vx/rdmp
/dev/md/dsk/d5         2.0G   393M       1.5G    21%    /home
/dev/vx/dsk/appdg/oravl
                       2.0G    17M       2.0G     1%    /ora
/dev/md/dsk/d60        1.9G   364M       1.5G    19%    /apps/stats
/dev/md/dsk/d4          16G   2.1G        14G    14%    /var/crash
/dev/md/dsk/d61       1005M   330M       594M    36%    /opt/controlm6
/dev/vx/dsk/appdg/oraproductvl
                        10G   2.3G       7.6G    24%    /ora/product
/dev/md/dsk/d63        963M   1.0M       904M     1%    /var/opt/app
/dev/vx/dsk/dmldg/appsdmlsvtvl
                       1.0T   130G       887G    13%    /apps/dml/svt
/dev/vx/dsk/appdg/homeappusersvl
                        20G    19G       645M    97%    /home/app/users
/dev/vx/dsk/dmldg/appsdmlmit2vl
                        20G    66M        20G     1%    /apps/dml/mit2
/dev/vx/dsk/dmldg/datadmlmit2vl
                       1.9T   1.1T       773G    61%    /data/dml/mit2
/dev/md/dsk/d62        9.8G    30M       9.7G     1%    /usr/openv/netbackup/logs

ローカルサーバーの場合はdf-h：

   Filesystem             Size   Used  Available Capacity  Mounted on
/dev/dsk/c0t0d0s0       20G   7.7G        12G    40%    /
/devices                 0K     0K         0K     0%    /devices
ctfs                     0K     0K         0K     0%    /system/contract
proc                     0K     0K         0K     0%    /proc
mnttab                   0K     0K         0K     0%    /etc/mnttab
swap                   140G   1.6M       140G     1%    /etc/svc/volatile
objfs                    0K     0K         0K     0%    /system/object
fd                       0K     0K         0K     0%    /dev/fd
/dev/dsk/c0t0d0s5      9.8G   9.3G       483M    96%    /var
swap                   140G   504K       140G     1%    /tmp
swap                   140G    80K       140G     1%    /var/run
swap                   140G     0K       140G     0%    /dev/vx/dmp
swap                   140G     0K       140G     0%    /dev/vx/rdmp
/dev/dsk/c0t0d0s6      9.8G   9.4G       403M    96%    /opt
/dev/vx/dsk/eva8k/tlkhome
                       2.0G    66M       1.8G     4%    /tlkhome
/dev/vx/dsk/eva8k/tlkuser4
                        48G    26G        20G    57%    /tlkuser4
/dev/vx/dsk/eva8k/ST82
                       1.1G    17M       999M     2%    /ST_A_82
/dev/vx/dsk/eva8k/tlkuser11
                        37G    37G       176M   100%    /tlkuser11
/dev/vx/dsk/eva8k/oravl97
                        20G    12G       7.3G    63%    /oravl97
/dev/vx/dsk/eva8k/tlkuser5
                        32G    23G       8.3G    74%    /tlkuser5
/dev/vx/dsk/eva8k/mbtlkproj1
                       2.0G    18M       1.9G     1%    /mbtlkproj1
/dev/vx/dsk/eva8k/Oravol98
                        38G    25G        12G    68%    /oravl98
/dev/vx/dsk/eva8k_new/tlkuser15
                        57G    57G         0K   100%    /tlkuser15
/dev/vx/dsk/eva8k/Oravol1
                        39G    16G        22G    42%    /oravl01
/dev/vx/dsk/eva8k/Oravol99
                        30G   8.3G        20G    30%    /oravl99
/dev/vx/dsk/eva8k/tlkuser9
                        18G    13G       4.8G    73%    /tlkuser9
/dev/vx/dsk/eva8k/oravl08
                        32G    25G       6.3G    81%    /oravl08
/dev/vx/dsk/eva8k/oravl07
                        46G    45G       1.2G    98%    /oravl07
/dev/vx/dsk/eva8k/Oravol3
                       103G    90G        13G    88%    /oravl03
/dev/vx/dsk/eva8k_new/tlkuser12
                        79G    79G         0K   100%    /tlkuser12
/dev/vx/dsk/eva8k/Oravol4
                        88G    83G       4.3G    96%    /oravl04
/dev/vx/dsk/eva8k/oravl999
                        10G   401M       9.0G     5%    /oravl999
/dev/vx/dsk/eva8k_new/tlkuser14
                        54G    39G        15G    73%    /tlkuser14
/dev/vx/dsk/eva8k/Oravol2
                        85G    69G        14G    84%    /oravl02
/dev/vx/dsk/eva8k/sdkhome
                       1.0G    17M       944M     2%    /sdkhome
/dev/vx/dsk/eva8k/tlkuser7
                        44G    36G       7.8G    83%    /tlkuser7
/dev/vx/dsk/eva8k/tlkproj1
                       1.0G    17M       944M     2%    /tlkproj1
/dev/vx/dsk/eva8k/tlkuser3
                        35G    29G       5.9G    84%    /tlkuser3
/dev/vx/dsk/eva8k/tlkuser10
                        29G    29G       2.7M   100%    /tlkuser10
/dev/vx/dsk/eva8k/oravl05
                        30G    29G       1.2G    97%    /oravl05
/dev/vx/dsk/eva8k/oravl06
                        36G    34G       1.6G    96%    /oravl06
/dev/vx/dsk/eva8k/tlkuser6
                        29G    27G       2.1G    93%    /tlkuser6
/dev/vx/dsk/eva8k/tlkuser2
                        36G    30G       5.8G    84%    /tlkuser2
/dev/vx/dsk/eva8k/tlkuser1
                        66G    49G        16G    75%    /tlkuser1
/dev/vx/dsk/eva8k_new/tlkuser13
                        84G    77G       7.0G    92%    /tlkuser13
/dev/vx/dsk/eva8k_new/tlkuser16
                        44G    37G       6.4G    86%    /tlkuser16
/dev/vx/dsk/eva8k/db2
                       1.0G   593M       404M    60%    /opt/db2V8.1
/dev/vx/dsk/eva8k/WebSphere6029
                       3.0G   2.2G       776M    75%    /opt/WebSphere6029
/dev/vx/dsk/eva8k/websphere6
                       2.0G    88M       1.8G     5%    /opt/websphere6
/dev/vx/dsk/eva8k/wli
                       4.0G   1.4G       2.5G    36%    /opt/wli10gR3MP1
/dev/vx/dsk/eva8k/user
                       2.0G    19M       1.9G     1%    /user/telstra/history
dvcinasdm3:/oracle_cdrom/data
                       576G   576G       206M   100%    /oracle_cdrom
dvcinasdm2:/system_kits
                       822G   818G       4.2G   100%    /system_kits
dvcinasdm2:/db_share   295G   283G        13G    96%    /db_share
dvcinas2dm2:/system_data/data
                       315G   283G        32G    90%    /system_data
dvcinas2dm2:/ossinfra/data
                        49G    18G        32G    36%    /ossinfra

ローカルサーバーの場合、コマンド：は：/usr/sbin/prtpicl -v | egrep "devfs-path|driver-name|subsystem-id" | nawk '/:subsystem-id/ { print $0; getline; print $0; getline; print $0; }' | nawk -F: '{ print $2 }'を与えます

subsystem-id     0x13a1
devfs-path       /pci@0,600000/pci@0/pci@8/pci@0/scsi@1
driver-name      mpt
subsystem-id     0x1648
devfs-path       /pci@0,600000/pci@0/pci@8/pci@0/network@2
driver-name      bge
subsystem-id     0x1648
devfs-path       /pci@0,600000/pci@0/pci@8/pci@0/network@2,1
driver-name      bge
subsystem-id     0xfc11
devfs-path       /pci@0,600000/pci@0/pci@8/pci@0,1/SUNW,emlxs@1
driver-name      emlxs
subsystem-id     0x125e
devfs-path       /pci@3,700000/network
driver-name      e1000g
subsystem-id     0x125e
devfs-path       /pci@3,700000/network
driver-name      e1000g
subsystem-id     0x13a1
devfs-path       /pci@10,600000/pci@0/pci@8/pci@0/scsi@1
driver-name      mpt
subsystem-id     0x1648
devfs-path       /pci@10,600000/pci@0/pci@8/pci@0/network
driver-name      bge
subsystem-id     0x1648
devfs-path       /pci@10,600000/pci@0/pci@8/pci@0/network
driver-name      bge
subsystem-id     0xfc11
devfs-path       /pci@10,600000/pci@0/pci@8/pci@0,1/SUNW,emlxs@1
driver-name      emlxs

MITサーバーの場合：

subsystem-id     0xfc00
devfs-path       /pci@3d,600000/SUNW,emlxs@1
driver-name      emlxs
subsystem-id     0xfc00
devfs-path       /pci@3d,600000/SUNW,emlxs@1,1
driver-name      emlxs
subsystem-id     0xfc00
devfs-path       /pci@5d,600000/SUNW,emlxs@1
driver-name      emlxs
subsystem-id     0xfc00
devfs-path       /pci@5d,600000/SUNW,emlxs@1,1
driver-name      emlxs

i / o消費コードの開始時に、iostat -d c3t50001FE1502613A9d75は次のことを示します。

1161  37  134    0   0    0    0   0    0  329  24    2
  3   2    3    0   0    0    0   0    0  554  71   10
195  26    6    0   0    0    0   0    0  853 108   19
 37   6    4    0   0    0    0   0    0  1134 143   10
140   8    7    0   0    0    0   0    0  3689  86    7
173  24   85    0   0    0    0   0    0  9914  74    9
  0   0    0    0   0    0    0   0    0  12323 114    2
 13   9   41    0   0    0    0   0    0  10609 117    2
  0   0    0    0   0    0    0   0    0  10746  72    2
    sd0           sd1           sd4          ssd134
kps tps serv  kps tps serv  kps tps serv  kps tps serv
  1   0    3    0   0    0    0   0    0  11376 137    2
  2   0   10    0   0    0    0   0    0  11980 157    3
231  39   14    0   0    0    0   0    0  10584 140    3
785 175    5    0   0    0    0   0    0  13503 170    2
  9   4   32    0   0    0    0   0    0  11597 168    2
  7   1    6    0   0    0    0   0    0  11555 106    2

MITサーバーでは、iostatは次のことを示しています。

0.0  460.4    0.0 4029.2  0.4  0.6    0.9    1.2   2  11 c6t5006048452A79BD6d206
0.0  885.2    0.0 8349.3  0.5  0.8    0.6    0.9   3  24 c4t5006048452A79BD9d206
0.0  660.0    0.0 5618.8  0.5  0.7    0.7    1.0   2  18 c6t5006048452A79BD6d206
0.0  779.1    0.0 7408.6  0.3  0.7    0.4    0.8   2  21 c4t5006048452A79BD9d206
0.0  569.8    0.0 4893.9  0.3  0.5    0.5    1.0   2  15 c6t5006048452A79BD6d206
0.0  521.5    0.0 5433.6  0.2  0.5    0.3    0.9   1  16 c4t5006048452A79BD9d206
0.0  362.8    0.0 3134.8  0.2  0.4    0.6    1.1   1  10 c6t5006048452A79BD6d206

したがって、最大i / o操作中は、ローカルサーバーのkpsがMITサーバーのkpsよりもはるかに大きいことがわかります。

score 2 · Accepted Answer

ローカルサーバーとMITサーバーに関する結論

お使いのマシンを一目で確認できます。

ローカルサーバーは、SPARCVI上の小さなシャーシのSunEnterpriseマシンであり、おそらくM4000です。直接SCSI接続を使用して、マルチパスPCIeスロットを介して外部ファイルシステム（eva8k_newと呼ばれる）にデータを書き込んでいます。このマシンは3〜5年前のものです。
MITサーバーはSunFire15000であり、古いメインフレームクラスのSolarisサーバーです。実行しているハードウェアパーティションに12個のデュアルコアUltraSPARCIV+ CPUがあります（物理シャーシは、互いにまったく見えないいくつかの異なるハードウェアパーティションに論理的に分割できます）。マルチパスPCIスロット上の1Gb/sまたは2Gb/sファイバーチャネル（LUNはdmldgと呼ばれる場合があります）を介してSANに書き込みます。このマシンは少なくとも7年前のものですが、テクノロジーは10年前のものです。
ローカルサーバーとMITサーバーで使用されるストレージシステムは両方とも外部です。ストレージのパフォーマンスは、物理インターフェイス（PCIとPCIe）および相互接続（SunFireの1または2Gb / sファイバーチャネル）のI/O速度を含む多くの要因に依存します。この記事では、この情報を取得する方法について説明します。

理論上のパフォーマンスの問題

アプリケーションのパフォーマンスは、いくつかのボトルネックの1つに依存している可能性があります（コードの問題やネットワークの遅延/ボトルネックがないと仮定した場合）。

CPU：CPUが高速であれば、アプリケーションを高速化できます。
- シングルスレッド：一部のアプリケーションはシングルスレッドでボトルネックになっているため、スレッド/コアを追加してもパフォーマンスは向上しません。
- マルチスレッド対応：アプリケーションがマルチスレッドの場合、スレッド/コアを追加するとパフォーマンスが向上することがあります
ストレージIO帯域幅またはIOPS：アプリケーションはストレージシステム（ディスクを含む）からの読み取りまたはストレージシステムへの書き込みを行っています。ディスクの追加、RAIDタイプの変更、ディスクキャッシュの追加などにより、IOまたはIOPSが向上する場合があります。または、別のストレージサブシステムに変更することもできます。
- IO帯域幅は、特定の1秒間に渡すことができるデータの最大量であり、ディスクとの間でデータをストリーミングする場合、最初に飽和する可能性があります。
- IOPS（1秒あたりのIO操作）は、1秒あたりに処理できるIOコマンド（読み取りまたは書き込み）の最大数です。通常、これは、ファイルを検索または検索しているプロセス、または小さなチャンクを（再）書き込んでいるプロセスで最初に飽和します。

あなたの問題を見て、私たちは簡単なチェックをすることができます：

問題がCPUの場合、次のようになります。
- プログラムの実行中、上部のJavaプロセスのCPU使用率が非常に高いことがわかります（90〜99％）。
- SunFire MITサーバーには十分な数のコアが使用可能であるため、問題はスレッド化ではない可能性があります。したがって、問題はシングルスレッドのパフォーマンスです。
- UltraSPARC IV +は、SPARCVIよりもかなり低速です。これは簡単に目立つ低下であるため、MITサーバーが遅い理由である可能性があります
問題がIOの場合、次のようになります。
- 上部のJavaプロセスのCPU使用率は低いことがわかります（おそらく50％以下ですが、経験則として80％程度になる可能性があります）
- iostat saturateを使用したディスクサブシステムへのIOが表示されます。これはすぐに固定数に上昇し、実際にはこの数を超えて「ピーク」になることはありません。次のオプションが役立つ場合がありますiostat -d <disk> 5。スループット値と1秒あたりの操作数は、ローカルサーバーでは高くなり、MITサーバーでは低くなります。
- MITサーバーでより高速なストレージシステムが利用できるかどうかを確認するには、管理者に相談する必要があります。

上記はすべて、サーバー上の他のプロセスがプログラムの動作に干渉していないことを前提としています。明らかに、別の高CPUプロセス、または同じディスクに大量に書き込むプロセスは、パフォーマンスに大きく影響します。

結論

提供するCPUデータから、CPUのボトルネックの証拠はありません。

あなたが提供するデータから、iostatあなたがコメントするように、SunFireのIOはローカルサーバーのIOを大幅に下回っています。これは、接続されたストレージ、つまり次の少なくとも1つの結果である可能性があります。

ローカルサーバーでのPCIとPCIeのパフォーマンスの低下
ローカルサーバー上の（おそらくより速い）SCSI接続ストレージよりも遅い1Gb/sファイバーチャネルの可能性
SunFireの古くて遅いディスクとローカルに接続されたストレージ

（同じSANがローカルサーバーに接続されているように見えるため、これをテストできることに注意してください）。

ハードウェアがパフォーマンスの違いの原因であるという明確な証拠があるため、実行できることはほとんどありません。

ただし、アプリケーションの一般的なパフォーマンスが向上する場合があります。アプリケーションでJavaプロファイラーを実行することをお勧めします。例としては、 NetbeansやJProfilerがあります。

プロファイラーは、どのIO操作が問題であるかを識別します。次のことができる場合があります。

一般的に、ボトルネックでアルゴリズムを改善します
キャッシュレイヤーを使用して、一度書き込む前に複数の書き込み操作を集約します
元のJavaI/ Oクラス（java.io内）を使用している場合は、JavaNIOを使用するようにアプリケーションを書き直すことができます。

編集：キャッシングレイヤーについての考え

仮定：問題のあるIO操作は、小さなチャンクをディスクに繰り返し書き込んでフラッシュするか、ランダムアクセスのディスクへの書き込み操作を実行し続けることです。アプリケーションはすでに効率的にディスクにストリーミングされている可能性があります。その場合、キャッシュは役に立ちません。

アプリケーションでコストのかかる操作や遅い操作を行う場合は、呼び出される回数を最小限に抑える必要があります。理想的には、理論上の最小値である1に設定します。ただし、コードがそうしない場合があります。たとえば、 OutputStreamとそれに小さなチャンクを書き込み、ディスクにフラッシュします。この場合、各ディスクブロック（8k）に何度も書き込むことができ、そのたびに少しだけ多くのデータを書き込むことができます。

代わりに、RAMキャッシュを使用してすべての書き込みを統合できます。ブロックへの書き込みがなくなることがわかったら、ディスクに1回だけ書き込みます。ストリーミングの場合、Javaには、単純な場合に備えて、このためのBufferedOutputStreamがあります。FileOutputStreamからインスタンスを取得するときはFile、をラップしてFileOutputStream、BufferedOutputStreamのみを使用しBufferedOutputStreamます。

ただし、真のランダムアクセス書き込みを実行していて（たとえば、を使用してjava.io.RandomAccessFile）、ファイルポインタをで移動しているRandomAccessFile.seek()場合は、RAMに書き込みキャッシュを書き込むことを検討することをお勧めします。これがどのように見えるかは、ファイルのデータ構造に完全に依存しますが、ブロックページングメカニズムから始めることをお勧めします。Java NIOの第1章には、これらの概念の概要が記載されていますが、そこに行く必要がないか、NIOAPIに近いものが見つかることを願っています。

score 1 · Accepted Answer

パフォーマンスが気になる場合は、このような古いバージョンのJavaは使用しません。1つのアーキテクチャ用に生成されたOS呼び出しとネイティブコードが最適ではない可能性が非常に高くなります。新しいアーキテクチャが苦しむことを期待します。

これらのマシン間でJava7を比較できますか？

最初のulimitマシンにははるかに多くのリソースがあることを提案します。2台のマシンにはどのモデルのCPUとどのくらいのメモリがありますか？

java - 2つの異なるプラットフォームでのJavaコードの実行時の違い

2 に答える 2

Related

Reference