两种不同平台的Java代码运行时间差异-6ren

两种不同平台的Java代码运行时间差异

转载作者：行者123 更新时间：2023-12-04 05:20:49

我已经在两个不同的服务器上部署了 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 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 服务器上的运行速度明显变慢。
由于两个操作系统的 nofiles 和堆栈不同，我想如果我更改 ulimit -s和 ulimit -n它会有所作为。
在没有确认问题的情况下，我无法更改 MIT 服务器上的参数，因此降低了本地服务器的 ulimit 参数并重新测试。但代码完成执行的时间是相同的。

我不知道可能导致这种情况的操作系统参数之间有什么区别。
任何帮助表示赞赏。如果有人告诉我要寻找什么，我会发布更多参数。

编辑:

对于 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

df -h 用于 MIT 服务器:

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 c3t50001FE1502613A9d7 5 显示:

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。

最佳答案

关于本地和 MIT 服务器的结论

快速浏览一下您的机器:

本地服务器是 SPARC VI 上的小型机箱 Sun Enterprise 机器，可能是 M4000 .您正在通过多路径在外部文件系统(称为 eva8k_new)上写入数据 PCIe slots使用直接 SCSI 连接。这台机器3-5年了。

MIT 服务器是 SunFire 15000 - 旧的大型机级 Solaris 服务器。它在您运行的硬件分区中有 12 个双核 UltraSPARC IV+ CPU(物理机箱可以在逻辑上分成几个完全不可见的不同硬件分区)。您正在通过 1Gb/s 或 2Gb/s 光纤 channel (LUN 可能称为 dmldg)在多路径 PCI slots 上写入 SAN。 . native 是至少 7岁，但技术10岁。

本地和 MIT 服务器上使用的存储系统都是外部的。存储的性能取决于许多因素，包括物理接口(interface)的 I/O 速度(PCI 与 PCIe)和互连(SunFire 上的 1 或 2Gb/s 光纤 channel )。 This article解释了如何获取这些信息。

理论性能问题

您的应用程序的性能可能会受到几个瓶颈之一的限制(假设没有代码问题和网络延迟/瓶颈):

CPU:如果您的 CPU 速度更快，您可以让应用程序运行得更快。

单线程:某些应用程序在单线程上遇到瓶颈，因此添加线程/内核不会提高性能。

多线程能力:有时，如果应用程序是多线程的，添加更多线程/内核可以提高性能

存储 IO 带宽或 IOPS:应用程序正在读取或写入存储系统(包括磁盘)。添加磁盘、更改RAID类型、添加磁盘缓存等可能会提高IO或IOPS；或者，您可以更改为另一个存储子系统。

IO 带宽是在给定的秒内可以传递的最大数据量，如果将数据流传输到磁盘或从磁盘传输数据，它可能首先饱和

IOPS(每秒 IO 操作数)是每秒可以处理的最大 IO 命令(读或写)数。通常，对于正在搜索或在文件中搜索或(重新)写入小块的进程，这首先饱和。

针对您的问题，我们可以快速检查一下:

如果是 CPU 问题，则:

您应该在 中看到 java 进程的 CPU 使用率。顶部 非常高程序执行期间 (90-99%)

问题不太可能是线程，因为 SunFire MIT Server 有很多可用的内核，因此问题是 单线程性能 .

UltraSPARC IV+ 比 SPARC VI 慢很多。这很容易引起明显的下降，所以这可能是 MIT 服务器速度较慢的原因

如果问题是IO，那么:

您将在 中看到 java 进程的 CPU 利用率。顶部 成为低 (可能为 50% 或更低，但根据经验可能高达 80% 左右)

您将使用 iostat saturate 看到磁盘子系统的 IO - 即立即上升到一个固定数字，而不是真正超过这个数字的“峰值”。以下选项可能有用:iostat -d <disk> 5 .吞吐量值和每秒操作数在本地服务器上会更高，而在 MIT 服务器上会更低

您需要与管理员联系以查看是否有更快的存储系统可用于 MIT 服务器。

