2016-12-01 18 views
6

Tôi đang chạy cụm tia lửa ở chế độ độc lập và ứng dụng bằng cách sử dụng tính năng phát tia lửa. Trong phần giai đoạn UI của giao diện người dùng, tôi đã tìm thấy giai đoạn thực thi với thời gian thực hiện lớn (> 10h, khi thời gian thông thường ~ 30 giây). Giai đoạn có nhiều tác vụ thất bại với lỗi Resubmitted (resubmitted due to lost executor). Có người thi hành có địa chỉ CANNOT FIND ADDRESS trong mục Aggregated Metrics by Executor trong trang giai đoạn. Spark cố gắng gửi lại tác vụ này vô hạn. Nếu tôi giết giai đoạn này (ứng dụng của tôi sẽ tự động chạy lại các công việc spark chưa hoàn thành), tất cả sẽ tiếp tục hoạt động tốt.Ứng dụng Spark giết chết người thi hành

Ngoài ra, tôi đã tìm thấy một số mục lạ trong nhật ký tia lửa (cùng thời gian như bắt đầu thực hiện giai đoạn).

Master:

16/11/19 19:04:32 INFO Master: Application app-20161109161724-0045 requests to kill executors: 0 
16/11/19 19:04:36 INFO Master: Launching executor app-20161109161724-0045/1 on worker worker-20161108150133 
16/11/19 19:05:03 WARN Master: Got status update for unknown executor app-20161109161724-0045/0 
16/11/25 10:05:46 INFO Master: Application app-20161109161724-0045 requests to kill executors: 1 
16/11/25 10:05:48 INFO Master: Launching executor app-20161109161724-0045/2 on worker worker-20161108150133 
16/11/25 10:06:14 WARN Master: Got status update for unknown executor app-20161109161724-0045/1 

Worker:

16/11/25 10:06:05 INFO Worker: Asked to kill executor app-20161109161724-0045/1 
16/11/25 10:06:08 INFO ExecutorRunner: Runner thread for executor app-20161109161724-0045/1 interrupted 
16/11/25 10:06:08 INFO ExecutorRunner: Killing process! 
16/11/25 10:06:13 INFO Worker: Executor app-20161109161724-0045/1 finished with state KILLED exitStatus 137 
16/11/25 10:06:14 INFO Worker: Asked to launch executor app-20161109161724-0045/2 for app.jar 
16/11/25 10:06:17 INFO SecurityManager: Changing view acls to: spark 
16/11/25 10:06:17 INFO SecurityManager: Changing modify acls to: spark 
16/11/25 10:06:17 INFO SecurityManager: SecurityManager: authentication disabled; ui acls disabled; users with view permissions: Set(spark); users with modify permissions: Set(spark) 

Không có vấn đề với kết nối mạng vì công nhân, thạc sĩ (bản ghi ở trên), lái xe chạy trên cùng một máy.

Spark phiên bản 1.6.1

+1

Bạn có thể thêm nhật ký của nhân viên gây ra sự cố không? Một nhân viên có thể bị giết trong trường hợp một nhiệm vụ thất bại số lần. Có bất kỳ trường hợp ngoại lệ nào xảy ra không? –

+0

@YuvalItzchakov công nhân đăng nhập vào nhật ký pos từ công nhân bị mất thi hành. Không có ngoại lệ và không thành công trước khi người thực thi bị mất. – Cortwave

+0

* "công nhân đăng nhập pos - nhật ký từ công nhân bị mất thi hành" * Không chắc chắn điều đó nghĩa là gì –

Trả lời

6

Có khả năng một phần thú vị của các bản ghi là:

16/11/25 10:06:13 INFO Worker: Executor app-20161109161724-0045/1 finished with state KILLED exitStatus 137 

