Linux sunucusu belleğin sadece% 60'ını kullanıyor, sonra değiştiriyor

Bacula yedekleme sistemimizi çalıştıran bir Linux sunucum var. Makine çılgın gibi taşlıyor çünkü takas etmek için ağır gidiyor. Sorun şu ki, fiziksel belleğinin sadece% 60'ını kullanıyor!

İşte çıktı 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

ve bazı örnek çıktı 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

Dahası, CPU zamanına göre sıralanmış en iyi çıktı, takasın sistemde aşağı inen şey olduğu teorisini destekliyor gibi görünüyor:

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

Sanal bellek görüntü boyutuna göre aynı şekilde sıralanmıştır:

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Çekirdek parametresini hem yüksek hem de düşük değerlere ayarlamayı denedim , ancak hiçbir şey burada davranışı değiştirmek için görünmüyor. Neler olup bittiğini anlayabiliyorum. Buna neyin sebep olduğunu nasıl öğrenebilirim?

Güncelleme: Sistem tamamen 64 bit bir sistemdir, bu nedenle 32 bitlik sorunlar nedeniyle bellek sınırlamaları söz konusu olmamalıdır.

Güncelleme2: Orijinal soruda bahsettiğim gibi, 0'ı da içeren her türlü değere swappiness ayarlamayı denedim. Sonuç her zaman aynı, yaklaşık 1,6 GB bellek kullanılmıyor.

Güncelleme3: Yukarıdaki bilgilere üst çıktı eklendi.

Bacula performansı veritabanına oldukça bağlıdır. Muhtemelen, sunucunuzu öldüren postgresql. Yüksek yük ortalaması ve bekleme durumunda harcanan işlemci zamanının oldukça büyük bir yüzdesi Disk I / O'yu beklediğini açıkça gösteriyor ... Ve PostgreSQL bunu yapıyor. Yedeklemenizdeki her dosya için en az bir UPDATE deyimi yapıyor. Takas hakkında endişelenme.

PostgreSQL kurulumunu ayarlayın. G / Ç'yi yaymak için tek tek veritabanlarına (hatta tablolara) kendi disklerini / raid setlerini verin. PostgreSQL'i henüz değilse aynsenkron yazmaları kullanmaya zorlayabilirsiniz ... Her ne kadar bu yazma performansı için ticaret veritabanı bütünlüğü. PostgreSQL'in kullanabileceği paylaşılan hafızadan kurtulun. Bu, veritabanındaki okunanların en azından bir kısmını hafifletir. Daha önce yapmadıysanız, Bacula veritabanında da VACCUM ANALYZE komutunu çalıştırın.

Bacula'nın en zayıf noktası veritabanı bağımlılıkları (ve bazılarının beyin ölümü ...) Son zamanlarda büyük bir yedeklemenin temizliğini yapın ve birkaç düzine milyon sorgu çalıştırmanın ne kadar sürdüğünü (saatlerce) fark edin. .. Bacula nispeten az sayıda büyük dosyayı sever, aksi takdirde bir köpektir.

I / O bağlısınız. Sisteminiz, 100 feet boyunda bir tampon / önbellek / VM çağrı şişmesi fırtınalı denizinde dövülmüş küçük bir cankurtaran salıdır.

Vay. Sadece ... vay. G / Ç'nizden yaklaşık 100Mbyte / sn ilerliyorsunuz, G / Ç beklemesinde% 50 CPU zamanının çok ötesindesiniz ve 4 Gb RAM'iniz var. Bu sunucunun VM'sindeki geri basınç muazzam olmalıdır. "Normal" koşullar altında, sistem arabelleğe almaya / önbelleğe almaya başladığında, sahip olduğunuz boş RAM 40 saniyeden daha kısa sürede canlı olarak yenir .

Ayarları şuradan göndermek mümkün müdür /proc/sys/vm? Bu, çekirdeğinizin "normal" olduğunu düşündüğü konusunda bir fikir verecektir.

