Vùng chứa đang vượt quá giới hạn bộ nhớ

Trong Hadoop v1, tôi đã chỉ định mỗi 7 khe cắm bản đồ và trình thu gọn với kích thước 1GB, trình liên kết và trình giảm tốc của tôi chạy tốt. Máy mình có bộ nhớ 8G, vi xử lý 8 nhân. Bây giờ với YARN, khi chạy cùng một ứng dụng trên cùng một máy, tôi đã gặp lỗi vùng chứa. Theo mặc định, tôi có cài đặt này:

  <property>
    <name>yarn.scheduler.minimum-allocation-mb</name>
    <value>1024</value>
  </property>
  <property>
    <name>yarn.scheduler.maximum-allocation-mb</name>
    <value>8192</value>
  </property>
  <property>
    <name>yarn.nodemanager.resource.memory-mb</name>
    <value>8192</value>
  </property>

Nó đã cho tôi lỗi:

Container [pid=28920,containerID=container_1389136889967_0001_01_000121] is running beyond virtual memory limits. Current usage: 1.2 GB of 1 GB physical memory used; 2.2 GB of 2.1 GB virtual memory used. Killing container.

Sau đó, tôi đã cố gắng đặt giới hạn bộ nhớ trong mapred-site.xml:

  <property>
    <name>mapreduce.map.memory.mb</name>
    <value>4096</value>
  </property>
  <property>
    <name>mapreduce.reduce.memory.mb</name>
    <value>4096</value>
  </property>

Nhưng vẫn gặp lỗi:

Container [pid=26783,containerID=container_1389136889967_0009_01_000002] is running beyond physical memory limits. Current usage: 4.2 GB of 4 GB physical memory used; 5.2 GB of 8.4 GB virtual memory used. Killing container.

Tôi bối rối tại sao tác vụ bản đồ lại cần nhiều bộ nhớ như vậy. Theo hiểu biết của tôi, 1GB bộ nhớ là đủ cho tác vụ bản đồ / thu nhỏ của tôi. Tại sao khi tôi gán nhiều bộ nhớ hơn cho vùng chứa, tác vụ sử dụng nhiều hơn? Có phải vì mỗi nhiệm vụ được phân chia nhiều hơn? Tôi cảm thấy sẽ hiệu quả hơn khi giảm kích thước của vùng chứa một chút và tạo nhiều vùng chứa hơn để nhiều tác vụ chạy song song hơn. Vấn đề là làm thế nào tôi có thể đảm bảo rằng mỗi vùng chứa sẽ không được chỉ định nhiều phân chia hơn mức nó có thể xử lý?

Bạn cũng nên định cấu hình đúng cách phân bổ bộ nhớ tối đa cho MapReduce. Từ hướng dẫn HortonWorks này :

[...]

Mỗi máy trong cụm của chúng tôi có 48 GB RAM. Một số RAM này nên được> dành riêng cho việc sử dụng Hệ điều hành. Trên mỗi nút, chúng tôi sẽ gán 40 GB RAM cho> YARN để sử dụng và giữ lại 8 GB cho Hệ điều hành

Đối với cụm ví dụ của chúng tôi, chúng tôi có RAM tối thiểu cho Vùng chứa (fiber.scheduler.minimum-Delivery-mb) = 2 GB. Do đó, chúng tôi sẽ gán 4 GB cho Vùng chứa nhiệm vụ bản đồ và 8 GB cho Vùng chứa nhiệm vụ Giảm.

Trong mapred-site.xml:

mapreduce.map.memory.mb: 4096

mapreduce.reduce.memory.mb: 8192

Mỗi Vùng chứa sẽ chạy JVM cho các tác vụ Bản đồ và Rút gọn. Kích thước đống JVM phải được đặt thấp hơn Bản đồ và Giảm bộ nhớ được xác định ở trên, để chúng nằm trong giới hạn của bộ nhớ Vùng chứa được YARN cấp phát.

Trong mapred-site.xml:

