우리는 대형(5T) 하드 드라이브 파티션을 갖춘 4개의 동일한 Linux 서버를 보유하고 있습니다. 다음 커널을 사용하는 Scientific Linux가 있습니다.
Linux s3.law.di.unimi.it 2.6.32-358.18.1.el6.x86_64 #1 SMP Tue Aug 27 14:23:09 CDT 2013 x86_64 x86_64 x86_64 GNU/Linux
이들 서버의 구성, 설치 등은 모두 동일합니다. 그러나 ext4를 사용하여 쓸 때 단 하나의 서버만 터무니없이 느립니다. 내가 만들면
dd if=/dev/zero of=/mnt/big/analysis/test
l -tr
total 11M
-rw-r--r-- 1 root root 11M Apr 20 10:01 test
10:01:42 [s3] /mnt/big/analysis
l -tr
total 16M
-rw-r--r-- 1 root root 16M Apr 20 10:02 test
10:02:13 [s3] /mnt/big/analysis
30초에 5MB가 됩니다. 다른 모든 서버의 쓰기 속도는 훨씬 더 빠릅니다.
이 머신은 64GB, 32개 코어였으며 I/O나 CPU 활동이 없었지만 메모리의 90%는 아무 작업도 하지 않는 대규모 Java 프로세스에 의해 점유되었습니다. 오직하나기계가 천천히 쓰고 있습니다.
SMART는 모든 것이 괜찮다는 것을 의미합니다.
# smartctl -H /dev/sdb
smartctl 5.42 2011-10-20 r3458 [x86_64-linux-2.6.32-358.18.1.el6.x86_64] (local build)
Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net
SMART Health Status: OK
hdparm은 문제 없이 읽습니다.
# hdparm -t /dev/sdb
/dev/sdb:
Timing buffered disk reads: 1356 MB in 3.00 seconds = 451.60 MB/sec
파티션은 다음과 같이 마운트됩니다.
/dev/sdb1 on /mnt/big type ext4 (rw,noatime,data=writeback)
우리는 설정했다
tune2fs -o journal_data_writeback /dev/sdb1
성능을 위해.
나는 찾으려고 노력한다아무것이는 이 특정 서버의 쓰기 속도가 너무 느린 이유, 즉 진단 도구의 출력에는 차이가 있지만 아무것도 설명되지 않는 이유를 설명합니다.
그림을 완성하려면 본질적으로 비어 있는 파티션이 있는 모든 서버에서 크롤링을 시작합니다. 크롤링으로 인해 파티션에 많은 파일, 특히 156G 파일(크롤링된 저장소)이 생성되었습니다. 크롤링은 정상적으로 시작되었지만 몇 시간 후에는 속도가 느려지는 것을 발견했습니다(분명히 매장이 성장함에 따라). 확인해 보니 디스크 쓰기 속도가 점점 느려지고 있는 것으로 나타났습니다.
CPU 활동도 없고 I/O도 없이 모든 것을 중지했지만 dd는 여전히 위의 동작을 보여줍니다. 다른 세 서버는 크롤링 및 dd 사용 중에 동일한 조건, 동일한 파일 등에서 완벽하게 작동합니다.
솔직히 나도 잘 모르겠어어디보세요. 누군가 벨이 울리는 것을 들어본 적이 있나요? 무슨 일이 일어나고 있는지 알아내기 위해 어떤 진단 도구를 사용할 수 있으며, 어떤 테스트를 시도해야 합니까?
고쳐 쓰다
게시된 링크 외에도 크롤러를 실행하는 두 서버 모두에서 동일한 테스트를 실행하는 것이 좋을 것이라고 생각합니다. 정말 흥미롭습니다. 예를 들어, vmstat 10은 다음을 제공합니다.
좋아요
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
4 0 68692 9009864 70832 29853400 0 0 15 214 9 2 11 1 88 0 0
10 0 68692 8985620 70824 29883460 0 0 48 7402 79465 62898 12 1 86 0 0
11 0 68692 8936780 70824 29928696 0 0 54 6842 81500 66665 15 1 83 0 0
10 2 68692 8867280 70840 30000104 0 0 65 36578 80252 66272 14 1 85 0 0
15 0 68692 8842960 70840 30026724 0 0 61 3667 81245 65161 14 1 85 0 0
나쁜
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
13 0 8840 14015100 92972 25683108 0 0 11 104 3 9 4 1 94 0 0
2 0 8840 14015800 92984 25696108 0 0 49 16835 38619 54204 2 2 96 0 0
1 0 8840 14026004 93004 25699940 0 0 33 4152 25914 43530 0 2 98 0 0
1 0 8840 14032272 93012 25703716 0 0 30 1164 25062 43230 0 2 98 0 0
2 0 8840 14029632 93020 25709448 0 0 24 5619 23475 40080 0 2 98 0 0
그리고 iostat -x -k 5
좋아요
Linux 2.6.32-358.18.1.el6.x86_64 (s0.law.di.unimi.it) 04/21/2014 _x86_64_ (64 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
10.65 0.00 1.02 0.11 0.00 88.22
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sdb 0.11 3338.25 17.98 56.52 903.55 13579.19 388.79 7.32 98.30 1.23 9.18
sda 0.39 0.72 0.49 0.76 11.68 5.90 28.25 0.01 11.25 3.41 0.43
avg-cpu: %user %nice %system %iowait %steal %idle
15.86 0.00 1.33 0.03 0.00 82.78
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sdb 0.00 1106.20 9.20 31.00 36.80 4549.60 228.18 0.41 10.09 0.39 1.58
sda 0.00 2.20 0.80 3.00 4.80 20.80 13.47 0.04 10.53 3.21 1.22
avg-cpu: %user %nice %system %iowait %steal %idle
15.42 0.00 1.23 0.01 0.00 83.34
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sdb 0.00 1205.40 8.00 33.60 40.80 4956.00 240.23 0.39 9.43 0.33 1.38
sda 0.00 0.60 0.00 1.00 0.00 6.40 12.80 0.01 5.20 4.20 0.42
나쁜
Linux 2.6.32-358.18.1.el6.x86_64 (s2.law.di.unimi.it) 04/21/2014 _x86_64_ (64 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
4.37 0.00 1.41 0.06 0.00 94.16
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sdb 0.06 1599.70 13.76 38.23 699.27 6551.73 278.96 3.12 59.96 0.99 5.16
sda 0.46 3.17 1.07 0.78 22.51 15.85 41.26 0.03 16.10 2.70 0.50
avg-cpu: %user %nice %system %iowait %steal %idle
11.93 0.00 2.99 0.60 0.00 84.48
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sdb 0.00 14885.40 13.60 141.20 54.40 60106.40 777.27 34.90 225.45 1.95 30.14
sda 0.00 0.40 0.00 0.80 0.00 4.80 12.00 0.01 7.00 3.25 0.26
avg-cpu: %user %nice %system %iowait %steal %idle
11.61 0.00 2.51 0.16 0.00 85.71
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util
sdb 0.00 2245.40 10.60 51.20 42.40 9187.20 298.69 3.51 56.80 2.04 12.58
sda 0.00 0.40 0.00 0.80 0.00 4.80 12.00 0.01 6.25 3.25 0.26
따라서 (출력을 올바르게 이해한다면) 그렇습니다. 느린 서버가 I/O를 수행하는 데 시간이 오래 걸린다는 것이 JVM 스택 추적에서 분명합니다. 이유를 이해해야합니다 :(.
나도 하나를 실행했습니다 strace -c ls -R /. 한동안 실행되고 있다는 사실을 인지하지 못했기 때문에 이전 데이터는 큰 의미가 없습니다. 명령이 실행되었습니다크롤러가 실행 중일 때, 그래서 많은 I/O가 진행되고 있습니다.
좋아요
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
99.62 14.344825 114 126027 getdents
0.25 0.036219 1 61812 12 open
0.07 0.009891 0 61802 close
0.06 0.007975 0 61801 fstat
0.01 0.000775 0 8436 write
0.00 0.000043 22 2 rt_sigaction
0.00 0.000000 0 12 read
0.00 0.000000 0 1 stat
0.00 0.000000 0 3 1 lstat
0.00 0.000000 0 33 mmap
0.00 0.000000 0 16 mprotect
0.00 0.000000 0 4 munmap
0.00 0.000000 0 15 brk
0.00 0.000000 0 1 rt_sigprocmask
0.00 0.000000 0 3 3 ioctl
0.00 0.000000 0 1 1 access
0.00 0.000000 0 3 mremap
0.00 0.000000 0 1 execve
0.00 0.000000 0 1 fcntl
0.00 0.000000 0 1 getrlimit
0.00 0.000000 0 1 statfs
0.00 0.000000 0 1 arch_prctl
0.00 0.000000 0 3 1 futex
0.00 0.000000 0 1 set_tid_address
0.00 0.000000 0 1 set_robust_list
------ ----------- ----------- --------- --------- ----------------
100.00 14.399728 319982 18 total
나쁜
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
99.81 24.210936 181 133618 getdents
0.14 0.032755 1 63183 14 open
0.03 0.006637 0 63171 close
0.02 0.005410 0 63170 fstat
0.00 0.000434 0 15002 write
0.00 0.000000 0 12 read
0.00 0.000000 0 1 stat
0.00 0.000000 0 4 1 lstat
0.00 0.000000 0 33 mmap
0.00 0.000000 0 16 mprotect
0.00 0.000000 0 4 munmap
0.00 0.000000 0 25 brk
0.00 0.000000 0 2 rt_sigaction
0.00 0.000000 0 1 rt_sigprocmask
0.00 0.000000 0 3 3 ioctl
0.00 0.000000 0 1 1 access
0.00 0.000000 0 3 mremap
0.00 0.000000 0 1 execve
0.00 0.000000 0 1 fcntl
0.00 0.000000 0 1 getrlimit
0.00 0.000000 0 1 statfs
0.00 0.000000 0 1 arch_prctl
0.00 0.000000 0 3 1 futex
0.00 0.000000 0 1 set_tid_address
0.00 0.000000 0 1 set_robust_list
------ ----------- ----------- --------- --------- ----------------
100.00 24.256172 338259 20 total
답변1
이것이 커널입니다. 꽤 오래된 버전인 2.6.32를 사용하고 있지만 Red Hat EL과 Scientific Linux에서 지원하는 버전입니다.
오늘은 친구와 점심을 먹었습니다(주세페 오타비아노) 고성능 인덱싱 알고리즘 튜닝에 비슷한 경험이 있는 사람입니다. 모든 것(컴파일러, 라이브러리 등)을 최신 버전으로 업그레이드한 후 커널을 3.10 시리즈로 변경했는데 갑자기 모든 것이 잘 작동했습니다.
그것은 우리에게도 효과가 있습니다. 3.10 커널 사용(제공:http://elrepo.org), 모든 문제가 해결되었습니다.
Giuseppe는 NUMA와 커널 페이징 사이에 유해한 상호 작용이 있어 커널이 동일한 데이터를 미친 듯이 로드하고 저장하여 시스템이 거의 정지할 뻔했다고 의심했습니다.
답변2
txt 파일과 관련하여 이 모든 것은 모든 컴퓨터에서 "정상"인 것 같습니다...낮은 대기 시간(디스크 대기 시간), "나쁜" 컴퓨터의 경우 훨씬 더 낮음(=더 좋음)...요청 대기열도 좋음, 0wa(IO 대기) vmstat의 시간).
그런데 5MB/30초에서 130MB/초로 바뀌었습니다. 무슨 일이 일어나고 있나요?