14年前(2007 年)的笔记本的 HDD 和插在 USB 口的 HDD 移动硬盘的读写速度测试结果

HDD:
$ dd if=/root/tmp.data of=/dev/null bs=1024k
4096+0 records in
4096+0 records out
4294967296 bytes transferred in 190.078495 secs (22595756 bytes/sec)
$ dd if=/dev/random of=/root/tmp.data bs=1024k count=4096
4096+0 records in
4096+0 records out
4294967296 bytes transferred in 200.241032 secs (21448987 bytes/sec)

Read speed: 21.54 Megabyte per second
Write speed: 20.45 Megabyte per second

HDD @ USB:
$ dd if=/dev/random of=/tank/tmp.data bs=1024k count=1024
1024+0 records in
1024+0 records out
1073741824 bytes transferred in 100.581317 secs (10675361 bytes/sec)
$ dd if=/tank/tmp.data of=/dev/null
2097152+0 records in
2097152+0 records out
1073741824 bytes transferred in 43.525504 secs (24669257 bytes/sec)

Read speed: 23.52 Megabyte per second
Write speed: 10.18 Megabyte per second

#dd, #hdd, #usb

RAM disk speed test result

Memory Slots:

  ECC:	Disabled
  Upgradeable Memory:	No

BANK 0/ChannelA-DIMM0:

  Size:	32 GB
  Type:	DDR4
  Speed:	2667 MHz
  Status:	OK
  Manufacturer:	Micron
  Part Number:	-
  Serial Number:	-

BANK 2/ChannelB-DIMM0:

  Size:	32 GB
  Type:	DDR4
  Speed:	2667 MHz
  Status:	OK
  Manufacturer:	Micron
  Part Number:	-
  Serial Number:	-

$ diskutil erasevolume HFS+ 'RAM_Disk' `hdiutil attach -nobrowse -nomount ram://67108864`
Started erase on disk4
Unmounting disk
Erasing
Initialized /dev/rdisk4 as a 32 GB case-insensitive HFS Plus volume
Mounting disk
Finished erase on disk4 (RAM_Disk)

$ dd if=/dev/random of=/Volumes/RAM_Disk/tmp.data bs=1024k count=16384
16384+0 records in
16384+0 records out
17179869184 bytes transferred in 54.670080 secs (314246279 bytes/sec)

$ dd if=/Volumes/RAM_Disk/tmp.data of=/dev/null bs=1024k
16384+0 records in
16384+0 records out
17179869184 bytes transferred in 5.130549 secs (3348544052 bytes/sec)

$ hdiutil detach /dev/disk4
"disk4" ejected.

Read speed: 3.1185 Gigabyte per second
Write speed: 299.6886 Megabyte per second

#dd

#ddr4, #ram-disk

SSD with USB 3.1 read/write speed test result

USB 3.1 Bus:

  Host Controller Driver:	AppleUSBXHCITR
  PCI Device ID:	0x15ec 
  PCI Revision ID:	0x0006 
  PCI Vendor ID:	0x8086 
  Bus Number:	0x00 

VLI Product String:

  Product ID:	0x0715
  Vendor ID:	0x2109  (VIA Labs, Inc.)
  Version:	1.31
  Serial Number:	000000123ADA
  Speed:	Up to 10 Gb/s
  Manufacturer:	VLI Manufacture String
  Location ID:	0x00200000 / 1
  Current Available (mA):	900
  Current Required (mA):	896
  Extra Operating Current (mA):	0
  Media:
SL500 2TB:
  Capacity:	2 TB (2,000,398,934,016 bytes)
  Removable Media:	No
  BSD Name:	disk2
  Logical Unit:	0
  Partition Map Type:	GPT (GUID Partition Table)
  S.M.A.R.T. status:	Verified
  USB Interface:	0
  Volumes:
EFI:
  Capacity:	209.7 MB (209,715,200 bytes)
  File System:	MS-DOS FAT32
  BSD Name:	disk2s1
  Content:	EFI
  Volume UUID:	0E239BC6-F960-3107-89CF-1C97F78BB46B
disk2s2:
  Capacity:	2 TB (2,000,189,177,856 bytes)
  BSD Name:	disk2s2
  Content:	Apple_APFS