mapreduce.map.java.opts: -Xmx3072m

mapreduce.reduce.java.opts: -Xmx6144m

Các cài đặt trên định cấu hình giới hạn trên của RAM vật lý mà các tác vụ Bản đồ và Giảm sẽ sử dụng .

Tóm lại:

1. Trong YARN, bạn nên sử dụng cấu hình mapreducechứ không phải cấu mapredhình. CHỈNH SỬA: Nhận xét này không còn áp dụng nữa vì bạn đã chỉnh sửa câu hỏi của mình.
2. Những gì bạn đang định cấu hình thực sự là số tiền bạn muốn yêu cầu, không phải là mức tối đa để phân bổ.
3. Các giới hạn tối đa được định cấu hình với các java.optscài đặt được liệt kê ở trên.

Cuối cùng, bạn có thể muốn kiểm tra câu hỏi SO khác mô tả một vấn đề tương tự (và giải pháp).

Có một kiểm tra được đặt ở cấp độ Yarn cho tỷ lệ sử dụng bộ nhớ ảo và vật lý. Vấn đề không chỉ là VM không có đủ bộ nhớ vật lý. Nhưng đó là do việc sử dụng bộ nhớ ảo nhiều hơn mong đợi đối với bộ nhớ vật lý nhất định.

Lưu ý : Điều này đang xảy ra trên Centos / RHEL 6 do phân bổ bộ nhớ ảo tích cực.

Nó có thể được giải quyết bằng cách:

1. Tắt tính năng kiểm tra mức sử dụng bộ nhớ ảo bằng cách cài đặt wire.nodemanager.vmem-check-enable thành false ;

2. Tăng tỷ lệ VM: PM bằng cách đặt tỷ lệ sợi.nodemanager.vmem-pmem thành một số giá trị cao hơn.

Tài liệu tham khảo :

https://issues.apache.org/jira/browse/HADOOP-11364

http://blog.cloudera.com/blog/2014/04/apache-hadoop-yarn-avoiding-6-time-consuming-gotchas/

Thêm thuộc tính sau trong sợi-site.xml

 <property>
   <name>yarn.nodemanager.vmem-check-enabled</name>
    <value>false</value>
    <description>Whether virtual memory limits will be enforced for containers</description>
  </property>
 <property>
   <name>yarn.nodemanager.vmem-pmem-ratio</name>
    <value>4</value>
    <description>Ratio between virtual memory to physical memory when setting memory limits for containers</description>
  </property>

Tôi đã gặp vấn đề tương tự khi sử dụng HIVE trong EMR. Không có giải pháp hiện có nào phù hợp với tôi - tức là không có cấu hình mapreduce nào phù hợp với tôi; và cũng không đặt yarn.nodemanager.vmem-check-enabledthành false.

Tuy nhiên, những gì cuối cùng hoạt động là thiết lập tez.am.resource.memory.mb, ví dụ:

hive -hiveconf tez.am.resource.memory.mb=4096

Một cài đặt khác để xem xét điều chỉnh là yarn.app.mapreduce.am.resource.mb

Tôi không thể bình luận về câu trả lời được chấp nhận, do danh tiếng thấp. Tuy nhiên, tôi muốn nói thêm, hành vi này là do thiết kế. NodeManager đang giết vùng chứa của bạn. Có vẻ như bạn đang cố gắng sử dụng tính năng phát trực tuyến hadoop đang chạy như một quy trình con của nhiệm vụ thu nhỏ bản đồ. NodeManager giám sát toàn bộ cây quy trình của tác vụ và nếu nó chiếm nhiều bộ nhớ hơn bộ nhớ tối đa được đặt trong mapreduce.map.memory.mb hoặc mapreduce.reduce.memory.mb tương ứng, chúng tôi sẽ hy vọng Nodemanager sẽ hủy nhiệm vụ, nếu không nhiệm vụ của bạn là đánh cắp bộ nhớ của các vùng chứa khác mà bạn không muốn.

