Máy chủ Linux chỉ sử dụng 60% bộ nhớ, sau đó trao đổi

Tôi đã có một máy chủ Linux đang chạy hệ thống sao lưu bacula của chúng tôi. Cỗ máy đang nghiền như điên vì nó rất nặng để trao đổi. Vấn đề là, nó chỉ sử dụng 60% bộ nhớ vật lý của nó!

Đây là đầu ra từ 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

và một số mẫu đầu ra từ 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

Hơn nữa, đầu ra của đầu được sắp xếp theo thời gian CPU dường như hỗ trợ lý thuyết rằng hoán đổi là thứ làm chậm hệ thống:

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

Đây là cùng một sắp xếp theo kích thước hình ảnh bộ nhớ ảo:

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

Tôi đã thử điều chỉnh swappinesstham số kernel thành cả giá trị cao và thấp, nhưng không có gì thay đổi hành vi ở đây. Tôi không biết phải làm gì. Làm thế nào tôi có thể tìm ra những gì gây ra điều này?

Cập nhật: Hệ thống này là một hệ thống 64 bit hoàn toàn, do đó không có câu hỏi nào về giới hạn bộ nhớ do các vấn đề 32 bit.

Update2: Như tôi đã đề cập trong câu hỏi ban đầu, tôi đã thử điều chỉnh swappiness theo tất cả các loại giá trị, bao gồm 0. Kết quả luôn giống nhau, với khoảng 1,6 GB bộ nhớ vẫn chưa được sử dụng.

Update3: Đã thêm đầu ra hàng đầu vào thông tin trên.

Hiệu suất Bacula phụ thuộc vào cơ sở dữ liệu cao. Có khả năng, đó là postgresql đang giết chết máy chủ của bạn. Trung bình tải cao và% thời gian cpu khá lớn dành cho trạng thái chờ cho thấy rõ ràng nó đang chờ Đĩa I / O ... Và đó là việc PostgreQuery đang làm. Đối với mỗi tệp trong bản sao lưu của bạn, hãy đặt ít nhất một câu lệnh CẬP NHẬT. Đừng lo lắng về việc hoán đổi.

Đừng điều chỉnh cài đặt PostgreSQL. Có thể cung cấp cho cơ sở dữ liệu cá nhân (hoặc thậm chí các bảng) các bộ đĩa / đột kích của riêng chúng để truyền bá I / O xung quanh. Bạn có thể buộc PostgreSQL sử dụng ghi không đồng bộ nếu nó chưa ... Mặc dù đó là tính toàn vẹn của cơ sở dữ liệu giao dịch để thực hiện ghi. Tăng cường thoát khỏi bộ nhớ chia sẻ có sẵn cho PostgreSQL. Điều đó sẽ làm giảm bớt ít nhất rất nhiều việc đọc trên cơ sở dữ liệu. Nếu bạn chưa bao giờ thực hiện nó, hãy chạy VACCUM ANALYZE trên cơ sở dữ liệu Bacula để cung cấp cho trình tối ưu hóa truy vấn một cái gì đó để làm việc.

Cho đến nay, điểm yếu nhất của Bacula là sự phụ thuộc vào cơ sở dữ liệu (và sự chết não của một số trong số đó ...) Chạy một cuộc thanh trừng một bản sao lưu lớn gần đây và nhận thấy mất bao lâu (hàng giờ) để chạy vài chục triệu truy vấn. .. Bacula thích tương đối ít tập tin lớn, nếu không đó là một con chó.

Bạn bị ràng buộc I / O. Hệ thống của bạn là một chiếc bè nhỏ, bị vùi dập trong một biển bão bộ đệm / bộ đệm / VM phồng cao 100 feet.

Ồ Chỉ là ... wow. Bạn đang di chuyển khoảng 100Mbyte / giây ra I / O của mình, bạn đã vượt quá 50% thời gian CPU trong thời gian chờ I / O và bạn có RAM 4Gb. Áp lực trên VM của máy chủ này phải rất lớn. Trong trường hợp "bình thường", khi hệ thống bắt đầu đệm / bộ đệm, bất kỳ RAM miễn phí nào bạn có sẽ là ăn sống trong vòng chưa đầy 40 giây .

Có thể đăng các cài đặt từ/proc/sys/vm ? Điều này sẽ cung cấp một số cái nhìn sâu sắc về những gì hạt nhân của bạn nghĩ là "bình thường".