Colorful SL500 2TB Media:

  Free:	1.43 TB (1,431,453,413,376 bytes)
  Capacity:	2 TB (2,000,189,177,856 bytes)
  Mount Point:	/Volumes/Colorful SL500 2TB Media
  File System:	Case-sensitive APFS
  Writable:	Yes
  Ignore Ownership:	Yes
  BSD Name:	disk3s1
  Volume UUID:	E7369016-1660-4A22-B537-2412DD8CE2F0
  Physical Drive:
  Device Name:	SL500 2TB
  Media Name:	AppleAPFSMedia
  Protocol:	USB
  Internal:	No
  Partition Map Type:	Unknown

with ORICO TYPE-C USB 3.1 Transparent 2.5 inch Hard Drive Enclosure  [2139C3-R1.1]
$ dd if=/dev/random of=./tmp.data bs=1024k count=32768
32768+0 records in
32768+0 records out
34359738368 bytes transferred in 729.521762 secs (47098990 bytes/sec)
$ dd if=./tmp.data of=/dev/null bs=1024k
32768+0 records in
32768+0 records out
34359738368 bytes transferred in 152.150119 secs (225827877 bytes/sec)

Read speed: 215.3662462234497070 Megabyte per second
Write speed: 44.9170970916748046 Megabyte per second

#dd, #ssd, #usb

什么时候能用 log 对象的静态引用

这是一篇2011年1月9日开始至今没有完成的翻译,十多年了,今天我在整理草稿时发现它还躺在这里,然后我尝试点击查看英文原文试图完成它时,原来的英文原文地址已经不存在了,然后就去搜索标题试图找到英文原文,发现已经有朋友翻译过它了:什么时候使用静态的Log对象。那这篇就不继续了。


英文原文:When Static References to Log objects can be used When Static References to Log objects can be used

有两个非常常见的使用日志的模式:

public class Foo {
 private Log log = LogFactory.getLog(Foo.class);
 ....
}

public class Foo {
 private static Log log = LogFactory.getLog(Foo.class);
 ....
}

静态限定符的使用在某些情况下是有益的。然而,在其它一些情况下,它却确确实实是一个糟糕的主意,并且可能会有意想不到的后果。本页面描述了各个方案在什么情况下是合适的。

静态的问题

技术上,使用静态的结果是很明显的:在这个类的所有实例间共享这个仅有的 Log 引用。这很明显节省了内存;不管创建多少个实例都只需要一个引用(4 或者 8 个字节)。并且 CPU 角度也非常有效率;查找 Log 实例只需要在这个类第一次被引用的时候做一次。

当编写一个独立的应用程序代码时,使用静态是个好主意。

然而,当相关 java 代码是一个可能部署在某种容器(比如 J2EE 服务器)里的类库时,那么问题就来了。容器创建一个 java ClassLoader 对象的分级结构,比如每个“应用”所部署的容器有自己的 ClassLoader 但又有一些共享的 ClassLoader 作为所有部署着的“应用”的祖先,是很常见的事。这种情况下,当一个持有了 Log 实例的静态引用的类被部署在“应用程序”级(比如在一个 servlet 或 j2ee 容器的“webapp”级),这还没有问题;如果多个应用部署了这个有问题的类,那么他们每个都有这个类的一份副本,并且和其它应用没有交互。

然而考虑到这样一种情况,当一个使用了“private static Log log = …”的类被一个 ClassLoader 部署为多个看上去像独立的“应用”的祖先。这种情况下,log 成员仅被初始化一次,因为只有一个这个类的副本。这个初始化(典型地)发生在任何代码第一次试图实例化或调用一个静态方法时。当这个类的初始化发生时,这个 log 成员应该设置成什么?有以下选择:

引用属于“容器”层配置的 Log 对象,而不和任何“应用”关联。

引用在层次结构上和当前应用相关的应用里配置的 Log 对象

引用一个“代理”对象,每次调用 log 方法时都去找出当前应用,并委派给其下的 Log 对象

第一个选择是说日志不能配置在每个应用层。无论日志配置如何设置都会将每个应用的日志设成和容器里配置的一样,所有的从这些应用里的输出都会合并到一块。这是一个大问题。

第二个选择是说 Log 对象将配置成和第一个被调用的应用里配置的。容器里的其它应用将把它们的输出发送到第一个应用配置的目标里。显而易见,这是一个大问题。