Trong khi làm việc với spark trong EMR, tôi đã gặp vấn đề tương tự và cài đặt maximizeResourceAllocation=trueđã thực hiện một mẹo; hy vọng nó sẽ giúp một ai đó. Bạn phải đặt nó khi bạn tạo cụm. Từ tài liệu EMR:

aws emr create-cluster --release-label emr-5.4.0 --applications Name=Spark \
--instance-type m3.xlarge --instance-count 2 --service-role EMR_DefaultRole --ec2-attributes InstanceProfile=EMR_EC2_DefaultRole --configurations https://s3.amazonaws.com/mybucket/myfolder/myConfig.json

Nơi myConfig.json nên nói:

[
  {
    "Classification": "spark",
    "Properties": {
      "maximizeResourceAllocation": "true"
    }
  }
]

Chúng tôi cũng phải đối mặt với vấn đề này gần đây. Nếu vấn đề liên quan đến bộ nhớ người lập bản đồ, tôi muốn đề xuất một số điều cần được kiểm tra.

• Kiểm tra xem bộ kết hợp đã được bật hay chưa ? Nếu có, thì điều đó có nghĩa là logic rút gọn phải được chạy trên tất cả các bản ghi (đầu ra của ánh xạ). Điều này xảy ra trong bộ nhớ. Dựa trên ứng dụng của bạn, bạn cần kiểm tra xem việc kích hoạt bộ kết hợp có hữu ích hay không. Sự cân bằng là giữa byte truyền mạng và thời gian thực hiện / bộ nhớ / CPU để giảm bớt logic trên số lượng bản ghi 'X'.
  • Nếu bạn cảm thấy bộ kết hợp đó không có nhiều giá trị, chỉ cần vô hiệu hóa nó.
  • Nếu bạn cần bộ kết hợp và 'X' là một con số khổng lồ (giả sử hàng triệu bản ghi) thì hãy xem xét thay đổi logic phân tách của bạn (Đối với các định dạng đầu vào mặc định sử dụng kích thước khối nhỏ hơn, thông thường 1 kích thước khối = 1 lần tách) để ánh xạ số lượng bản ghi ít hơn thành một người lập bản đồ duy nhất.
• Số lượng bản ghi được xử lý trong một trình ánh xạ duy nhất. Hãy nhớ rằng tất cả các bản ghi này cần được sắp xếp trong bộ nhớ (đầu ra của ánh xạ được sắp xếp). Cân nhắc đặt mapreduce.task.io.sort.mb (mặc định là 200MB) thành giá trị cao hơn nếu cần. mapred-configs.xml
• Nếu bất kỳ cách nào ở trên không hữu ích, hãy thử chạy logic ánh xạ dưới dạng ứng dụng độc lập và lập hồ sơ ứng dụng bằng Trình biên dịch (như JProfiler) và xem bộ nhớ được sử dụng ở đâu. Điều này có thể cung cấp cho bạn những hiểu biết rất tốt.

Đang chạy thread trên hệ thống con Windows Linux với HĐH Ubunto, lỗi "chạy vượt quá giới hạn bộ nhớ ảo, Killing container" Tôi đã giải quyết bằng cách tắt kiểm tra bộ nhớ ảo trong tệp thread-site.xml

<property> <name>yarn.nodemanager.vmem-check-enabled</name> <value>false</value> </property> 

Tôi chưa kiểm tra cá nhân, nhưng hadoop-sợi-container-ảo-bộ nhớ-hiểu-và-giải-quyết-chứa-đang-chạy-vượt-ảo-giới-hạn-bộ-nhớ-lỗi- nghe rất hợp lý

Tôi đã giải quyết vấn đề bằng cách thay đổi yarn.nodemanager.vmem-pmem-ratiothành giá trị cao hơn và tôi đồng ý rằng:

Một giải pháp khác ít được đề xuất hơn là vô hiệu hóa kiểm tra bộ nhớ ảo bằng cách đặt tùy chọn wire.nodemanager.vmem-check-enable thành false.