bacula 백업 시스템을 실행하는 Linux 서버가 있습니다. 기계가 스왑하기에 무거워서 미친 듯이 연삭하고 있습니다. 문제는 실제 메모리의 60 % 만 사용한다는 것입니다!
출력은 다음과 같습니다 free -m.
free -m
total used free shared buffers cached
Mem: 3949 2356 1593 0 0 1
-/+ buffers/cache: 2354 1595
Swap: 7629 1804 5824
및 일부 샘플 출력 vmstat 1:
procs -----------memory---------- ---swap-- -----io---- -system-- -----cpu------
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 2 1843536 1634512 0 4188 54 13 2524 666 2 1 1 1 89 9 0
1 11 1845916 1640724 0 388 2700 4816 221880 4879 14409 170721 4 3 63 30 0
0 9 1846096 1643952 0 0 4956 756 174832 804 12357 159306 3 4 63 30 0
0 11 1846104 1643532 0 0 4916 540 174320 580 10609 139960 3 4 64 29 0
0 4 1846084 1640272 0 2336 4080 524 140408 548 9331 118287 3 4 63 30 0
0 8 1846104 1642096 0 1488 2940 432 102516 457 7023 82230 2 4 65 29 0
0 5 1846104 1642268 0 1276 3704 452 126520 452 9494 119612 3 5 65 27 0
3 12 1846104 1641528 0 328 6092 608 187776 636 8269 113059 4 3 64 29 0
2 2 1846084 1640960 0 724 5948 0 111480 0 7751 116370 4 4 63 29 0
0 4 1846100 1641484 0 404 4144 1476 125760 1500 10668 105358 2 3 71 25 0
0 13 1846104 1641932 0 0 5872 828 153808 840 10518 128447 3 4 70 22 0
0 8 1846096 1639172 0 3164 3556 556 74884 580 5082 65362 2 2 73 23 0
1 4 1846080 1638676 0 396 4512 28 50928 44 2672 38277 2 2 80 16 0
0 3 1846080 1628808 0 7132 2636 0 28004 8 1358 14090 0 1 78 20 0
0 2 1844728 1618552 0 11140 7680 0 12740 8 763 2245 0 0 82 18 0
0 2 1837764 1532056 0 101504 2952 0 95644 24 802 3817 0 1 87 12 0
0 11 1842092 1633324 0 4416 1748 10900 143144 11024 6279 134442 3 3 70 24 0
2 6 1846104 1642756 0 0 4768 468 78752 468 4672 60141 2 2 76 20 0
1 12 1846104 1640792 0 236 4752 440 140712 464 7614 99593 3 5 58 34 0
0 3 1846084 1630368 0 6316 5104 0 20336 0 1703 22424 1 1 72 26 0
2 17 1846104 1638332 0 3168 4080 1720 211960 1744 11977 155886 3 4 65 28 0
1 10 1846104 1640800 0 132 4488 556 126016 584 8016 106368 3 4 63 29 0
0 14 1846104 1639740 0 2248 3436 428 114188 452 7030 92418 3 3 59 35 0
1 6 1846096 1639504 0 1932 5500 436 141412 460 8261 112210 4 4 63 29 0
0 10 1846104 1640164 0 3052 4028 448 147684 472 7366 109554 4 4 61 30 0
0 10 1846100 1641040 0 2332 4952 632 147452 664 8767 118384 3 4 63 30 0
4 8 1846084 1641092 0 664 4948 276 152264 292 6448 98813 5 5 62 28 0
또한 CPU 시간별로 정렬 된 최고 출력은 스왑이 시스템을 쇠약하게한다는 이론을 지원하는 것으로 보입니다.
top - 09:05:32 up 37 days, 23:24, 1 user, load average: 9.75, 8.24, 7.12
Tasks: 173 total, 1 running, 172 sleeping, 0 stopped, 0 zombie
Cpu(s): 1.6%us, 1.4%sy, 0.0%ni, 76.1%id, 20.6%wa, 0.1%hi, 0.2%si, 0.0%st
Mem: 4044632k total, 2405628k used, 1639004k free, 0k buffers
Swap: 7812492k total, 1851852k used, 5960640k free, 436k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ TIME COMMAND
4174 root 17 0 63156 176 56 S 8 0.0 2138:52 35,38 bacula-fd
4185 root 17 0 63352 284 104 S 6 0.0 1709:25 28,29 bacula-sd
240 root 15 0 0 0 0 D 3 0.0 831:55.19 831:55 kswapd0
2852 root 10 -5 0 0 0 S 1 0.0 126:35.59 126:35 xfsbufd
2849 root 10 -5 0 0 0 S 0 0.0 119:50.94 119:50 xfsbufd
1364 root 10 -5 0 0 0 S 0 0.0 117:05.39 117:05 xfsbufd
21 root 10 -5 0 0 0 S 1 0.0 48:03.44 48:03 events/3
6940 postgres 16 0 43596 8 8 S 0 0.0 46:50.35 46:50 postmaster
1342 root 10 -5 0 0 0 S 0 0.0 23:14.34 23:14 xfsdatad/4
5415 root 17 0 1770m 108 48 S 0 0.0 15:03.74 15:03 bacula-dir
23 root 10 -5 0 0 0 S 0 0.0 13:09.71 13:09 events/5
5604 root 17 0 1216m 500 200 S 0 0.0 12:38.20 12:38 java
5552 root 16 0 1194m 580 248 S 0 0.0 11:58.00 11:58 java
가상 메모리 이미지 크기별로 동일한 정렬이 있습니다.
top - 09:08:32 up 37 days, 23:27, 1 user, load average: 8.43, 8.26, 7.32
Tasks: 173 total, 1 running, 172 sleeping, 0 stopped, 0 zombie
Cpu(s): 3.6%us, 3.4%sy, 0.0%ni, 62.2%id, 30.2%wa, 0.2%hi, 0.3%si, 0.0%st
Mem: 4044632k total, 2404212k used, 1640420k free, 0k buffers
Swap: 7812492k total, 1852548k used, 5959944k free, 100k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ TIME COMMAND
5415 root 17 0 1770m 56 44 S 0 0.0 15:03.78 15:03 bacula-dir
5604 root 17 0 1216m 492 200 S 0 0.0 12:38.30 12:38 java
5552 root 16 0 1194m 476 200 S 0 0.0 11:58.20 11:58 java
4598 root 16 0 117m 44 44 S 0 0.0 0:13.37 0:13 eventmond
9614 gdm 16 0 93188 0 0 S 0 0.0 0:00.30 0:00 gdmgreeter
5527 root 17 0 78716 0 0 S 0 0.0 0:00.30 0:00 gdm
4185 root 17 0 63352 284 104 S 20 0.0 1709:52 28,29 bacula-sd
4174 root 17 0 63156 208 88 S 24 0.0 2139:25 35,39 bacula-fd
10849 postgres 18 0 54740 216 108 D 0 0.0 0:31.40 0:31 postmaster
6661 postgres 17 0 49432 0 0 S 0 0.0 0:03.50 0:03 postmaster
5507 root 15 0 47980 0 0 S 0 0.0 0:00.00 0:00 gdm
6940 postgres 16 0 43596 16 16 S 0 0.0 46:51.39 46:51 postmaster
5304 postgres 16 0 40580 132 88 S 0 0.0 6:21.79 6:21 postmaster
5301 postgres 17 0 40448 24 24 S 0 0.0 0:32.17 0:32 postmaster
11280 root 16 0 40288 28 28 S 0 0.0 0:00.11 0:00 sshd
5534 root 17 0 37580 0 0 S 0 0.0 0:56.18 0:56 X
30870 root 30 15 31668 28 28 S 0 0.0 1:13.38 1:13 snmpd
5305 postgres 17 0 30628 16 16 S 0 0.0 0:11.60 0:11 postmaster
27403 postfix 17 0 30248 0 0 S 0 0.0 0:02.76 0:02 qmgr
10815 postfix 15 0 30208 16 16 S 0 0.0 0:00.02 0:00 pickup
5306 postgres 16 0 29760 20 20 S 0 0.0 0:52.89 0:52 postmaster
5302 postgres 17 0 29628 64 32 S 0 0.0 1:00.64 1:00 postmaster
swappiness커널 매개 변수를 높은 값과 낮은 값으로 조정하려고 시도했지만 여기에서 동작을 변경하는 것으로 보이는 것은 없습니다. 나는 무슨 일이 일어나고 있는지 알아 내지 못하고있다. 이 문제의 원인을 어떻게 알 수 있습니까?
업데이트 : 시스템은 완전 64 비트 시스템이므로 32 비트 문제로 인한 메모리 제한에 대한 의문은 없습니다.
업데이트 2 : 원래 질문에서 언급했듯이 스왑 피니 스는 0을 포함하여 모든 종류의 값으로 조정하려고 시도했습니다. 결과는 항상 동일하며 약 1.6GB의 메모리가 사용되지 않습니다.
업데이트 3 : 위 정보에 최고 출력을 추가했습니다.
답변
Bacula 성능은 데이터베이스에 따라 크게 다릅니다. 아마도 서버를 죽이는 것은 postgresql입니다. 대기 상태에서 보낸 평균로드 평균과 상당히 많은 CPU 시간의 %는 디스크 I / O를 기다리고 있음을 분명히 보여줍니다 … 그리고 PostgreSQL이하고 있습니다. 백업의 모든 파일에 대해 적어도 UPDATE 문을 수행하도록 설정하십시오. 스와핑에 대해 걱정하지 마십시오.
PostgreSQL 설치를 조정하십시오. 개별 데이터베이스 (또는 테이블)에 자체 디스크 / 레이드 세트를 제공하여 I / O를 분산시킬 수 있습니다. PostgreSQL이 비동기 쓰기를 아직 사용하지 않는 경우 강제 쓰기를 사용할 수 있습니다 … 쓰기 성능을 위해 데이터베이스 무결성을 거래하고 있지만. PostgreSQL에 사용 가능한 공유 메모리에서 지옥을 높이십시오. 이는 데이터베이스에 대한 최소한의 읽기를 완화시킵니다. 이 작업을 수행하지 않은 경우 Bacula 데이터베이스에서 VACCUM ANALYZE를 실행하고 쿼리 최적화 프로그램에 작업 할 것을 제공하십시오.
지금까지 Bacula의 가장 약점은 데이터베이스 종속성 (및 그 중 일부의 뇌사)입니다. 최근 대규모 백업을 제거하고 수십만 건의 쿼리를 실행하는 데 시간이 얼마나 걸리는지 확인하십시오. .. Bacula는 비교적 적은 수의 큰 파일을 좋아합니다. 그렇지 않으면 개입니다.
답변
당신은 I / O 바인딩입니다. 시스템은 약간의 구명 뗏목이며 폭풍우가 치는 바다에서 100 피트 높이의 버퍼 / 캐시 / VM 페이징 팽창이 발생합니다.
와. 그냥 … 와우 I / O에서 약 100MB / 초를 이동하고 I / O 대기에서 CPU 시간이 50 %를 초과하고 4Gb의 RAM이 있습니다. 이 서버 VM의 역 압력은 엄청나게 커야합니다. “정상적인”상황에서 시스템이 버퍼링 / 캐시를 시작하면 사용 가능한 RAM 이 40 초 이내에 살아 남게됩니다 .
게시 할 수 있을까요 설정 에서 /proc/sys/vm? 이것은 커널이 “정상”이라고 생각하는 것에 대한 통찰력을 제공합니다.
이러한 postmaster프로세스는 백그라운드에서 PostgreSQL을 실행 중임을 나타냅니다. 이것이 설정에 정상입니까? 기본 구성의 PostgreSQL은 RAM을 거의 사용하지 않지만 일단 속도를 위해 다시 조정하면 사용 가능한 RAM의 25 % -40 %를 빠르게 씹을 수 있습니다. 따라서 출력의 수를 고려할 때 백업을 실행하는 동안 일종의 프로덕션 데이터베이스를 실행하고 있다고 추측 할 수 있습니다. 이것은 잘 지내지 않습니다. 왜 실행되고 있는지 더 많은 정보를 줄 수 있습니까? 모든 공유 메모리 매개 변수의 크기는 얼마입니까?postmaster프로세스? 백업이 실행되는 동안 더 적은 연결 / 버퍼를 사용하도록 서비스를 종료하거나 데이터베이스를 임시로 재구성 할 수 있습니까? 이렇게하면 이미 변형 된 I / O 및 사용 가능한 RAM을 약간 줄이는 데 도움이됩니다. 각 postmaster프로세스는 데이터베이스가 내부 캐싱에 사용하는 것 이상으로 RAM을 소비합니다. 따라서 메모리 설정을 조정할 때 어떤 것이 “공유”되고 어떤 것이 “프로세스 당”인지주의하십시오 .
백업 프로세스의 일부로 PostgreSQL을 사용하는 경우 최소 연결 수만 허용하도록 재조정 하고 프로세스 별 매개 변수를 합리적인 수준으로 줄이십시오 (각각 몇 메그 만). 이것의 단점은 PostgreSQL이 원하는 RAM의 데이터 세트와 함께 작동하지 않으면 디스크에 유출되므로 실제로 디스크 I / O 가 증가 하므로 조심스럽게 조정하십시오.
X11 자체는 많은 메모리를 차지하지 않지만 전체 데스크톱 세션은 몇 메가를 소비 할 수 있습니다. 사용중인 모든 세션을 로그 아웃하고 콘솔 또는 SSH를 통해 연결을 실행하십시오.
아직도, 나는 그것이 완전히 메모리 문제라고 생각하지 않습니다. I / O 대기 시간이 50 %보다 길면 오랜 시간 동안 (그리고 70 년대에 해당하는 수치를 게시하는 경우) 결과적으로 병목 현상이 발생하여 나머지 시스템이 중단됩니다. 다스 베이더 가 목을 부수는 것처럼 .
플러시 스레드 는 몇 개 입니까? 사용하다
cat /proc/sys/vm/nr_pdflush_threads
찾아서
echo "vm.nr_pdflush_threads = 1" >> /etc/sysctl.conf
단일 스레드로 설정하십시오. 마지막 명령은 재부팅시 영구적으로로드됩니다. 1 또는 2를 보는 것은 드문 일이 아닙니다. I / O를 위해 여러 개의 코어 또는 많은 스핀들 / 버스 용량이있는 경우 이러한 코어를 약간 (약간) 부딪치게됩니다. 더 많은 플러시 스레드 = 더 많은 I / O 활동, 또한 더 많은 I / O 대기에 소비 된 CPU 시간.
기본값입니까, 아니면 부딪 쳤습니까? 충돌이 발생한 경우 I / O ops의 압력을 줄이기 위해 숫자를 줄이는 것을 고려 했습니까? 또는 수많은 스핀들과 채널을 사용할 수 있습니까?이 경우 플러시 스레드 수를 늘리는 것을 고려한 적이 있습니까?
추신 : 스왑 아웃을 방지하기 위해 스왑을 높은 값이 아닌 낮은 값으로 설정하려고합니다. 가장 높은 값 = 100 = 기분이 좋을 때 미친 것처럼 스왑, 가장 낮은 값 = 0 = 전혀 바꾸지 마십시오.
답변
IO에서 초당 읽은 블록 (bi)을 보면 스왑 활동이 여러 자릿수만큼 줄어 듭니다. 스왑 사용이 디스크 스 래싱을 일으키는 원인이라고 생각하지 않습니다. 상자에서 실행 중 많은 디스크 활동 (읽기)을 유발하는 것으로 생각됩니다.
실행중인 응용 프로그램을 조사하고 범인을 찾을 수 있는지 확인했습니다.
답변
이 링크가 귀하의 질문에 대한 답변인지 확인하십시오. 나는 정기적으로 Linux 페이징 (스왑하지 않음) 메모리를 60 % 사용하기 오래 전에 보았습니다. 이것은 메모리 튜닝의 예상 부분입니다.
http://www.sheepguardingllama.com/?p=2252
그러나 버퍼 / 캐시가 부족하면 걱정이됩니다. 매우 이례적인 것 같습니다. 그래서 더 많은 것이 잘못되었다고 생각합니다.
답변
스왑을 완전히 비활성화 할 수 있습니까?
swapoff /dev/hdb2
또는 적어도 일부는 스왑이 다른 문제가 아닌 문제임을 확인합니다.
답변
기본적으로 swappiness는 60으로 설정되어 있습니다.
고양이 / proc / sys / vm / swappiness 60
Swappiness는 커널이 RAM보다 스왑을 선호하는 정도를 조정하는 데 사용되는 커널입니다. 교환 율이 높으면 커널이 많이 교환되고 교환 율이 낮 으면 커널이 교환 공간을 사용하지 않습니다.
이 편집 을 /etc/sysctl.conf 에서 vm.swappiness 값을 변경할 수 있습니다 .
답변
명령 을 보거나 발행 할 수있는 커널 의 스왑 핀 니스를 수동 으로 설정할 수 있습니다 . swappiness는 스왑 사용량을 결정하는 커널 설정입니다./proc/sys/vm/swappinesssysctl vm.swappiness
설정 sudo sysctl vm.swappiness=0하면 스왑 파티션이 효과적으로 비활성화됩니다. 이 변경 사항을 영구적으로 만들려면 vm.swappiness=0에서 추가 / 수정할 수 있습니다 /etc/sysctl.conf. 당신에게 좋은 가치가 무엇인지 알아야합니다. 개인적 vm.swappiness=10으로 기본값으로 60을 구성했습니다 .
