เซิร์ฟเวอร์ Linux ใช้หน่วยความจำเพียง 60% จากนั้นจึงทำการสลับ

ฉันมีเซิร์ฟเวอร์ 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 ดูเหมือนจะสนับสนุนทฤษฎีที่ว่า swap คือสิ่งที่ทำให้ระบบหยุดชะงัก:

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 บิต

Update2:ตามที่ฉันกล่าวถึงในคำถามเดิมฉันได้ลอง swappiness เพื่อทุกประเภทของค่ารวมถึง 0 ผลลัพธ์จะเหมือนกันเสมอโดยมีหน่วยความจำเหลืออยู่ประมาณ 1.6 GB

Update3:เพิ่มการส่งออกสูงสุดไปยังข้อมูลข้างต้น

ประสิทธิภาพของ Bacula นั้นขึ้นอยู่กับฐานข้อมูลสูง น่าจะเป็น postgresql ที่ฆ่าเซิร์ฟเวอร์ของคุณ ค่าเฉลี่ยการโหลดสูงและ% cpu ที่ใช้เวลามากในสถานะรออย่างชัดเจนแสดงให้เห็นว่ากำลังรอ Disk I / O ... และนั่นเป็นสิ่งที่ PostgreSQL กำลังทำอยู่ สำหรับทุกไฟล์ในชุดข้อมูลสำรองของคุณจะต้องทำอย่างน้อยคำสั่ง UPDATE ไม่ต้องกังวลกับการแลกเปลี่ยน

ทำการปรับแต่งการติดตั้ง PostgreSQL อาจให้แต่ละฐานข้อมูล (หรือแม้แต่ตาราง) ชุดดิสก์ / การโจมตีของตนเองเพื่อกระจาย I / O รอบ ๆ คุณสามารถบังคับให้ PostgreSQL ใช้การเขียนแบบอะซิงโครนัสหากยังไม่ได้ ... แม้ว่าจะเป็นฐานข้อมูลการซื้อขายที่สมบูรณ์สำหรับการเขียน เพิ่มพลังให้กับหน่วยความจำที่ใช้ร่วมกันของ PostgreSQL นั่นจะช่วยให้การอ่านฐานข้อมูลน้อยลงอย่างมาก หากคุณไม่เคยทำมันให้รัน VACCUM ANALYZE บนฐานข้อมูล Bacula และให้เครื่องมือเพิ่มประสิทธิภาพคิวรีทำงานได้

จนถึงจุดที่อ่อนแอที่สุดของ Bacula ก็คือการพึ่งพาฐานข้อมูล (และความสิ้นหวังของสมองบางส่วน ... ) ดำเนินการสำรองข้อมูลขนาดใหญ่ล่าสุดและแจ้งให้ทราบว่าต้องใช้เวลานานเท่าใด .. Bacula ชอบไฟล์ขนาดใหญ่ค่อนข้างน้อยไม่เช่นนั้นจะเป็นสุนัข

คุณเป็น I / O-bound ระบบของคุณเป็นแพชูชีพเล็ก ๆ น้อย ๆ ซัดเซในทะเลที่เต็มไปด้วยพายุของบัฟเฟอร์เพจ / แคช / VM ที่สูง 100 ฟุต

ว้าว. เพียงแค่ ... ว้าว คุณกำลังเคลื่อนที่ประมาณ 100Mbyte / วินาทีจาก I / O ของคุณคุณจะผ่านช่วงเวลา CPU 50% ในการรอ I / O และคุณมี RAM 4GB ความกดดันของ VM บนเซิร์ฟเวอร์นี้ต้องมหาศาล ภายใต้สถานการณ์ "ปกติ" เป็นระบบเริ่ม buffer / แคชใด ๆ ฟรี RAM ที่คุณมีเป็นไปได้กินมีชีวิตอยู่ในเวลาน้อยกว่า 40 วินาที

มันจะเป็นไปได้ที่จะโพสต์การตั้งค่าจาก/proc/sys/vm? สิ่งนี้จะให้ข้อมูลเชิงลึกเกี่ยวกับสิ่งที่เคอร์เนลของคุณคิดว่าเป็น "ปกติ"