以上所有内容都假设服务器上的其他进程不干扰您的程序的运行 - 显然另一个高 CPU 进程或向同一磁盘写入大量内容会极大地影响性能。

结论

从您提供的 CPU 数据来看，没有证据表明存在 CPU 瓶颈。

来自 iostat根据您提供的数据，正如您评论的那样，SunFire 上的 IO 明显低于本地服务器的 IO。这可能是附加存储的结果，即至少以下之一:

本地服务器中 PCI 的性能低于 PCIe

可能 1Gb/s 光纤 channel 比本地服务器上的(可能更快)SCSI 附加存储慢

SunFire 上较旧和较慢的磁盘与本地附加存储

(请注意，同一个 SAN 似乎连接到本地服务器，因此可以进行测试)。

有明确的证据表明硬件是导致性能差异的原因，几乎无能为力。

不过，有些事情可能会提高应用程序的总体性能。在应用程序上运行 Java 分析器是个好主意。示例包括 Netbeans和 JProfiler .

探查器将确定哪些 IO 操作有问题。您或许能够:

一般在瓶颈处改进算法

在写一次之前使用缓存层聚合多个写操作

如果使用原始 Java I/O 类(在 java.io 中)，您可以重写应用程序以使用 Java NIO

编辑 : 关于缓存层的想法

假设:有问题的 IO 操作要么反复将小块写入磁盘并刷新它们，要么继续执行随机访问写入磁盘操作。您的应用程序可能已经有效地流式传输到磁盘，在这种情况下缓存将没有用。

当您在应用程序中有一个昂贵或缓慢的操作时，您将希望最小化它被调用的次数 - 理想情况下是理论上的最小值，希望是 1。但是您的代码可能不会这样做 - 例如您正在使用OutputStream 并将小块写入其中并刷新到磁盘。在这种情况下，您可能会多次写入每个磁盘块 (8k)，每次只写入更多数据。

相反，您可以使用 RAM 缓存来整合所有写入；当您知道不会再向该块写入数据时，您只需将它写入磁盘一次。对于流，Java 有 BufferedOutputStream对于这种简单的情况。当您获得 FileOutputStream来自 File 的实例, 包裹 FileOutputStream在 BufferedOutputStream并且仅使用 BufferedOutputStream .

但是，如果您正在执行真正的随机访问写入(例如使用 java.io.RandomAccessFile )，并使用 RandomAccessFile.seek() 移动文件指针，您可能需要考虑在 RAM 中写入写入缓存。确切地说，这完全取决于您的文件数据结构，但您可能希望从块分页机制开始。 Java NIO第1章有对这些概念的介绍，但希望您要么不需要去那里，要么在 NIO API 中找到接近的匹配项。

关于两种不同平台的Java代码运行时间差异，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/13717749/

文章推荐：使用 idref 的 XPath 表达式

文章推荐： ruby-on-rails - Rails 3.1 Multi-Tenancy 路由

文章推荐： matlab - 删除矩阵中第一个二维中的重复项，matlab

