Category Archives: 计算机与 Internet

计算机与 Internet

PowerEdge R730xd, USB SanDisk 3.2Gen1 1.00, Bonnie++ Benchmark results

Version 2.00 Sequential Output Sequential Input Random
Seeks		 Sequential Create Random Create
Size Per Char Block Rewrite Per Char Block Num Files Create Read Delete Create Read Delete
M/sec % CPU M/sec % CPU M/sec % CPU M/sec % CPU M/sec % CPU /sec % CPU /sec % CPU /sec % CPU /sec % CPU /sec % CPU /sec % CPU /sec % CPU
r730xd 300M 439 98 6 0 7 1 1258 98 0 +++ 3578 58 16 20046 42 +++++ +++ 29700 41 15540 30 +++++ +++ 22936 36
Latency 54365us 45us 423us 8267us 46us 65us Latency 639us 670us 2145us 375us 23us 4314us
标准
计算机与 Internet

Raspberry PI 4B 8GB, USB SanDisk 3.2Gen1 1.00, Bonnie++ Benchmark results

Version 1.98 Sequential Output Sequential Input Random
Seeks		 Sequential Create Random Create
Size Per Char Block Rewrite Per Char Block Num Files Create Read Delete Create Read Delete
M/sec % CPU M/sec % CPU M/sec % CPU M/sec % CPU M/sec % CPU /sec % CPU /sec % CPU /sec % CPU /sec % CPU /sec % CPU /sec % CPU /sec % CPU
rpi-4b-01.oxerr.net 300M 70 99 12 5 11 5 141 99 466 99 6528 1067 16 10622 68 +++++ +++ 584 5 13205 81 +++++ +++ 213 2
Latency 201ms 20456ms 9257ms 59358us 301us 1877us Latency 23336us 114us 976ms 5286us 82us 4367ms
标准
计算机与 Internet

Raspberry PI 4B 8GB, Kingston CANVAS React Plus microSD UHS-II U3 V90 A1 64GB, Bonnie++ Benchmark results

Total Size: 64GB
Avail Size: 50GB

Version 1.98 Sequential Output Sequential Input Random
Seeks		 Sequential Create Random Create
Size Per Char Block Rewrite Per Char Block Num Files Create Read Delete Create Read Delete
M/sec % CPU M/sec % CPU M/sec % CPU M/sec % CPU M/sec % CPU /sec % CPU /sec % CPU /sec % CPU /sec % CPU /sec % CPU /sec % CPU /sec % CPU
rpi-4b-01.oxerr.net 16G 227 99 20 4 11 2 645 99 23 2 610.6 11 16 13347 37 +++++ +++ 18211 35 12686 36 +++++ +++ +++++ +++
Latency 76038us 1662ms 1954ms 18491us 108ms 3190ms Latency 497ms 33us 148us 603ms 37us 63us
标准
计算机与 Internet

PowerEdge R720xd, SanDisk’ Cruzer Fit 1.00 @ USB 2.0, Bonnie++ Benchmark results

SanDisk’ Cruzer Fit 1.00 @ USB 2.0 on PowerEdge R720xd
Total Size: 64GB
Avail Size: 52GB

$ bonnie++ -r 16g -u root

Version 1.98 Sequential Output Sequential Input Random
Seeks		 Sequential Create Random Create
Size Per Char Block Rewrite Per Char Block Num Files Create Read Delete Create Read Delete
M/sec % CPU M/sec % CPU M/sec % CPU M/sec % CPU M/sec % CPU /sec % CPU /sec % CPU /sec % CPU /sec % CPU /sec % CPU /sec % CPU /sec % CPU
r720xd 300M 37 24 4 1 8 2 362 99 0 +++ 2686 35 16 9095 82 +++++ +++ 2065 21 13115 91 +++++ +++ 1884 17
Latency 91238us 313us 178us 30257us 87us 144us Latency 3030us 87us 3177ms 4959us 56us 2710ms
标准
计算机与 Internet

MacBook10,1 Bonnie++ Benchmark results

Free: 51.09 GB (51,086,016,512 bytes)
Capacity: 499.96 GB (499,963,174,912 bytes)
File System: Case-sensitive APFS
Physical Drive:
Device Name: APPLE SSD AP0512J
Media Name: AppleAPFSMedia
Medium Type: SSD
Protocol: PCI-Express
Internal: Yes

Version 1.97 Sequential Output Sequential Input Random
Seeks		 Sequential Create Random Create
Size Per Char Block Rewrite Per Char Block Num Files Create Read Delete Create Read Delete
K/sec % CPU K/sec % CPU K/sec % CPU K/sec % CPU K/sec % CPU /sec % CPU /sec % CPU /sec % CPU /sec % CPU /sec % CPU /sec % CPU /sec % CPU
Sutras-MacBook.local 32G 247 97 109953 56 241384 63 980 99 599318 60 8102 404 16 11035 77 256223 99 18319 90 13954 92 376947 99 19261 92
Latency 74169us 370ms 66589us 10032us 54077us 102ms Latency 29031us 331us 3128us 1971us 56us 2712us
标准
计算机与 Internet

MacBookAir3,2 Bonnie++ Benchmark results

Available: 110.78 GB (110,775,746,560 bytes)
Capacity: 250.79 GB (250,790,436,864 bytes)
File System: Case-sensitive APFS
Device Name: APPLE SSD TS256C
Medium Type: SSD
Protocol: SATA
Internal: Yes

Version 1.97 Sequential Output Sequential Input Random
Seeks		 Sequential Create Random Create
Size Per Char Block Rewrite Per Char Block Num Files Create Read Delete Create Read Delete
K/sec % CPU K/sec % CPU K/sec % CPU K/sec % CPU K/sec % CPU /sec % CPU /sec % CPU /sec % CPU /sec % CPU /sec % CPU /sec % CPU /sec % CPU
Sutras-MacBook-Air.local 8G 61 93 104139 29 60629 23 346 82 186436 19 3373 107 16 3197 36 70504 76 5590 72 6558 63 73555 61 5157 66
Latency 395ms 683ms 596ms 38893us 17542us 61724us Latency 536ms 1866us 112ms 155ms 8375us 68189us
标准
计算机与 Internet

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

标准
计算机与 Internet

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

标准
计算机与 Internet

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

标准
计算机与 Internet

什么时候能用 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对象。

标准