postmasterกระบวนการเหล่านั้นยังระบุว่าคุณกำลังใช้งาน PostgreSQL ในพื้นหลัง เป็นเรื่องปกติสำหรับการตั้งค่าของคุณหรือไม่ PostgreSQL ในการกำหนดค่าเริ่มต้นจะใช้ RAM น้อยมาก แต่เมื่อปรับค่าความเร็วใหม่แล้วมันสามารถเคี้ยวได้ 25% -40% ของ RAM ที่มีอยู่อย่างรวดเร็ว ดังนั้นฉันสามารถคาดเดาได้เพียงกำหนดจำนวนของพวกเขาในผลลัพธ์คุณกำลังเรียกใช้ฐานข้อมูลการผลิตบางประเภทในขณะที่คุณกำลังสำรองข้อมูล มันไม่ได้เป็นลางดี คุณช่วยให้ข้อมูลเพิ่มเติมเกี่ยวกับสาเหตุที่ทำให้มันทำงานได้หรือไม่? ขนาดของพารามิเตอร์หน่วยความจำที่แชร์สำหรับทั้งหมดคืออะไรpostmasterกระบวนการ? เป็นไปได้ไหมที่จะปิดบริการหรือกำหนดค่าฐานข้อมูลใหม่ชั่วคราวเพื่อใช้การเชื่อมต่อ / บัฟเฟอร์ที่น้อยลงในขณะที่กำลังสำรองข้อมูล ซึ่งจะช่วยลดแรงกดดันบางส่วนจาก I / O ที่ทำให้เครียดและ RAM ฟรี โปรดทราบว่าแต่ละ postmasterกระบวนการใช้ RAM สูงกว่าสิ่งที่ฐานข้อมูลใช้สำหรับการแคชภายใน ดังนั้นเมื่อคุณทำการปรับเปลี่ยนการตั้งค่าหน่วยความจำโปรดระวังว่า "การแบ่งปัน" และการ "ดำเนินการต่อ" เป็นอย่างไร

หากคุณใช้ PostgreSQL เป็นส่วนหนึ่งของกระบวนการสำรองข้อมูลของคุณให้ลองปรับแต่งใหม่เพื่อยอมรับจำนวนการเชื่อมต่อที่น้อยที่สุดและตรวจสอบให้แน่ใจว่าได้ลดขนาดพารามิเตอร์ต่อกระบวนการลงไปเป็นสิ่งที่สมเหตุสมผล (เพียงไม่กี่เมกะไบต์) ข้อเสียของสิ่งนี้คือPostgreSQL จะรั่วไหลไปยังดิสก์ถ้ามันไม่สามารถทำงานกับชุดข้อมูลใน RAM ได้อย่างที่ต้องการดังนั้นมันจะเพิ่มดิสก์ I / O ของคุณจริง ๆดังนั้นควรปรับแต่งอย่างระมัดระวัง

X11 ในและของตัวเองไม่ได้ใช้หน่วยความจำมาก แต่เซสชันเดสก์ทอปเต็มสามารถใช้หลายเมกะ ออกจากระบบเซสชันที่ใช้งานอยู่ที่คุณมีและเรียกใช้การเชื่อมต่อจากคอนโซลหรือผ่าน SSH

ถึงกระนั้นฉันไม่คิดว่ามันเป็นปัญหาความจำทั้งหมด หากคุณดีกว่า 50% I / O รอเป็นเวลานาน (และคุณกำลังโพสต์ตัวเลขที่สัมผัสยุค 70) คอขวดที่ได้จะทำให้ระบบที่เหลือหมดในที่สุด เหมือนDarth Vaderบีบคอ

วิธีการหลายหัวข้อล้างคุณกำลังกำหนดค่าสำหรับ? ใช้

cat /proc/sys/vm/nr_pdflush_threads

เพื่อค้นหาและ

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

เพื่อตั้งเป็นเธรดเดี่ยว โปรดทราบว่าคำสั่งสุดท้ายทำให้มันโหลดอย่างถาวรเมื่อรีบูต เห็น 1 หรือ 2 ในนั้นไม่ผิดปกติ หากคุณมีแกนหลายแกนหรือความจุแกนหมุน / บัสจำนวนมากสำหรับ I / O คุณจะต้องชนสิ่งเหล่านี้ (เล็กน้อย) เพิ่มเติม flush threads = กิจกรรม I / O มากขึ้น แต่ยังใช้เวลา CPU มากขึ้นในการรอ I / O

มันเป็นค่าเริ่มต้นหรือคุณเคยเจอหรือเปล่า? หากคุณชนมันคุณได้พิจารณาลดจำนวนเพื่อลดจำนวนความกดดันของ I / O ops หรือไม่? หรือคุณมีแกนหมุนและแชนเนลจำนวนมากที่จะทำงานด้วยในกรณีนี้คุณได้พิจารณาเพิ่มจำนวนฟลัชเธรดหรือไม่

PS คุณต้องการตั้งค่า swappiness ให้ต่ำกว่าไม่ใช่ค่าที่สูงกว่าเพื่อป้องกันการสลับออก ค่าสูงสุด = 100 = สลับอย่างบ้าคลั่งเมื่อรู้สึกถูกที่สุดค่าต่ำสุด = 0 = พยายามอย่าสลับเลย