Bu postmasterişlemler ayrıca PostgreSQL'i arka planda çalıştırdığınızı gösterir. Kurulumunuz için bu normal mi? Varsayılan bir yapılandırmada PostgreSQL çok az RAM kullanacaktır, ancak hız için yeniden ayarlandıktan sonra, mevcut RAM'inizin% 25-40'ını hızlı bir şekilde çiğneyebilir. Bu yüzden çıktıdaki sayıları göz önüne alındığında, yedekleri çalıştırırken bir tür üretim veritabanı çalıştırdığınızı tahmin edebiliyorum. Bu iyi bir şey değil. Neden çalıştığına dair biraz daha bilgi verebilir misiniz? Herkes için paylaşılan bellek parametresinin boyutu nedirpostmastersüreçler? Yedekleme çalışırken hizmeti kapatmak veya veritabanını daha az bağlanma / arabellek kullanacak şekilde geçici olarak yeniden yapılandırmak mümkün mü? Bu, zaten gerilmiş I / O ve boş RAM'den bazı basınçların alınmasına yardımcı olacaktır. Her postmasterişlemin veritabanının dahili önbellekleme için kullandığı değerin üzerinde RAM kullandığını unutmayın. Bu nedenle bellek ayarlarında ayarlamalar yaparken, hangilerinin "paylaşılan" hangilerinin "işlem başına" olduğuna dikkat edin .

PostgreSQL'i yedekleme işleminizin bir parçası olarak kullanıyorsanız, yalnızca minimum bağlantı sayısını kabul etmek için yeniden ayarlamayı deneyin ve işlem başına parametrelerinizi makul bir şeye indirdiğinizden emin olun (her biri sadece birkaç meg). Bunun dezavantajı, PostgreSQL'in istediği gibi RAM'deki veri kümesiyle çalışamaması durumunda diske dökülmesidir, böylece disk I / O'nuzu artıracaktır , bu yüzden dikkatlice ayarlayın.

X11'in kendisi çok fazla bellek almıyor, ancak tam bir masaüstü oturumu birkaç megabayt tüketebilir. Sahip olduğunuz tüm aktif oturumları kapatın ve bağlantınızı konsoldan veya SSH üzerinden çalıştırın.

Yine de, bunun tamamen bir hafıza sorunu olduğunu düşünmüyorum. % 50 G / Ç'den daha iyiyseniz uzun süre bekleyin (ve 70'lere dokunan rakamlar gönderiyorsunuz), sonuçta ortaya çıkan darboğaz sonunda sistemin geri kalanını ezecektir. Darth Vader gibi boyunları eziyor.

Kaç tane yıkama ipliği için yapılandırıldınız? kullanım

cat /proc/sys/vm/nr_pdflush_threads

bulmak ve

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

tek bir iş parçacığına ayarlamak için. Son komutun yeniden başlatma sonrasında kalıcı olarak yüklenmesini sağladığını unutmayın. İçeride 1 veya 2 görmek olağandışı değil. G / Ç için birkaç çekirdek veya çok fazla mil / veri yolu kapasitesine sahipseniz, bunları (hafifçe) çarpmak isteyeceksiniz. Daha fazla yıkama dişi = daha fazla G / Ç etkinliği, aynı zamanda G / Ç beklemesinde daha fazla CPU zamanı harcanır.

Varsayılan değer mi, yoksa çarptınız mı? Eğer çarptıysanız, G / Ç işlemlerindeki baskı miktarını azaltmak için sayıyı azaltmayı düşündünüz mü? Veya birlikte çalışacak çok sayıda iğ ve kanalınız var mı, bu durumda sifon dişlerinin sayısını artırmayı düşündünüz mü?

PS, takas yapılmasını önlemek için daha yüksek değerlere değil, daha düşük değerlere swappiness ayarlamak istiyorsunuz. En yüksek değer = 100 = doğru geldiğinde deli gibi takas, en düşük değer = 0 = hiç takas etmemeye çalışın.