Các postmasterquy trình này cũng cho biết bạn đang chạy PostgreSQL trong nền. Đây có phải là bình thường cho thiết lập của bạn? PostgreSQL trong cấu hình mặc định sẽ sử dụng rất ít RAM, nhưng một khi được điều chỉnh lại về tốc độ, nó có thể nhai 25% -40% RAM khả dụng của bạn một cách nhanh chóng. Vì vậy, tôi chỉ có thể đoán, với số lượng chúng trong đầu ra, bạn đang chạy một số loại cơ sở dữ liệu sản xuất trong khi bạn đang chạy sao lưu. Điều này không tốt cho lắm. Bạn có thể cung cấp thêm một số thông tin về lý do tại sao nó đang chạy? Kích thước của tham số bộ nhớ dùng chung cho tất cảpostmasterquy trình? Có thể tắt dịch vụ hoặc tạm thời cấu hình lại cơ sở dữ liệu để sử dụng ít kết nối / bộ đệm hơn trong khi các bản sao lưu đang chạy? Điều này sẽ giúp giảm bớt một số áp lực đối với I / O đã bị căng thẳng và RAM miễn phí. Hãy nhớ rằng mỗi postmasterquá trình tiêu thụ RAM ở trên và vượt ra ngoài những gì cơ sở dữ liệu sử dụng cho bộ nhớ đệm bên trong. Vì vậy, khi bạn thực hiện điều chỉnh cài đặt bộ nhớ, hãy cẩn thận về "chia sẻ" và "theo quy trình" .

Nếu bạn đang sử dụng PostgreSQL như một phần của quy trình sao lưu của mình, hãy thử điều chỉnh lại để chỉ chấp nhận số lượng kết nối tối thiểu và đảm bảo thu nhỏ các tham số theo quy trình của bạn xuống mức hợp lý (chỉ một vài megs mỗi lần). Nhược điểm của điều này là PostgreSQL sẽ tràn vào đĩa nếu nó không thể hoạt động với bộ dữ liệu trong RAM như nó muốn, do đó sẽ thực sự tăng I / O đĩa của bạn , vì vậy hãy điều chỉnh cẩn thận.

Bản thân X11 không chiếm nhiều bộ nhớ, nhưng một phiên máy tính để bàn đầy đủ có thể tiêu tốn vài megs. Đăng xuất bất kỳ phiên hoạt động nào bạn có và chạy kết nối của bạn từ bảng điều khiển hoặc thông qua SSH.

Tuy nhiên, tôi không nghĩ đó hoàn toàn là vấn đề về trí nhớ. Nếu bạn tốt hơn 50% I / O, hãy chờ trong thời gian dài (và bạn đang đăng các số liệu chạm vào thập niên 70), kết quả là nút cổ chai sẽ phá vỡ phần còn lại của hệ thống. Giống như Darth Vader nghiền nát cổ.

Có bao nhiêu chủ đề tuôn ra bạn được cấu hình cho? Sử dụng

cat /proc/sys/vm/nr_pdflush_threads

để tìm hiểu và

echo "vm.nr_pdflush_threads = 1" >> /etc/sysctl.conf

để đặt nó thành một chủ đề duy nhất. Lưu ý rằng lệnh cuối cùng làm cho nó tải vĩnh viễn khi khởi động lại. Nhìn thấy 1 hoặc 2 trong đó không có gì bất thường. Nếu bạn có một số lõi hoặc nhiều công suất trục chính / bus cho I / O, bạn sẽ muốn tăng các mức này (một chút). Nhiều luồng xả hơn = hoạt động I / O nhiều hơn, nhưng cũng tốn nhiều thời gian CPU hơn trong chờ I / O.

Là giá trị mặc định, hoặc bạn đã vượt qua nó? Nếu bạn đã va vào nó, bạn đã xem xét giảm số lượng để giảm áp lực lên I / O op chưa? Hoặc bạn có một số lượng lớn các trục và kênh để làm việc, trong trường hợp đó, bạn đã xem xét việc tăng số lượng các luồng xả?

PS bạn muốn đặt swappiness thành các giá trị thấp hơn, chứ không phải các giá trị cao hơn, để ngăn chặn trao đổi. Giá trị cao nhất = 100 = hoán đổi như điên khi cảm thấy đúng, giá trị thấp nhất = 0 = cố gắng không trao đổi gì cả.