flutter - 为什么dart不会抛出编译时错误类型异常。运行时间？
考虑以下示例代码: void main() { List array = []; for (int i = 0; i newList = array.where( (value) => v
java - TextRank 运行时间
我在java中实现了textrank，但它看起来很慢。有谁知道它的预期性能吗？如果预计速度不会很慢，则可能是以下任一问题: 1) 似乎没有办法在 JGraphT 时间内创建一条边并同时为其添加权重，
java - 输出流的flush()运行时间
我正在尝试提交解决方案(使用一些具有编译时间限制的在线编译器)来对数组进行排序 - 这是我的代码片段 - class TSORT { public static void main(Strin
c++ - 数据结构——运行时间
只是一个困惑......部分C++示例代码如下我只是重新编辑了整个帖子。抱歉造成任何混淆 int i, j; i = 0; // c1 j = 0; // c2 while (i
c++ - OpenMP 运行时间
我正在使用 OpenMP 运行一些并行工作，但发现加速无法很好地扩展。然后我发现随着线程数量的增加，完成相同工作量的时间也会增加。这是示例: void fillingVec(vector& vec)
algorithm - 最大子数组 - 运行时间
我目前正在分析 maximum subarray problem 用于强力算法和分而治之算法(递归)。使用蛮力算法，最坏情况下的运行时间为 O(n^2)。使用递归算法，最坏情况下的运行时间为 O(n
javascript concat 运行时间
如果我有两个数组都有 10000 个项目，现在我想将它们合并到一个数组中，所以我用 concat 来完成: array1=array1.concat(array2); 但是有人知道运行时间是多少吗？
C++ 运行时间，以毫秒为单位
{ clock_t t1, t2; double time1 = 0; t1 = clock(); bubbleSort(data, n); t2 = cloc
runtime - 运行时间 vs 设计时间
我在某处读到有人可以在运行时访问配置值，但不能在设计时访问。在这种情况下，运行时和设计时有什么区别？最佳答案设计时间是有人用愉快的“看起来不错!”在我们的 Word 文档和 UML 图表上签字的时
java - 优化 GC 运行时间
我正在比较我们一个项目的两个分支的性能，一个比另一个慢得多。我注意到其中一个的 GC 运行计数更高(见下图)。更有趣的是，运行时间要长很多倍，远远超过额外运行所能解释的时间。什么可以解释运行次数增加
java - log4j有r(运行时间)的时间格式吗
我想以可读的方式格式化 log4j 经过的运行时间，%r 参数: [00:36:25.844] 和 [01 13:35:25.844] [时:分:ss.SSS] ... [dd 时:分:ss.SSS]
performance - 嵌套循环的大 O 运行时间？
如何计算此代码的大 O 运行时效率？我的直觉告诉我它是 O(n^3)，但我不确定，因为我不确定循环是独立的还是相关的。 for (i=1; i<=n; i++) for (j=1; j<=n;
algorithm - 确定这些不同循环的大 O 运行时间？
确定这些不同循环的大 O 运行时间？ for i = 1 to n { ... for j = 1 to 2*i { ... k = j; while (k>=0)
algorithm - 运行时间，复杂性，编译时间和执行时间有什么区别？
运行时间、复杂性、编译时间和执行时间有什么区别？运行时间与时间复杂度有冲突，执行时间和执行时间有什么区别？最佳答案您真正需要的是如何将大O时间复杂度转换为运行时。这不像一开始看起来那么容易。因
algorithm - Mergesort 运行时间 BigO
斯内普的《Unfriendly Algorithms for Wizards》教科书声称合并的运行时间排序是 O(n^4)。这种说法是否正确？解决方案:是的。这个说法在技术上是正确的，因为 O(n^
algorithm - 确定这些不同循环的大 O 运行时间？
我有一系列问题需要反馈和答案。我会评论我的想法，这不是家庭作业而是准备为了我的考试。我的主要问题是确定不同情况下循环的迭代。试图弄清楚这一点会如何？评估运行时间。 Q2。 for(int i =
java - 测量eclipse中的速度，运行时间，执行时间
我试图找到一个合理的机会来测量我的 java 程序/程序部分的速度，例如测试两种方法中哪一种执行得更快。注释掉这两种方法中的一种，确定运行时间，最后比较时间。我不想在我的程序中使用任何代码，例如: p
java - 某些方法上的 BigO 运行时间
好吧，这些都是非常简单的方法，而且有几个，所以当它们都是同一件事时，我不想只创建多个问题。 BigO 是我的弱点。我只是想不通他们是如何得出这些答案的。无论如何，您是否可以让我深入了解您对分析其中一些
c++ - 递归的 Theta 运行时间
如何计算此给定代码的 Theta 运行时间: void f(int n) { for (int i=3; i
clojure - Leiningen uberjar "empty"运行时间
使用 leiningen 创建 uberjar 并使用 java -jar foo-uberjar.jar 运行该 jar 后程序运行良好，最后一行代码执行得相当快，但程序在关闭前挂了大约一分钟。这是

行者123

个人简介

我是一名优秀的程序员,十分优秀！

作者热门文章

滴滴打车优惠券免费领取

全站热门文章

首页

博学

6Ren·AI

商城

两种不同平台的Java代码运行时间差异