第三个选择允许每个应用都有各自的日志配置,并正确地过滤和输出需要的日志信息。可是付出的性能损失非常大,这不是一个可以接受的解决方案。

注意,我们还没有讨论到“Thread Context ClassLoaders”或者其它的技术要点。这个问题不详述了,只给出一个概念性的结论:当 Log 对象是在多个应用间共享时,是不可能做到各个应用各配各的的,并且有性能问题。

这个问题真正的根源是数据(通过类的静态成员)在所谓独立的“应用”间共享。如果没有类是在应用间“共享”的,那么问题就不存在了。然而,它似乎(我个人的经验)容器提供商继续鼓励使用共享类,并且应用程序开发人员继续在使用它。

另一个解决方法是:在任何可能部署到共享 classpath 的代码里避免使用 Log 对象的“静态”引用。

SLF4J 有这个问题吗?

有。SLF4J 也正受着上述问题的困扰,并且有着相同的建议:在可能部署到共享 classpath 的代码中避免使用 log 对象的静态引用。

这里有几个可能的场景。首先我们需要定义一个术语“TCCL 感知”。日志类库是“TCCL 感知”的,当它初始化代码时使用 Thread Context ClassLoader 来定位配置文件,而不是类库自身里的类的 ClassLoader。举个例子,在它的标准形式里,log4j 是不能“TCCL 感知”的。不过它可以通过下面描述的一个“Contextural RepositorySelector”来做到“TCCL 感知”:

http://www.qos.ch/logging/sc.jsp

现在来看看一些可能的场景:

假设 SLF4J 是部署在一个共享的层,有一个使用了静态 Logger 引用的类在共享的 classpath 里,也有一个使用了静态 logger 的类在应用程序 classpath 里。当日志类库不是 TCCL 感知的,那么就仅读取在“共享” classpath 里的日志配置,所有部署着的应用程序都输出调试信息到全局配置里了。输出是正确的,但是就不能仅为一个应用开启调试日志了,并且从所有的应用程序里来的所有输出都是混在一起的。当日志类库是 TCCL 感知的,那么就可以针对各个应用程序配置自己的日志了。另外,来自这些类的输出都输出在应用程序层,这是正确的。然而,那些部署在共享层的类将有它们自己的 Log 对象的初始化,使用第一个调用该类的应用程序的配置;当其它应用程序调用相同的类时其日志输出将跑到第一个应用程序里去了。不好。

如果 SLF4J 同时部署在共享和应用程序层,并且首先先加载了一个父层的,那么行为和上面的一样。但是如果先加载的是应用层的,如果日志类库是 TCCL 感知的那么结果还可以承受。然而如果是先加载的应用层的,并且日志类库不是 TCCL 感知的,那么结果就是这样:从共享类里的输出仅能配置在全局,所有应用层的输出都跑到一起去了。

不幸的是,在大多数情况下,类库代码的作者不能指定类库用户说代码必须部署在哪一层,必须使用怎样的加载顺序,或者应该用什么行为的日志类库。因此有必要和 commons-loggings 一样避免使用 SLF4J logger 的静态引用。

无论如何,不当使用 SLF4J 所导致的问题确实要比 commons-logging 少。原因如下:

当前 TCCL 感知的日志类库并不多,并且目前部署在共享 classpath 里的类库相对较少地使用了 SLF4J。

commons-logging 本身是 TCCL 感知的,允许应用层的日志类库配置是非 TCCL 感知的;实际上,使用 commons-logging 时每个日志类库都可以 TCCL 感知。commons-logging 也经常被很多部署在共享 classloader 的类库所使用。

请注意,这段不是想要批评 SLF4J。如前所述,这个问题是因为应用程序间使用共享静态日志引用的隔离问题造成的冲突,并且何况在这些场景下 SLF4J 和 commons-logging 一样面临着这个尴尬。

翻译未完成。要阅读完整版本,请看这篇翻译:什么时候使用静态的Log对象

#java, #logging

HDD read/write speed test result

Disk:
  HGST
  1TB 7200RPM
  5V 800mA
  HDD: 7K1000-1000
  Type TS7SAF100
  SATA 6.0Gb/s

