สาเหตุของการแตกแฟรกเมนต์บนเซิร์ฟเวอร์“ ใหญ่” ที่มี xfs, 20 ดิสก์และ Ceph

18

ข้อมูลเชิงลึกจากผู้ที่มีประสบการณ์เล็กน้อยในระบบ linux IO จะเป็นประโยชน์ นี่คือเรื่องราวของฉัน:

เมื่อเร็ว ๆ นี้นำคลัสเตอร์ Dell PowerEdge rx720xds หกตัวมาให้บริการไฟล์ผ่าน Ceph เครื่องเหล่านี้มี 24 คอร์ในสองซ็อกเก็ตที่มีสองโซน numa และ 70 กิกะไบต์หน่วยความจำคี่ ดิสก์ถูกฟอร์แมตเป็นการบุกค้นของดิสก์หนึ่งแผ่น (เราไม่เห็นวิธีเปิดเผยโดยตรง) เครือข่ายให้บริการโดย mellanox infiniband IP ผ่าน IB (แพ็คเก็ต IP กลายเป็น IB ในเคอร์เนลที่ดินไม่ใช่ฮาร์ดแวร์)

เราได้ติดตั้งไดรฟ์ SAS แต่ละตัวไว้ดังนี้:

# cat /proc/mounts | grep osd
/dev/sdm1 /var/lib/ceph/osd/ceph-90 xfs rw,noatime,attr2,inode64,noquota 0 0
/dev/sdj1 /var/lib/ceph/osd/ceph-87 xfs rw,noatime,attr2,inode64,noquota 0 0
/dev/sdu1 /var/lib/ceph/osd/ceph-99 xfs rw,noatime,attr2,inode64,noquota 0 0
/dev/sdd1 /var/lib/ceph/osd/ceph-82 xfs rw,noatime,attr2,inode64,noquota 0 0
/dev/sdk1 /var/lib/ceph/osd/ceph-88 xfs rw,noatime,attr2,inode64,noquota 0 0
/dev/sdl1 /var/lib/ceph/osd/ceph-89 xfs rw,noatime,attr2,inode64,noquota 0 0
/dev/sdh1 /var/lib/ceph/osd/ceph-86 xfs rw,noatime,attr2,inode64,noquota 0 0
/dev/sdo1 /var/lib/ceph/osd/ceph-97 xfs rw,noatime,attr2,inode64,noquota 0 0
/dev/sdc1 /var/lib/ceph/osd/ceph-81 xfs rw,noatime,attr2,inode64,noquota 0 0
/dev/sdb1 /var/lib/ceph/osd/ceph-80 xfs rw,noatime,attr2,inode64,noquota 0 0
/dev/sds1 /var/lib/ceph/osd/ceph-98 xfs rw,noatime,attr2,inode64,noquota 0 0
/dev/sdn1 /var/lib/ceph/osd/ceph-91 xfs rw,noatime,attr2,inode64,noquota 0 0
/dev/sde1 /var/lib/ceph/osd/ceph-83 xfs rw,noatime,attr2,inode64,noquota 0 0
/dev/sdq1 /var/lib/ceph/osd/ceph-93 xfs rw,noatime,attr2,inode64,noquota 0 0
/dev/sdg1 /var/lib/ceph/osd/ceph-85 xfs rw,noatime,attr2,inode64,noquota 0 0
/dev/sdt1 /var/lib/ceph/osd/ceph-95 xfs rw,noatime,attr2,inode64,noquota 0 0
/dev/sdf1 /var/lib/ceph/osd/ceph-84 xfs rw,noatime,attr2,inode64,noquota 0 0
/dev/sdr1 /var/lib/ceph/osd/ceph-94 xfs rw,noatime,attr2,inode64,noquota 0 0
/dev/sdi1 /var/lib/ceph/osd/ceph-96 xfs rw,noatime,attr2,inode64,noquota 0 0
/dev/sdp1 /var/lib/ceph/osd/ceph-92 xfs rw,noatime,attr2,inode64,noquota 0 0