Nếu bạn nhìn vào các khối được đọc trong mỗi giây (bi) trong IO, nó sẽ làm giảm hoạt động hoán đổi theo nhiều bậc độ lớn. Tôi không nghĩ rằng việc sử dụng trao đổi là những gì gây ra sự cố cho đĩa của bạn, tôi nghĩ rằng bạn có một cái gì đó đang chạy trên hộp chỉ đơn giản là gây ra nhiều hoạt động của đĩa (đọc).

Tôi sẽ điều tra các ứng dụng đang chạy và xem bạn có thể tìm ra thủ phạm không.

Xem nếu liên kết này trả lời một số câu hỏi của bạn. Tôi thường xuyên thấy Linux phân trang (không tráo đổi) bộ nhớ từ lâu trước khi sử dụng 60%. Đây là một phần dự kiến ​​của điều chỉnh bộ nhớ của nó:

http://www.sheepguendingllama.com/?p=2252

Nhưng việc bạn thiếu bộ đệm / bộ đệm làm tôi lo lắng. Điều đó có vẻ rất bất thường. Vì vậy, tôi nghĩ rằng một cái gì đó nhiều hơn là không ổn.

Bạn có thể thử vô hiệu hóa trao đổi hoàn toàn?

swapoff /dev/hdb2

hoặc một số như vậy - ít nhất điều đó sẽ xác nhận rằng đó là sự tráo đổi đó là vấn đề của bạn chứ không phải vấn đề khác.

Theo mặc định, swappiness được đặt là 60.

mèo / Proc / sys / vm / swappiness 60

Swappiness là một kernel được sử dụng để điều chỉnh bao nhiêu kernel thích trao đổi trên RAM; swappiness cao có nghĩa là kernel sẽ trao đổi rất nhiều, và swappiness thấp có nghĩa là kernel sẽ cố gắng không sử dụng không gian trao đổi.

Chúng tôi có thể thay đổi chỉnh sửa này giá trị của vm.swappiness trong /etc/sysctl.conf .

Bạn có thể hướng dẫn cài đặt swappinness của kernel, bạn có thể thấy tại/proc/sys/vm/swappiness hoặc ban hành lệnh sysctl vm.swappiness. Swappiness là một thiết lập kernel xác định mức độ hoán đổi được sử dụng.

Bằng cách thiết lập, sudo sysctl vm.swappiness=0bạn đang vô hiệu hóa phân vùng trao đổi. Để thực hiện thay đổi này vĩnh viễn bạn có thể thêm / sửa đổi vm.swappiness=0trong /etc/sysctl.conf. Bạn nên xem đâu là giá trị tốt cho bạn. Cá nhân tôi đã cấu hình nó vm.swappiness=10, là 60 giá trị mặc định.

Một điều khác mà bạn có thể muốn xem xét là hàng đợi chạy kernel và các quá trình không thể bị gián đoạn (các cột 'r' và 'b' trong vmstat) là một chỉ báo cho thấy hệ thống đã bão hòa. Mặt khác, đừng nhầm lẫn độ bão hòa với việc sử dụng ... vấn đề thực sự có thể là một ngăn xếp quá trình bị bỏ đói so với hạt nhân bão hòa :-(

Bạn cũng có thể chạy 'pmap -x [PID]' để có thêm chi tiết bộ nhớ từ một số quy trình tiêu thụ nhiều hơn. Chúc các bạn may mắn!

Matt

Có thể bạn có các quy trình tồn tại trong thời gian ngắn sử dụng nhiều bộ nhớ, sau đó thoát ra trước khi bạn có cơ hội chú ý đến chúng.

Điều này sẽ phù hợp với những gì bạn đang nhìn thấy.

Bạn đã điều tra các vấn đề với bộ đệm inode? slabtopít nhất nên cung cấp cho bạn một điểm khởi đầu nếu bạn đang gặp phải một cái gì đó như thế này.

Mặc dù hệ thống của bạn là 64 bit nhưng hệ thống có thể không thực sự giải quyết được tất cả bộ nhớ khả dụng. Đây là một giới hạn chipset. Ví dụ, Mac mini thế hệ trước "hỗ trợ" 4GB ram nhưng chỉ có 3,3 GB thực sự có thể truy cập được.