with ORICO TYPE-C USB 3.1 Transparent 2.5 inch Hard Drive Enclosure  [2139C3-R1.1]

$ dd if=/dev/random of=./tmp.data bs=1024k count=65536
65536+0 records in
65536+0 records out
68719476736 bytes transferred in 948.964624 secs (72415214 bytes/sec)

$ dd if=./tmp.data of=/dev/null bs=1024k
65536+0 records in
65536+0 records out
68719476736 bytes transferred in 712.999277 secs (96380851 bytes/sec)

Read speed: 96.380851 Megabyte per second
Write speed: 72.415214 Megabyte per second

#HDD #dd

SSD read/write speed test result

File System:	Case-sensitive APFS
Physical Drive:
  Device Name:	APPLE SSD AP8192N
  Media Name:	AppleAPFSMedia
  Medium Type:	SSD
  Protocol:	PCI-Express
  Internal:	Yes
  Partition Map Type:	Unknown
  S.M.A.R.T. Status:	Verified

$ dd if=/dev/random of=/tmp/tmp.data bs=1024k count=262144
262144+0 records in
262144+0 records out
274877906944 bytes transferred in 764.036416 secs (359770688 bytes/sec)

$ dd if=/tmp/tmp.data of=/dev/null bs=1024k
262144+0 records in
262144+0 records out
274877906944 bytes transferred in 99.768125 secs (2755167619 bytes/sec)

Read speed: 2.755167619 Gigabyte per second
Write speed: 359.770688 Megabyte per second

#SSD #dd

MacBook Pro 16,1 Ubench

Hardware Overview:

Model Name: MacBook Pro
Model Identifier: MacBookPro16,1
Processor Name: 8-Core Intel Core i9
Processor Speed: 2.4 GHz
Number of Processors: 1
Total Number of Cores: 8
L2 Cache (per Core): 256 KB
L3 Cache: 16 MB
Hyper-Threading Technology: Enabled
Memory: 64 GB
Boot ROM Version: 1037.147.4.0.0 (iBridge: 17.16.16610.0.0,0)
Activation Lock Status: Disabled

Unix Benchmark Utility v.0.3
Copyright (C) July, 1999 PhysTech, Inc.
Author: Sergei Viznyuk
http://www.phystech.com/download/ubench.html
Darwin 19.6.0 Darwin Kernel Version 19.6.0: Thu Jun 18 20:49:00 PDT 2020; root:xnu-6153.141.1~1/RELEASE_X86_64 x86_64
Ubench CPU: 5887318
Ubench MEM: 1754351
——————–
Ubench AVG: 3820834

#intel-core-i9, #macbook-pro, #ubench

DigitalOcean Compute-optimized SFO2 2 vCPUs 4GB Memory 25GB Disk ubench

Unix Benchmark Utility v.0.3
Copyright (C) July, 1999 PhysTech, Inc.
Author: Sergei Viznyuk
http://www.phystech.com/download/ubench.html
FreeBSD 12.1-RELEASE-p2 FreeBSD 12.1-RELEASE-p2 GENERIC amd64
Ubench CPU: 864680
Ubench MEM: 741036
——————–
Ubench AVG: 802858

#digitalocean, #ubench

DigitalOcean Standard SFO1 1 vCPUs 3GB Memory 50GB Disk ubench

Unix Benchmark Utility v.0.3
Copyright (C) July, 1999 PhysTech, Inc.
Author: Sergei Viznyuk
http://www.phystech.com/download/ubench.html
FreeBSD 12.1-RELEASE-p2 FreeBSD 12.1-RELEASE-p2 GENERIC amd64
Ubench CPU: 317769
Ubench MEM: 361761
——————–
Ubench AVG: 339765

#digitalocean, #ubench

DigitalOcean Standard SFO1 1 vCPUs 2GB Memory 50GB Disk ubench

Unix Benchmark Utility v.0.3
Copyright (C) July, 1999 PhysTech, Inc.
Author: Sergei Viznyuk
http://www.phystech.com/download/ubench.html
FreeBSD 12.1-RELEASE-p2 FreeBSD 12.1-RELEASE-p2 GENERIC amd64
Ubench CPU: 280240
Ubench MEM: 248686
——————–
Ubench AVG: 264463

#digitalocean, #ubench