Linux 서버는 60 %의 메모리 만 사용하고 스와핑

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을 구성했습니다 .

또 다른 것은 커널 실행 큐이며 상호 호환 불가능한 프로세스 (vmstat의 'r'및 'b'열)는 시스템이 때때로 포화 상태임을 나타내는 지표입니다. 참고로, 포화와 활용을 혼동하지 마십시오 ... 실제 문제는 포화 커널에 대한 굶주린 프로세스 스택 일 수 있습니다.

'pmap -x [PID]'를 실행하여보다 많은 소비 프로세스에서 추가 메모리 세부 사항을 얻을 수도 있습니다. 행운을 빌어 요!

매트

많은 메모리를 사용하는 수명이 짧은 프로세스 일 수 있습니다. 그런 다음 프로세스를 알아 차리기 전에 종료하십시오.

이것은 어쨌든보고있는 것과 일치합니다.

아이 노드 캐시 관련 문제를 조사 했습니까? slabtop이런 식으로 실행되는 경우 적어도 시작점을 제공해야합니다.

시스템이 64 비트 인 경우 시스템이 실제로 사용 가능한 모든 메모리를 처리하지 못할 수 있습니다. 이것은 칩셋 한계입니다. 예를 들어, 이전 세대 Mac mini는 4GB의 램을 "지원"하지만 실제로 3.3GB 만 처리 할 수있었습니다.