หากคุณดูบล็อกที่อ่านต่อวินาที (bi) ภายใต้ IO มันจะทำให้กิจกรรมการแลกเปลี่ยนเป็นไปด้วยคำสั่งหลายขนาด ฉันไม่คิดว่าการใช้ swap เป็นสิ่งที่ทำให้ดิสก์ของคุณสั่นสะเทือนฉันคิดว่าคุณมีบางอย่างที่ทำงานอยู่ในกล่องที่ทำให้เกิดกิจกรรมบนดิสก์มากมาย (อ่าน)

ฉันจะตรวจสอบแอปพลิเคชันที่ทำงานอยู่และดูว่าคุณสามารถหาผู้กระทำผิดได้หรือไม่

ดูว่าลิงค์นี้ตอบคำถามของคุณไหม ฉันเห็นหน้า Linux (ไม่สลับ) หน่วยความจำนานก่อนการใช้ประโยชน์ 60% นี่เป็นส่วนที่คาดหวังของการปรับแต่งหน่วยความจำ:

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

แต่การขาดบัฟเฟอร์ / แคชของคุณทำให้ฉันเป็นกังวล มันดูแปลกมาก ดังนั้นฉันคิดว่ามีอะไรผิดปกติอีก

คุณลองปิดการแลกเปลี่ยนได้หรือไม่?

swapoff /dev/hdb2

หรืออย่างน้อยก็จะตรวจสอบว่ามันแลกเปลี่ยนที่เป็นปัญหาของคุณและไม่ใช่อย่างอื่น

โดยค่าเริ่มต้น swappiness ถูกตั้งค่าเป็น 60

cat / proc / sys / vm / swappiness 60

Swappiness เป็นเคอร์เนลที่ใช้ในการปรับแต่งเท่าไหร่เคอร์เนลโปรดปรานแลกเปลี่ยนมากกว่า RAM; ความว่องไวสูงหมายถึงเคอร์เนลจะสลับเป็นจำนวนมากและความว่องไวต่ำหมายถึงเคอร์เนลจะพยายามไม่ใช้พื้นที่สว็อป

เราสามารถเปลี่ยนแปลงแก้ไขค่าของvm.swappinessใน/etc/sysctl.conf

คุณ manualy สามารถตั้งค่าswappinnessของเคอร์เนลชคุณสามารถดูได้หรือการออกคำสั่ง/proc/sys/vm/swappiness sysctl vm.swappinessswappiness คือการตั้งค่าเคอร์เนลที่กำหนดจำนวน swap ที่ใช้

โดยการตั้งค่าsudo sysctl vm.swappiness=0คุณจะปิดการใช้งาน swap partition อย่างมีประสิทธิภาพ เพื่อให้การเปลี่ยนแปลงนี้อย่างถาวรคุณสามารถเพิ่ม / แก้ไขในvm.swappiness=0 /etc/sysctl.confคุณควรเห็นว่าอะไรคือสิ่งที่คุ้มค่าสำหรับคุณ ฉันได้กำหนดค่าส่วนตัวเป็นการvm.swappiness=1060 ค่าเริ่มต้น

อีกสิ่งหนึ่งที่คุณอาจต้องการดูก็คือเคอร์เนลที่รันคิวและกระบวนการที่ไม่สามารถแตกได้ (คอลัมน์ 'r' และ 'b' ใน vmstat) เป็นตัวบ่งชี้ว่าระบบอิ่มตัวตลอดเวลา ในหมายเหตุด้านอย่าสับสนความอิ่มตัวกับการใช้ ... ปัญหาที่แท้จริงอาจเป็นกระบวนการที่หิวโหยเมื่อเทียบกับเคอร์เนลอิ่มตัว :-(

คุณสามารถเรียกใช้ 'pmap -x [PID]' เพื่อรับรายละเอียดหน่วยความจำเพิ่มเติมจากกระบวนการที่กินเวลามากขึ้น ฉันขอให้คุณโชคดี!

ด้าน

บางทีคุณอาจมีกระบวนการระยะสั้นที่ใช้หน่วยความจำจำนวนมากจากนั้นออกก่อนที่คุณจะมีโอกาสสังเกตเห็น

สิ่งนี้จะสอดคล้องกับสิ่งที่คุณเห็นอยู่แล้ว

คุณตรวจสอบปัญหาเกี่ยวกับแคชไอโหนดหรือไม่? slabtopอย่างน้อยควรให้จุดเริ่มต้นแก่คุณหากคุณพบปัญหาเช่นนี้

ในขณะที่ระบบของคุณเป็น 64 บิตระบบอาจไม่สามารถระบุหน่วยความจำที่มีอยู่ทั้งหมดได้ นี่เป็นข้อ จำกัด ของชิปเซ็ต ตัวอย่างเช่น Mac mini รุ่นก่อนหน้า "รองรับ" 4GB of ram แต่เพียง 3.3GB เท่านั้นที่สามารถจัดการได้