G / Ç altında saniyede (bi) okunan bloklara bakarsanız, takas etkinliğini birden çok büyüklük düzeyinde gösterir. Takas kullanımının diskinizin bozulmasına neden olduğunu düşünmüyorum, kutuda çalışan bir şey olduğunu düşünüyorum, bu da sadece disk etkinliğine (okumalara) neden oluyor.

Çalışan uygulamaları araştırır ve suçluyu bulabilecek misiniz diye görürüm.

Bu bağlantının bazı sorularınıza cevap verip vermediğine bakın. % 60 kullanımdan çok önce düzenli aralıklarla Linux disk belleği (takas değil) görüyorum. Bu, bellek ayarının beklenen bir parçasıdır:

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

Ancak arabellek / önbellek eksikliğiniz beni endişelendiriyor. Bu çok sıradışı görünüyor. Bu yüzden daha fazla bir şeyin yanlış olduğunu düşünüyorum.

Takas işlemini tamamen devre dışı bırakmayı deneyebilir misiniz?

swapoff /dev/hdb2

ya da en azından böyle bir şey başka bir şey değil, senin sorunun olduğunu değiştirdiğini doğrular.

Varsayılan olarak swappiness 60 olarak ayarlanmıştır.

kedi / proc / sys / vm / swappiness 60

Swappiness, çekirdeğin RAM üzerinden takas etmeyi ne kadar tercih ettiğini ayarlamak için kullanılan bir çekirdektir; yüksek swappiness, çekirdeğin çok fazla takas edeceği anlamına gelir ve düşük swappiness, çekirdeğin takas alanı kullanmamaya çalışacağı anlamına gelir.

Biz bunun değerini düzenleyerek değiştirebilirsiniz vm.swappiness içinde /etc/sysctl.conf .

Komutta görebileceğiniz /proc/sys/vm/swappinessveya komutu veren çekirdeğin swappinnessini manuel olarak ayarlayabilirsiniz sysctl vm.swappiness. Swappiness, swapın ne kadar kullanıldığını belirleyen bir çekirdek ayarıdır.

Ayarlayarak sudo sysctl vm.swappiness=0takas bölümünü etkin bir şekilde devre dışı bırakmış olursunuz. Eğer eklemek / değiştirmek bu değişikliği kalıcı hale getirmek için vm.swappiness=0de /etc/sysctl.conf. Sizin için neyin iyi bir değer olduğunu görmelisiniz. Şahsen vm.swappiness=1060 varsayılan değer olarak yapılandırılmış var .

Bakmak isteyebileceğiniz diğer bir şey, çekirdek çalıştırma kuyruğunuz ve kesintisiz işlemlerin (vmstat'taki 'r' ve 'b' sütunları) sistemin zaman zaman doygun olduğunun bir göstergesidir. Bir yan notta, doygunluğu kullanımla karıştırmayın ... asıl sorun doymuş çekirdeğe karşı açlıklı bir süreç yığını olabilir :-(

Daha fazla tüketen işlemlerden ek bellek ayrıntıları almak için 'pmap -x [PID]' çalıştırabilirsiniz. Sana şans diliyorum!

Mat

Belki çok fazla bellek kullanan kısa ömürlü süreçleriniz var, sonra onları fark etme şansınız olmadan çıkın.

Bu zaten gördüklerinizle tutarlı olacaktır.

İnode önbelleği ile ilgili sorunları araştırdınız mı? slabtopböyle bir şeyle karşılaşıyorsanız en azından size bir başlangıç ​​noktası vermelidir.

Sisteminiz 64 bit olsa da, sistem kullanılabilir belleğin tamamını ele alamayabilir. Bu bir yonga seti sınırlamasıdır. Örneğin, önceki nesil Mac mini, 4GB ram'ı "destekliyor", ancak yalnızca 3.3GB aslında adreslenebilirdi.