IO ที่ผ่านเครื่องเหล่านี้จะระเบิดที่ไม่กี่ร้อย MB / s แต่เวลาส่วนใหญ่นั้นค่อนข้างไม่ได้ใช้งานโดยมี 'pokes' จำนวนน้อย:

# iostat -x -m
Linux 3.10.0-123.el7.x86_64 (xxx)   07/11/14    _x86_64_    (24 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
       1.82    0.00    1.05    0.11    0.00   97.02
Device:         rrqm/s   wrqm/s     r/s     w/s    rMB/s    wMB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0.00     0.11    0.25    0.23     0.00     0.00    27.00     0.00    2.07    3.84    0.12   0.61   0.03
sdb               0.02     0.57    3.49    2.28     0.08     0.14    77.18     0.01    2.27    2.99    1.18   1.75   1.01
sdd               0.03     0.65    3.93    3.39     0.10     0.16    70.39     0.01    1.97    2.99    0.79   1.57   1.15
sdc               0.03     0.60    3.76    2.86     0.09     0.13    65.57     0.01    2.10    3.02    0.88   1.68   1.11
sdf               0.03     0.63    4.19    2.96     0.10     0.15    73.51     0.02    2.16    3.03    0.94   1.73   1.24
sdg               0.03     0.62    3.93    3.01     0.09     0.15    70.44     0.01    2.06    3.01    0.81   1.66   1.15
sde               0.03     0.56    4.35    2.61     0.10     0.14    69.53     0.02    2.26    3.00    1.02   1.82   1.26
sdj               0.02     0.73    3.67    4.74     0.10     0.37   116.06     0.02    1.84    3.01    0.93   1.31   1.10
sdh               0.03     0.62    4.31    3.04     0.10     0.15    67.83     0.02    2.15    3.04    0.89   1.75   1.29
sdi               0.02     0.59    3.82    2.47     0.09     0.13    74.35     0.01    2.20    2.96    1.03   1.76   1.10
sdl               0.03     0.59    4.75    2.46     0.11     0.14    70.19     0.02    2.33    3.02    1.00   1.93   1.39
sdk               0.02     0.57    3.66    2.41     0.09     0.13    73.57     0.01    2.20    3.00    0.97   1.76   1.07
sdm               0.03     0.66    4.03    3.17     0.09     0.14    66.13     0.01    2.02    3.00    0.78   1.64   1.18
sdn               0.03     0.62    4.70    3.00     0.11     0.16    71.63     0.02    2.25    3.01    1.05   1.79   1.38
sdo               0.02     0.62    3.75    2.48     0.10     0.13    76.01     0.01    2.16    2.94    0.99   1.70   1.06
sdp               0.03     0.62    5.03    2.50     0.11     0.15    68.65     0.02    2.39    3.08    0.99   1.99   1.50
sdq               0.03     0.53    4.46    2.08     0.09     0.12    67.74     0.02    2.42    3.04    1.09   2.01   1.32
sdr               0.03     0.57    4.21    2.31     0.09     0.14    72.05     0.02    2.35    3.00    1.16   1.89   1.23
sdt               0.03     0.66    4.78    5.13     0.10     0.20    61.78     0.02    1.90    3.10    0.79   1.49   1.47
sdu               0.03     0.55    3.93    2.42     0.09     0.13    70.77     0.01    2.17    2.97    0.85   1.79   1.14
sds               0.03     0.60    4.11    2.70     0.10     0.15    74.77     0.02    2.25    3.01    1.10   1.76   1.20
sdw               1.53     0.00    0.23   38.90     0.00     1.66    87.01     0.01    0.22    0.11    0.22   0.05   0.20
sdv               0.88     0.00    0.16   28.75     0.00     1.19    84.55     0.01    0.24    0.10    0.24   0.05   0.14
dm-0              0.00     0.00    0.00    0.00     0.00     0.00     8.00     0.00    1.84    1.84    0.00   1.15   0.00
dm-1              0.00     0.00    0.23    0.29     0.00     0.00    23.78     0.00    1.87    4.06    0.12   0.55   0.03
dm-2              0.00     0.00    0.01    0.00     0.00     0.00     8.00     0.00    0.47    0.47    0.00   0.45   0.00

ปัญหา:

หลังจากผ่านไปประมาณ 48 ชั่วโมงต่อมาหน้าต่อเนื่องนั้นมีการแยกส่วนเพื่อให้การจัดสรร Magniutde สี่ (16 หน้า, 65536 ไบต์) เริ่มล้มเหลวและเราเริ่มทิ้งแพ็กเก็ต (เนื่องจาก kalloc ล้มเหลวเมื่อโตขึ้น SLAB)

นี่คือสิ่งที่เซิร์ฟเวอร์ "ดีต่อสุขภาพ" ดูเหมือนว่า:

# cat /sys/kernel/debug/extfrag/unusable_index
Node 0, zone      DMA 0.000 0.000 0.000 0.001 0.003 0.007 0.015 0.031 0.031 0.096 0.225 
Node 0, zone    DMA32 0.000 0.009 0.015 0.296 0.733 0.996 0.997 0.998 0.998 1.000 1.000 
Node 0, zone   Normal 0.000 0.000 0.019 0.212 0.454 0.667 0.804 0.903 0.986 1.000 1.000 
Node 1, zone   Normal 0.000 0.027 0.040 0.044 0.071 0.270 0.506 0.772 1.000 1.000 1.000

เมื่อการแตกแฟรกเมนต์แย่ลงมากดูเหมือนว่าระบบจะเริ่มหมุนในพื้นที่เคอร์เนลและทุกอย่างก็แยกกัน ความผิดปกติอย่างหนึ่งในความล้มเหลวนี้คือ xfsaild ดูเหมือนจะใช้ CPU จำนวนมากและติดอยู่ในสถานะสลีปที่ไม่สามารถขัดจังหวะได้ ฉันไม่ต้องการที่จะข้ามไปสู่ข้อสรุปใด ๆ ที่มีความแปลกในระหว่างความล้มเหลวของระบบทั้งหมดแม้ว่า

วิธีแก้ปัญหาป่านนี้

เพื่อให้มั่นใจว่าการจัดสรรเหล่านี้จะไม่ล้มเหลวแม้จะอยู่ภายใต้การกระจายตัวของข้อมูลฉันได้ตั้งค่า:

vm.min_free_kbytes = 16777216

หลังจากเห็น blkdev_requests ในแคช SLAB หลายล้านรายการฉันพยายามลดหน้าสกปรกผ่าน:

vm.dirty_ratio = 1
vm.dirty_background_ratio = 1
vm.min_slab_ratio = 1
vm.zone_reclaim_mode = 3

อาจมีการเปลี่ยนแปลงตัวแปรมากเกินไปในคราวเดียว แต่ในกรณีที่ inodes และ dentries ทำให้เกิดการแตกแฟรกเมนต์ฉันตัดสินใจที่จะทำให้พวกเขามีค่าน้อยที่สุด:

vm.vfs_cache_pressure = 10000

และสิ่งนี้ดูเหมือนจะช่วย การกระจายตัวยังคงอยู่ในระดับสูง แต่ปัญหาการ inode และ dentry ที่ลดลงทำให้ฉันสังเกตเห็นบางสิ่งแปลก ๆ ที่ทำให้ฉัน ...

คำถามของฉัน:

ทำไมฉันจึงมี blkdev_requests จำนวนมาก (ที่แอ็คทีฟไม่น้อยกว่า) ที่เพิ่งหายไปเมื่อฉันวางแคช

นี่คือสิ่งที่ฉันหมายถึง:

# slabtop -o -s c | head -20
 Active / Total Objects (% used)    : 19362505 / 19431176 (99.6%)
 Active / Total Slabs (% used)      : 452161 / 452161 (100.0%)
 Active / Total Caches (% used)     : 72 / 100 (72.0%)
 Active / Total Size (% used)       : 5897855.81K / 5925572.61K (99.5%)
 Minimum / Average / Maximum Object : 0.01K / 0.30K / 15.69K

  OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME                   
2565024 2565017  99%    1.00K  80157       32   2565024K xfs_inode              
3295194 3295194 100%    0.38K  78457       42   1255312K blkdev_requests        
3428838 3399527  99%    0.19K  81639       42    653112K dentry                 
5681088 5680492  99%    0.06K  88767       64    355068K kmalloc-64             
2901366 2897861  99%    0.10K  74394       39    297576K buffer_head            
 34148  34111  99%    8.00K   8537        4    273184K kmalloc-8192           
334768 334711  99%    0.57K  11956       28    191296K radix_tree_node        
614959 614959 100%    0.15K  11603       53     92824K xfs_ili                
 21263  19538  91%    2.84K   1933       11     61856K task_struct            
 18720  18636  99%    2.00K   1170       16     37440K kmalloc-2048           
 32032  25326  79%    1.00K   1001       32     32032K kmalloc-1024           
 10234   9202  89%    1.88K    602       17     19264K TCP                    
 22152  19765  89%    0.81K    568       39     18176K task_xstate

# echo 2 > /proc/sys/vm/drop_caches                                                                                                                                                   :(
# slabtop -o -s c | head -20       
 Active / Total Objects (% used)    : 965742 / 2593182 (37.2%)
 Active / Total Slabs (% used)      : 69451 / 69451 (100.0%)
 Active / Total Caches (% used)     : 72 / 100 (72.0%)
 Active / Total Size (% used)       : 551271.96K / 855029.41K (64.5%)
 Minimum / Average / Maximum Object : 0.01K / 0.33K / 15.69K

  OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME                   
 34140  34115  99%    8.00K   8535        4    273120K kmalloc-8192           
143444  20166  14%    0.57K   5123       28     81968K radix_tree_node        
768729 224574  29%    0.10K  19711       39     78844K buffer_head            
 73280   8287  11%    1.00K   2290       32     73280K xfs_inode              
 21263  19529  91%    2.84K   1933       11     61856K task_struct            
686848  97798  14%    0.06K  10732       64     42928K kmalloc-64             
223902  41010  18%    0.19K   5331       42     42648K dentry                 
 32032  23282  72%    1.00K   1001       32     32032K kmalloc-1024           
 10234   9211  90%    1.88K    602       17     19264K TCP                    
 22152  19924  89%    0.81K    568       39     18176K task_xstate            
 69216  59714  86%    0.25K   2163       32     17304K kmalloc-256            
 98421  23541  23%    0.15K   1857       53     14856K xfs_ili                
  5600   2915  52%    2.00K    350       16     11200K kmalloc-2048

สิ่งนี้บอกกับฉันว่าการ build ของ blkdev_request นั้นไม่ได้เกี่ยวข้องกับหน้าสกปรกและยิ่งกว่านั้นวัตถุที่ใช้งานไม่ได้ทำงานจริง ๆ วัตถุเหล่านี้จะเป็นอิสระได้อย่างไรหากไม่ได้ใช้งานจริง เกิดขึ้นที่นี่คืออะไร?

สำหรับพื้นหลังบางส่วนนี่คือสิ่งที่ drop_caches กำลังทำ:

http://lxr.free-electrons.com/source/fs/drop_caches.c

ปรับปรุง:

คิดว่ามันอาจจะไม่ใช่ blkdev_requests แต่อาจเป็นรายการ xfs_buf ที่แสดงภายใต้ 'หัวเรื่อง' ไม่แน่ใจว่ามันทำงานอย่างไร:

/sys/kernel/slab # ls -l blkdev_requests(
lrwxrwxrwx 1 root root 0 Nov  7 23:18 blkdev_requests -> :t-0000384/

/sys/kernel/slab # ls -l | grep 384
lrwxrwxrwx 1 root root 0 Nov  7 23:18 blkdev_requests -> :t-0000384/
lrwxrwxrwx 1 root root 0 Nov  7 23:19 ip6_dst_cache -> :t-0000384/
drwxr-xr-x 2 root root 0 Nov  7 23:18 :t-0000384/
lrwxrwxrwx 1 root root 0 Nov  7 23:19 xfs_buf -> :t-0000384/

ฉันยังไม่รู้ว่าเหตุใดจึงถูกล้างข้อมูลโดย 'drop_slabs' หรือวิธีการแก้ไขสิ่งที่ทำให้เกิดการแตกแฟรกเมนต์นี้

คำถามโบนัส: วิธีที่ดีกว่าที่จะได้รับแหล่งที่มาของการกระจายตัวของนี้คืออะไร?

ถ้าคุณอ่านมาไกลขนาดนี้ขอขอบคุณสำหรับความสนใจของคุณ!

ข้อมูลที่ต้องการเพิ่มเติม:

ข้อมูลหน่วยความจำและ xfs: https://gist.github.com/christian-marie/f417cc3134544544a8d1

การจัดสรรหน้าล้มเหลว: https://gist.github.com/christian-marie/7bc845d2da7847534104

ติดตาม: ข้อมูลที่สมบูรณ์แบบและสิ่งที่เกี่ยวข้องกับการบดอัด

http://ponies.io/raw/compaction.png

รหัสการบีบอัดดูเหมือนว่าไม่มีประสิทธิภาพฮะเล็กน้อย? ฉัน Cobbled รหัสบางอย่างร่วมกันเพื่อพยายามที่จะทำซ้ำการล้มเหลว: https://gist.github.com/christian-marie/cde7e80c5edb889da541

ดูเหมือนว่าจะทำให้เกิดปัญหาอีกครั้ง

ฉันจะทราบด้วยว่าการติดตามเหตุการณ์บอกฉันว่ามีการเรียกคืนที่ล้มเหลวมากมายซ้ำแล้วซ้ำอีก:

<...>-322 [023] .... 19509.445609: mm_vmscan_direct_reclaim_end: nr_reclaimed=1

เอาต์พุต Vmstat นั้นเกี่ยวเนื่องกัน ในขณะที่ระบบอยู่ในสถานะโหลดสูงนี้การรวบรวมข้อมูลจะผ่านหลังคา (และส่วนใหญ่ล้มเหลว):

pgmigrate_success 38760827 pgmigrate_fail 350700119 compact_migrate_scanned 301784730 compact_free_scanned 204838172846 compact_isolated 18711615 compact_stall 270115 compact_fail 244488 compact_success 25212

มีบางสิ่งที่ผิดปกติกับการเรียกคืน / การบดอัด

ในขณะนี้ฉันกำลังมองหาวิธีลดการจัดสรรคำสั่งซื้อระดับสูงโดยเพิ่มการสนับสนุน SG ให้กับการตั้งค่า ipoib ของเรา ปัญหาจริงน่าจะเกี่ยวข้องกับ vmscan

สิ่งนี้น่าสนใจและอ้างอิงคำถามนี้: http://marc.info/?l=linux-mm&m=141607142529562&w=2

linux  linux-kernel  xfs  fragmentation  ceph 
— พิงกุ
แหล่งที่มา
2
เฮ้ใช่ !! เราไม่ได้รับคำถามที่ดีเหล่านี้มากมาย ฉันจะเห็นสิ่งที่เราสามารถทำได้
— ewwhite
1
คุณสามารถให้ผลลัพธ์/proc/buddyinfoและผลลัพธ์ของfree -m? ขอ blockdev จะอาจจะfreeแสดงเป็นบัฟเฟอร์ใน โอ้และ distro ที่คุณใช้ก็ดีเช่นกัน นอกจากนี้คุณมีpage allocation failureข้อความปรากฏในdmesg? ถ้าเป็นเช่นนั้นโปรดให้ผลลัพธ์รวมทั้งบริบทที่เกี่ยวข้อง
— Matthew Ife
1
นอกจากนี้คุณใช้mkfs.xfsบรรทัดคำสั่งเฉพาะหรือไม่ เปิดใช้งาน Hugepages แล้วหรือยัง
— ewwhite
นอกจากนี้ผลลัพธ์ของ/proc/meminfo
— Matthew Ife
พยายามปิดใช้งาน hugepages แบบโปร่งใสด้วยตัวเอง (ตั้งค่าเป็นไม่) ความล้มเหลวยังคงเกิดขึ้น ไม่ลองใช้ร่วมกับ 'การแก้ไข' อื่น ๆ
— pingu

คำตอบ:

4

ฉันคิดว่าฉันจะตอบคำถามด้วยการสังเกตของฉันเพราะมีความคิดเห็นมากมาย

อ้างอิงจากผลลัพธ์ของคุณที่https://gist.github.com/christian-marie/7bc845d2da7847534104

เราสามารถกำหนดสิ่งต่อไปนี้:

  1. GFP_MASK สำหรับการจัดสรรหน่วยความจำพยายามได้รับอนุญาตให้ทำดังต่อไปนี้
    • สามารถเข้าถึงพูลฉุกเฉิน (ฉันคิดว่านี่หมายถึงข้อมูลการเข้าถึงใต้ลายน้ำสูงสำหรับโซน)
    • อย่าใช้เงินสำรองฉุกเฉิน (ฉันคิดว่านี่หมายความว่าไม่อนุญาตให้เข้าถึง memroy ด้านล่างลายน้ำขั้นต่ำ)
    • จัดสรรจากหนึ่งในโซนปกติ
    • สามารถสลับเพื่อให้มีที่ว่าง
    • สามารถวางแคชเพื่อให้มีที่ว่าง

การกระจายตัวของโซนเป็นที่ตั้งที่นี่:

[3443189.780792] Node 0 Normal: 3300*4kB (UEM) 8396*8kB (UEM) 4218*16kB (UEM) 76*32kB (UEM) 12*64kB (M) 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 151056kB
[3443189.780801] Node 1 Normal: 26667*4kB (UEM) 6084*8kB (UEM) 2040*16kB (UEM) 96*32kB (UEM) 22*64kB (UEM) 4*128kB (U) 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 192972kB

และการใช้หน่วยความจำในเวลานั้นอยู่ที่นี่:

[3443189.780759] Node 0 Normal free:149520kB min:40952kB low:51188kB high:61428kB active_anon:9694208kB inactive_anon:1054236kB active_file:7065912kB inactive_file:7172412kB unevictable:0kB isolated(anon):5452kB isolated(file):3616kB present:30408704kB managed:29881160kB mlocked:0kB dirty:0kB writeback:0kB mapped:25440kB shmem:743788kB slab_reclaimable:1362240kB slab_unreclaimable:783096kB kernel_stack:29488kB pagetables:43748kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no
[3443189.780766] Node 1 Normal free:191444kB min:45264kB low:56580kB high:67896kB active_anon:11371988kB inactive_anon:1172444kB active_file:8084140kB inactive_file:8556980kB unevictable:0kB isolated(anon):4388kB isolated(file):4676kB present:33554432kB managed:33026648kB mlocked:0kB dirty:0kB writeback:0kB mapped:45400kB shmem:2263296kB slab_reclaimable:1606604kB slab_unreclaimable:438220kB kernel_stack:55936kB pagetables:44944kB unstable:0kB bounce:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no

การแตกแฟรกเมนต์ของแต่ละโซนนั้นไม่ดีในเอาต์พุตความล้มเหลวในการจัดสรรหน้า มีคำสั่งฟรีจำนวนมากที่มีหน้าสั่งซื้อที่น้อยกว่ามากถึงไม่มีเลย ผลลัพธ์ 'ดี' จะเป็นหน้าฟรีที่อุดมสมบูรณ์พร้อมคำสั่งซื้อแต่ละครั้งค่อย ๆ ลดขนาดให้ใหญ่ขึ้นตามลำดับที่คุณไป การมีลำดับสูง 0 หน้า 5 ขึ้นไปบ่งบอกถึงการกระจายตัวและความอดอยากสำหรับการจัดสรรใบสั่งสูง

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

Node 0 = active_anon:9694208kB inactive_anon:1054236kB
Node 1 = active anon:11371988kB inactive_anon:1172444kB

ไม่มีหน้าขนาดใหญ่ที่ได้รับมอบหมายจาก userspace และ userspace จะอ้างสิทธิ์การสั่งซื้อ 0 หน่วยความจำเสมอ ดังนั้นในทั้งสองโซนรวมกันมีหน่วยความจำที่จัดเรียงได้มากกว่า 22GiB

พฤติกรรมที่ฉันอธิบายไม่ได้

เมื่อการจัดสรรคำสั่งซื้อสูงล้มเหลวฉันเข้าใจว่าการพยายามบีบอัดหน่วยความจำมักจะเกิดขึ้นเพื่อให้ภูมิภาคของการจัดสรรหน่วยความจำระดับสูงเกิดขึ้นและประสบความสำเร็จ ทำไมสิ่งนี้ไม่เกิดขึ้น? หากมันเกิดขึ้นทำไมถึงไม่สามารถหาหน่วยความจำใด ๆ ที่จะจัดเรียงข้อมูลเมื่อมี 22GiB ของมันสุกสำหรับการจัดเรียงใหม่?

พฤติกรรมฉันคิดว่าฉันสามารถอธิบายได้

สิ่งนี้ต้องการการวิจัยเพิ่มเติมเพื่อให้เข้าใจอย่างถูกต้อง แต่ฉันเชื่อว่าความสามารถในการจัดสรรเพื่อแลกเปลี่ยน / วาง pagecache บางส่วนเพื่อประสบความสำเร็จโดยอัตโนมัติอาจไม่สามารถใช้ที่นี่ได้เนื่องจากมีหน่วยความจำว่างจำนวนมากที่ยังคงมีอยู่ เพียงแค่ไม่เพียงพอในคำสั่งซื้อที่สูงขึ้น

ในขณะที่มีหน่วยความจำว่างจำนวนมากและมีการสั่งซื้อ 4 คำขอไม่กี่รายการในแต่ละโซนปัญหา "รวมหน่วยความจำฟรีทั้งหมดสำหรับแต่ละคำสั่งซื้อและหักออกจากหน่วยความจำที่ว่างจริง" ส่งผลให้ สิ่งที่นำไปสู่ความล้มเหลวในการจัดสรรจริง

— Matthew Ife
แหล่งที่มา
ดูเหมือนแปลกที่แคช SLAB ขนาดเล็กที่ค่อนข้าง (รวมหน่วยความจำทั้งหมด) จะแยกส่วนความทรงจำทั้งหมด ฉันคาดว่าจะมีหน้าที่ขับไล่ได้ฟรีทั้งหมดมันจะขับไล่บางอย่างออกไป ฉันสงสัยว่า NUMA อาจมีส่วนเกี่ยวข้องกับสิ่งประหลาดนี้
— pingu
มีการnumadทำงานในระบบนี้หรือไม่?
— ewwhite
@ ขาว numad ไม่ทำงานไม่
— pingu
@pingu หากลักษณะการทำงานนี้คือสามารถทำซ้ำได้ลองเปิดใช้บริการและรับทราบการดำเนินการในnumad /var/log/numad.logคุณอาจต้องติดตั้ง libcgroup
— ewwhite
@ ขาวขาวเอาล่ะฉันมีหนึ่งทำงานอยู่ตอนนี้ ฉันไม่แน่ใจว่าสิ่งที่ฉันคาดหวังว่าจะทำหรือข้อมูลที่เราอาจได้รับจากมัน คุณหวังว่าจะเกิดอะไรขึ้น
— pingu
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.