Thoát 137 đề nghị mạnh mẽ một vấn đề tài nguyên, hoặc nhớ hoặc CPU lõi. Cho rằng bạn có thể sửa chữa các vấn đề của bạn bằng cách chạy lại giai đoạn nó có thể là bằng cách nào đó tất cả các lõi đã được phân bổ (có thể bạn cũng có một số vỏ Spark đang chạy?). Đây là vấn đề thường gặp với các thiết lập Spark độc lập (mọi thứ trên một máy chủ).

Dù bằng cách nào tôi sẽ cố gắng những điều sau đây theo thứ tự:

  1. Nâng phe bộ nhớ lưu trữ spark.storage.memoryFraction tiền phân bổ bộ nhớ hơn cho việc lưu trữ và ngăn chặn kẻ giết người hệ thống oom để cung cấp cho một cách ngẫu nhiên với bạn rằng 137 trên một lớn sân khấu.
  2. Đặt số lõi thấp hơn cho ứng dụng của bạn để loại trừ việc phân bổ trước một số yếu tố trước khi giai đoạn của bạn được chạy. Bạn có thể thực hiện điều này qua spark.deploy.defaultCores, đặt thành 3 hoặc thậm chí 2 (trên quad-core intel giả định 8 vcores)
  3. Cấp phát hết RAM cho Spark ->spark.executor.memory cần tăng lên.
  4. Có lẽ bạn chạy vào một vấn đề với dọn dẹp dữ liệu meta đây, cũng không phải không nghe trong triển khai ở địa phương, trong trường hợp này thêm
    export SPARK_JAVA_OPTS +="-Dspark.kryoserializer.buffer.mb=10 -Dspark.cleaner.ttl=43200" đến cùng bạn spark-env.sh thể làm như lừa bằng cách buộc dọn dẹp dữ liệu meta để chạy thường xuyên hơn

Một trong những điều này nên thực hiện thủ thuật theo ý kiến ​​của tôi.

3

Câu trả lời của Armin rất tốt. Tôi chỉ muốn chỉ ra những gì làm việc cho tôi.

Vấn đề tương tự ra đi khi tôi tăng tham số:

spark.default.parallelism từ 28 (mà là số lượng Chấp hành viên mà tôi có) đến 84 (đó là số lõi có sẵn).

LƯU Ý: đây không phải là quy tắc để đặt thông số này, đây chỉ là những gì đã hiệu quả đối với tôi.

CẬP NHẬT: Phương pháp này cũng được hỗ trợ bởi Spark's documentation:

Đôi khi, bạn sẽ nhận được một OutOfMemoryError không phải vì RDDs của bạn không phù hợp trong bộ nhớ, nhưng vì làm việc thiết lập của một trong những nhiệm vụ của bạn , chẳng hạn như một trong các tác vụ giảm trong groupByKey, quá lớn. Các hoạt động trộn của Spark (sortByKey, groupByKey, reduceByKey, join, vv) xây dựng một bảng băm trong mỗi tác vụ để thực hiện việc nhóm, thường có thể lớn. Sửa chữa đơn giản nhất ở đây là tăng mức độ song song, sao cho mỗi tập hợp đầu vào của mỗi tác vụ nhỏ hơn. Spark có thể hỗ trợ hiệu quả các tác vụ chỉ với 200 ms, vì nó sử dụng lại một JVM thực thi trên nhiều nhiệm vụ và nó có chi phí khởi chạy thấp, vì vậy bạn có thể tăng mức độ song song lên nhiều hơn số lõi trong các cụm của bạn.

+0

Bạn có một số giải thích lý thuyết cho điều này? – Cortwave

+0

@Câu trả lời có, tăng số lượng phân vùng làm giảm yêu cầu bộ nhớ của mỗi tác vụ (mỗi phân vùng được xử lý bởi một nhiệm vụ). Đối với số lượng cụ thể, không, nhưng trong kinh nghiệm MapReduce trước đây của tôi, việc thêm nhiều phân vùng có hành vi tương tự và tôi tiếp tục tăng chúng cho đến khi không có lỗi OOM nào được đưa ra (nếu có). – vefthym

Các vấn đề liên quan