我们每晚使用 pg_dump 来制作我们数据库的快照。我们用一个简单的命令做了很长时间
pg_dump -Fc database_name
这大约需要一个小时并生成一个 30+GByte 的文件。
我们怎样才能加快速度？
nginx 从来没有出现过任何问题。我们在很多 Spring Boot 应用服务器前面使用 5 台 Nginx 服务器作为负载均衡器。
我们多年来一直在 debian 9 上使用默认的 nginx 包 1.10.3 运行它们。现在我们将三个负载均衡器切换到带有 nginx 1.14.2 的 debian 10。首先，一切顺利。然后，在高负载下，我们遇到了一些问题。它开始于
2020/02/01 17:10:55 [crit] 5901#5901: *3325390 SSL_write() failed while sending to client, client: ...
2020/02/01 17:10:55 [crit] 5901#5901: *3306981 SSL_write() failed while sending to client, client: ...
在这之间我们得到很多
2020/02/01 17:11:04 [error] 5902#5902: *3318748 upstream timed out (110: Connection timed out) while connecting to upstream, ...
2020/02/01 17:11:04 [crit] 5902#5902: *3305656 SSL_write() failed while sending response to client, client: ...
2020/02/01 17:11:30 [error] 5911#5911: unexpected response for ocsp.int-x3.letsencrypt.org
它以
2020/02/01 17:11:33 [error] 5952#5952: unexpected response for ocsp.int-x3.letsencrypt.org
该问题仅在高负载下退出 30-120 秒，然后消失。
在内核日志中，我们有时会出现：Feb 1 17:11:04 kt104 kernel: [1033003.285044] TCP: request_sock_TCP: 端口 443 上可能的 SYN 泛洪。发送 cookie。检查 SNMP 计数器。
但在其他情况下，我们看不到任何 kernel.log 消息
在 debian 9 和 debian 10 服务器上，我们使用相同的设置并进行了一些 TCP 调整：
# Kernel tuning settings
# https://www.nginx.com/blog/tuning-nginx/
net.core.rmem_max=26214400
net.core.wmem_max=26214400
net.ipv4.tcp_rmem=4096 524288 26214400
net.ipv4.tcp_wmem=4096 524288 26214400
net.core.somaxconn=1000
net.core.netdev_max_backlog=5000
net.ipv4.tcp_max_syn_backlog=10000
net.ipv4.ip_local_port_range=16000 61000
net.ipv4.tcp_max_tw_buckets=2000000
net.ipv4.tcp_fin_timeout=30
net.core.optmem_max=20480
nginx的配置完全一样，所以我只显示主文件：
user www-data;
worker_processes auto;
worker_rlimit_nofile 50000;
pid /run/nginx.pid;
events {
worker_connections 5000;
multi_accept on;
use epoll;
}
http {
root /var/www/loadbalancer;
sendfile on;
tcp_nopush on;
tcp_nodelay on;
types_hash_max_size 2048;
server_tokens off;
client_max_body_size 5m;
client_header_timeout 20s; # default 60s
client_body_timeout 20s; # default 60s
send_timeout 20s; # default 60s
include /etc/nginx/mime.types;
default_type application/octet-stream;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dropping SSLv3, ref: POODLE
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:100m;
ssl_buffer_size 4k;
ssl_dhparam /etc/nginx/dhparam.pem;
ssl_prefer_server_ciphers on;
ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS';
ssl_session_tickets on;
ssl_session_ticket_key /etc/nginx/ssl_session_ticket.key;
ssl_session_ticket_key /etc/nginx/ssl_session_ticket_old.key;
ssl_stapling on;
ssl_stapling_verify on;
ssl_trusted_certificate /etc/ssl/rapidssl/intermediate-root.pem;
resolver 8.8.8.8;
log_format custom '$host $server_port $request_time $upstream_response_time $remote_addr "$ssl_session_reused" $upstream_addr $time_iso8601 "$request" $status $body_bytes_sent "$http_referer" "$http_user_agent";
access_log /var/log/nginx/access.log custom;
error_log /var/log/nginx/error.log;
proxy_set_header Host $http_host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_cache_path /var/cache/nginx/ levels=1:2 keys_zone=imagecache:10m inactive=7d use_temp_path=off;
proxy_connect_timeout 10s;
proxy_read_timeout 20s;
proxy_send_timeout 20s;
proxy_next_upstream off;
map $http_user_agent $outdated {
default 0;
"~MSIE [1-6]\." 1;
"~Mozilla.*Firefox/[1-9]\." 1;
"~Opera.*Version/[0-9]\." 1;
"~Chrome/[0-9]\." 1;
}
include sites/*.conf;
}
上游超时表明我们的 java 机器存在一些问题。但与此同时，debian9 nginx/loadbalancer 运行良好，连接到任何上游服务器都没有问题。letencrypt 和 SSL_write 的问题向我发出了 nginx 或 TCP 或其他问题的信号。我真的不知道如何调试这种情况。但我们可以可靠地重现它，大多数时候我们在 debian10 服务器上遇到高负载并且在 debian 9 上从未见过它。
然后我在 debian10 上安装了稳定版 nginx 1.16 看看这是否是 nginx 中已经修复的 bug：
nginx version: nginx/1.16.1
built by gcc 8.3.0 (Debian 8.3.0-6)
built with OpenSSL 1.1.1c 28 May 2019 (running with OpenSSL 1.1.1d 10 Sep 2019)
TLS SNI support enabled
configure arguments: ...
但这没有帮助。
这似乎是一个与网络相关的问题。但是我们不会在应用程序服务器上遇到它。但负载当然较低，因为负载均衡器/nginx 机器必须处理外部和内部流量。
调试非常困难，因为它只发生在高负载时。我们尝试使用 ab 对服务器进行负载测试，但我们无法重现该问题。
有人可以帮助我并给我一些提示如何开始进一步调试这种情况吗？
我们最近将服务器升级到了 debian 10。设置与 debian9 完全相同，当然还有一些新的软件包。
我们正在运行默认内核：
$ uname -a
Linux kt105 4.19.0-6-amd64 #1 SMP Debian 4.19.67-2+deb10u2 (2019-11-11) x86_64 GNU/Linux
我们在软件 raid 中使用 2 个 NVME SSD 磁盘，升级到 debian 10 后，我们遇到了高磁盘利用率。请滚动查看最后一列：
# iostat -x 20 5
Linux 4.19.0-6-amd64 (kt105) 01/29/2020 _x86_64_ (48 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
0.07 0.00 0.04 0.00 0.00 99.89
Device r/s w/s rkB/s wkB/s rrqm/s wrqm/s %rrqm %wrqm r_await w_await aqu-sz rareq-sz wareq-sz svctm %util
nvme0n1 0.00 5.97 0.03 805.42 0.00 9.37 0.00 61.07 0.30 1.31 1.00 19.16 134.83 166.12 99.26
nvme1n1 3.14 2.91 736.61 70.75 8.41 0.96 72.83 24.80 0.15 0.84 1.00 234.74 24.34 164.20 99.26
md0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 22.39 0.00 0.00 0.00
md1 0.00 0.00 0.07 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 39.29 1.00 0.00 0.00
md2 0.07 2.34 1.89 68.62 0.00 0.00 0.00 0.00 0.00 0.00 0.00 27.00 29.35 0.00 0.00
avg-cpu: %user %nice %system %iowait %steal %idle
0.03 0.00 0.02 0.00 0.00 99.95
Device r/s w/s rkB/s wkB/s rrqm/s wrqm/s %rrqm %wrqm r_await w_await aqu-sz rareq-sz wareq-sz svctm %util
nvme0n1 0.00 1.80 0.00 18.95 0.00 0.55 0.00 23.40 0.00 0.03 0.98 0.00 10.53 541.89 97.54
nvme1n1 0.00 1.80 0.00 18.95 0.00 0.55 0.00 23.40 0.00 0.03 0.98 0.00 10.53 541.89 97.54
md0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
md1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
md2 0.00 1.10 0.00 17.20 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 15.64 0.00 0.00
avg-cpu: %user %nice %system %iowait %steal %idle
0.03 0.00 0.02 0.00 0.00 99.95
Device r/s w/s rkB/s wkB/s rrqm/s wrqm/s %rrqm %wrqm r_await w_await aqu-sz rareq-sz wareq-sz svctm %util
nvme0n1 0.00 2.85 0.00 11.15 0.00 1.05 0.00 26.92 0.00 0.04 0.98 0.00 3.91 345.61 98.50
nvme1n1 0.00 2.85 0.00 11.15 0.00 1.05 0.00 26.92 0.00 0.04 0.98 0.00 3.91 345.61 98.50
md0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
md1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
md2 0.00 2.20 0.00 8.80 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 4.00 0.00 0.00
avg-cpu: %user %nice %system %iowait %steal %idle
0.03 0.00 0.02 0.00 0.00 99.94
Device r/s w/s rkB/s wkB/s rrqm/s wrqm/s %rrqm %wrqm r_await w_await aqu-sz rareq-sz wareq-sz svctm %util
nvme0n1 0.00 2.10 0.00 22.50 0.00 0.55 0.00 20.75 0.00 0.02 0.99 0.00 10.71 473.71 99.48
nvme1n1 0.00 2.10 0.00 22.50 0.00 0.55 0.00 20.75 0.00 0.02 0.99 0.00 10.71 473.71 99.48
md0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
md1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
md2 0.00 1.15 0.00 20.40 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 17.74 0.00 0.00
avg-cpu: %user %nice %system %iowait %steal %idle
0.02 0.00 0.02 0.00 0.00 99.95
一些人将此报告为内核中的错误：
https://kudzia.eu/b/2019/09/iostat-x-1-reporting-100-utilization-of-nearly-idle-nvme-drives/
我不太确定，因为我们磁盘的温度也很高：
/sbin/nvme smart-log /dev/nvme0
Smart Log for NVME device:nvme0 namespace-id:ffffffff
critical_warning : 0
temperature : 57 C
available_spare : 100%
available_spare_threshold : 10%
percentage_used : 0%
data_units_read : 48,847,719
data_units_written : 5,641,464
host_read_commands : 357,945,226
host_write_commands : 164,837,853
controller_busy_time : 320
power_cycles : 6
power_on_hours : 17,959
unsafe_shutdowns : 2
media_errors : 0
num_err_log_entries : 0
Warning Temperature Time : 0
Critical Composite Temperature Time : 0
Temperature Sensor 1 : 57 C
Thermal Management T1 Trans Count : 0
Thermal Management T2 Trans Count : 0
Thermal Management T1 Total Time : 0
Thermal Management T2 Total Time : 0
在其他配置相同且仍在运行 debian9 的服务器上，我们的磁盘利用率几乎为 0%，温度为 40 摄氏度。
iotop 显示的磁盘访问不多：
/sbin/iotop --only -ab -n5 -d5
Total DISK READ: 0.00 B/s | Total DISK WRITE: 0.00 B/s
Current DISK READ: 0.00 B/s | Current DISK WRITE: 0.00 B/s
TID PRIO USER DISK READ DISK WRITE SWAPIN IO COMMAND
Total DISK READ: 0.00 B/s | Total DISK WRITE: 11.94 K/s
Current DISK READ: 0.00 B/s | Current DISK WRITE: 9.35 K/s
TID PRIO USER DISK READ DISK WRITE SWAPIN IO COMMAND
23748 be/4 www-data 0.00 B 60.00 K 0.00 % 0.33 % nginx: worker process
637 be/3 root 0.00 B 0.00 B 0.00 % 0.00 % [jbd2/md2-8]
Total DISK READ: 0.00 B/s | Total DISK WRITE: 7.16 K/s
Current DISK READ: 0.00 B/s | Current DISK WRITE: 9.35 K/s
TID PRIO USER DISK READ DISK WRITE SWAPIN IO COMMAND
23748 be/4 www-data 0.00 B 88.00 K 0.00 % 0.16 % nginx: worker process
637 be/3 root 0.00 B 8.00 K 0.00 % 0.00 % [jbd2/md2-8]
Total DISK READ: 0.00 B/s | Total DISK WRITE: 8.75 K/s
Current DISK READ: 0.00 B/s | Current DISK WRITE: 9.35 K/s
TID PRIO USER DISK READ DISK WRITE SWAPIN IO COMMAND
23748 be/4 www-data 0.00 B 132.00 K 0.00 % 0.11 % nginx: worker process
637 be/3 root 0.00 B 8.00 K 0.00 % 0.00 % [jbd2/md2-8]
Total DISK READ: 0.00 B/s | Total DISK WRITE: 26.26 K/s
Current DISK READ: 0.00 B/s | Current DISK WRITE: 9.35 K/s
TID PRIO USER DISK READ DISK WRITE SWAPIN IO COMMAND
23748 be/4 www-data 0.00 B 252.00 K 0.00 % 0.19 % nginx: worker process
637 be/3 root 0.00 B 12.00 K 0.00 % 0.00 % [jbd2/md2-8]
23749 be/4 www-data 0.00 B 8.00 K 0.00 % 0.00 % nginx: worker process
顺便说一句，md raid array的resync几天前就完成了：
cat /proc/mdstat
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md2 : active raid1 nvme1n1p3[0] nvme0n1p3[1]
932839744 blocks super 1.2 [2/2] [UU]
bitmap: 3/7 pages [12KB], 65536KB chunk
md1 : active raid1 nvme1n1p2[0] nvme0n1p2[1]
523264 blocks super 1.2 [2/2] [UU]
md0 : active raid1 nvme1n1p1[0] nvme0n1p1[1]
4194240 blocks super 1.0 [2/2] [UU]
unused devices: <none>
当然，我已经尝试重新启动机器。
所以看起来有些东西不能正常工作。当我们在生产中将此服务器用作 nginx 负载均衡器时，我们遇到了一些无法解释的高峰中断。我们遇到了上游超时、DNS 错误、使用letsencrypt 的OSCP 装订错误。
所有这些问题都发生在相同的两分钟间隔内，并且仅在高峰使用时发生。大约 120 秒后问题消失。在此之后，一切都运行良好，直到下一个峰值（大约 2000-8000 req/s）。
还是您认为温度和磁盘使用情况正常？
这是内核错误吗？我错过了什么重要的事情吗？我怎样才能对真正的问题做一些进一步的调查？
我们在 debian 系统上运行 nginx 作为负载均衡器
nginx version: nginx/1.9.10
built with OpenSSL 1.0.2e 3 Dec 2015 (running with OpenSSL 1.0.2g 1 Mar 2016)
我们在服务器中激活了 http2，如下所示：
server {
listen 443 ssl http2;
....
}
所有请求都代理到我们的应用程序服务器。我们正在从 nginx记录request_time和。upstream_time
我们最近在第 13 周将我们的 iOS 混合应用从 UIWebView 切换到了 WKWebView，看看发生了什么：
upstream_time 保持不变，但随着越来越多的用户将他们的应用程序更新到新版本，我们的请求时间突然增加。
今天我们决定试一试并停用http2。我们只从服务器配置中删除了“http2”这个词：
server {
listen 443 ssl;
....
}
看看发生了什么：
似乎 http2 还没有准备好生产。我不知道它是服务器端还是客户端。也许甚至 request_time 也没有在 nginx 中正确记录。
有人有更多关于在 nginx 和/或 WKWebView 中使用 http2 的信息吗？
我希望我的服务器debian 8.1不使用 CPU 缩放，但始终以尽可能高的频率运行。
我已经安装了 cpufrequtils
$ dpkg -l | grep cpufreq
ii cpufrequtils 008-1 amd64 ...
ii libcpufreq0 008-1 amd64 ...
我将州长设置performance为
$ cat /etc/default/cpufrequtils
ENABLE="true"
GOVERNOR="performance"
MAX_SPEED="0"
MIN_SPEED="0"
并打电话给/etc/init.d/cpurequtils restart
当我列出我的 cpu 信息时，cpufreq-info我得到如下结果：
analyzing CPU 2:
driver: intel_pstate
CPUs which run at the same hardware frequency: 2
CPUs which need to have their frequency coordinated by software: 2
maximum transition latency: 0.97 ms.
hardware limits: 1.20 GHz - 3.80 GHz
available cpufreq governors: performance, powersave
current policy: frequency should be within 1.20 GHz and 3.80 GHz.
The governor "performance" may decide which speed to use
within this range.
current CPU frequency is 1.73 GHz (asserted by call to hardware).
最后一行显示cpu没有全速运行。当我检查 /sys 的值时，我得到相同的结果：
cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_cur_freq
echo "--"
cat /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_cur_freq
1198203
1199707
2001015
3048828
1551210
1358847
2953808
1982832
1523867
1200253
1654296
3446132
--
1198203
1199707
2001015
2643730
1772695
1358847
2953808
1982832
1523867
1200253
1654296
3446132
我想知道的是，我在 /sys 中没有任何名为“scaling_available_frequencies”的文件，这在许多howtos 中都提到过
ls -1 /sys/devices/system/cpu/cpu0/cpufreq/
affected_cpus
cpuinfo_cur_freq
cpuinfo_max_freq
cpuinfo_min_freq
cpuinfo_transition_latency
related_cpus
scaling_available_governors
scaling_cur_freq
scaling_driver
scaling_governor
scaling_max_freq
scaling_min_freq
scaling_setspeed
适当的内核模块都已加载：
$ lsmod | grep cpufre
cpufreq_powersave 12454 0
cpufreq_userspace 12525 0
cpufreq_conservative 14184 0
cpufreq_stats 12782 0
现在我像这样设置 scaling_min ：
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
现在我得到类似看到的信息，它说频率应该在 3.80 GHz 和 3.80 GHz 之间，但实际上不是：
analyzing CPU 0:
driver: intel_pstate
CPUs which run at the same hardware frequency: 0
CPUs which need to have their frequency coordinated by software: 0
maximum transition latency: 0.97 ms.
hardware limits: 1.20 GHz - 3.80 GHz
available cpufreq governors: performance, powersave
current policy: frequency should be within 3.80 GHz and 3.80 GHz.
The governor "performance" may decide which speed to use
within this range.
current CPU frequency is 2.84 GHz (asserted by call to hardware).
州长“表现”似乎没有做这项工作。那么如何强制我的 CPU 全速运行呢？
我们有一个客户为他的域设置了 CNAME 记录。不知何故，他也设法设置了一个 A 记录，这应该是不可能的，并且被 DNS 禁止。但结果是：
$ dig @ns1.your-server.de tippspiel-bl1.unternehmen-frische.de
...
;; ANSWER SECTION:
tippspiel-bl1.unternehmen-frische.de. 7200 IN CNAME www.kicktipp.de.
tippspiel-bl1.unternehmen-frische.de. 7200 IN A 78.46.10.156
第二条记录是非法的。但这导致其他缓存 DNS 服务器78.46.10.156在被问及时返回的一些混淆www.kicktipp.de。但这是完全错误的。
另一台 DNS 服务器使用了这两个答案并将它们混合在一起。最终结果：访问 www.kicktipp.de 的用户被发送到78.46.10.156哪个 IPunternehmen-frische.de
在为具有 CNAME 和 A 记录的域设置 DNS 时，我似乎可以劫持一个域。这是一个已知的错误？如何保护我的域免受它的侵害？
我想监控我的峰值网络使用情况。我已经用munin一个 5 分钟的示例来监控网络流量。但是由于我们有很多只持续几秒钟的 http 流量峰值，我想知道过去 5 分钟内每秒的峰值网络使用量，而不是平均值。
目前我使用iftop的是很容易看到峰值使用量的。但iftop只能交互运行。我使用屏幕让它运行，并且可以定期查看它。
我如何使用iftop或类似的工具每 5 分钟写出最后 5 分钟的峰值网络使用量。我只需要一个像这样行的文件：
2014-06-17 15:43:12 TX: 14,3 MBit/s RX: 16,2 MBit/s Sum: 29,6 MBit/s
2014-06-17 15:48:12 TX: 11,3 MBit/s RX: 12,2 MBit/s Sum: 22,3 MBit/s
等等。
我试过ntop了，但开销很大，而且我无法轻松地将数据输入 munin。而且它不会写出每 5 分钟的峰值。
有人知道这方面的工具或有效脚本吗？
我们有一个 tomcat 服务器集群，刚刚升级到 debian7/openjdk7/tomcat7（全部来自库存 debian）。现在我们在不同的机器上发生了两次 JVM 崩溃。两台服务器具有相同的硬件并且配置完全相同（当然除了 IP 地址）
第一次崩溃：
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007fd0b582123a, pid=6542, tid=140533723084544
#
# JRE version: 7.0_25-b30
# Java VM: OpenJDK 64-Bit Server VM (23.7-b01 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# V [libjvm.so+0x62623a] LinkResolver::runtime_resolve_interface_method(CallInfo&, methodHandle, KlassHandle, Handle, KlassHandle, bool, Thread*)+0x5a
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# If you would like to submit a bug report, please include
# instructions on how to reproduce the bug and visit:
# http://icedtea.classpath.org/bugzilla
#
--------------- T H R E A D ---------------
Current thread (0x00007fd0948b0800): JavaThread "catalina30" daemon [_thread_in_vm, id=6670, stack(0x00007fd08e94b000,0x00007fd08ea4c000)]
siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x0000000000000000
第二次崩溃：
#
# A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x00007f0a3a22421d, pid=3454, tid=139681826494208
#
# JRE version: 7.0_25-b30
# Java VM: OpenJDK 64-Bit Server VM (23.7-b01 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# V [libjvm.so+0x71021d] ParRootScanWithBarrierTwoGensClosure::do_oop(unsigned int*)+0x6d
#
# Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#
# If you would like to submit a bug report, please include
# instructions on how to reproduce the bug and visit:
# http://icedtea.classpath.org/bugzilla
#
--------------- T H R E A D ---------------
Current thread (0x000000000088c000): GCTaskThread [stack: 0x0000000000000000,0x0000000000000000] [id=3781]
siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x0000000000000018
我们以前从未发生过任何 JVM 崩溃。
我真的不知道从哪里开始。它看起来像硬件故障吗？JDK错误？雄猫虫？
最可能的原因是什么？
在我们的应用程序中，我们使用 Hibernate 和 PostgreSQL 来存储数据。在我们的一个数据库表中，我们有一个鉴别器列，例如“TIPPSPIEL”。它是一个固定的字符串，不能被任何用户操作。
突然间，我们在这个巨大的表格中有一个条目，其中我们有“TIPPQPIEL”而不是“TIPPSPIEL”。我们不知道这怎么会发生。
有没有可能我们的硬盘换了一位，所以我们的字母“S”不再编码为“1010001”，而是突然变成了硬盘上的“Q”，换了一位：1010011？
我不是硬盘物理学专家，但我猜操作系统或磁盘具有校验和和其他东西，以确保不会发生这种情况。
是否有可能只有一位切换所以我的文件显示一个字母“Q”而不是“S”？
更新：我们做了进一步的分析。我们的从数据库从主数据库（PostgreSQL 特性）获取它的 WAL 记录。不管怎样：我们的从服务器应该是同步的。但是从站对于这一特定行并不同步。我们可以看到它发生在几天前，没有用户对此特定条目进行任何交互。所以它必须有点翻转。害怕！