2015-07-01 13 views
5

Tôi có một cụm Elasticsearch được tạo thành từ hai nút. Một trang web (trực tiếp) trực tiếp sử dụng cụm này, liên tục chạy các truy vấn tìm kiếm và chỉ mục trên cụm ES của tôi.Elasticsearch không khả dụng khi đổ bộ thu gom rác?

Vấn đề của tôi là, trên cơ sở thường xuyên (và không thể đoán trước), toàn bộ cụm sẽ không khả dụng khi một trong các nút làm trống bộ thu gom rác. Thư tôi nhận được từ nhật ký nút trông giống như

[2015-07-01 06:43:19,525][INFO ][monitor.jvm] [my_node] [gc][old][205450][116] 
duration [5.7s], collections [1]/[6.3s], total [5.7s]/[1m], 
memory [22.3gb]->[4.9gb]/[30.9gb], 
all_pools {[young] [392.9mb]->[17.2mb]/[665.6mb]} 
{[survivor] [29.1mb]->[0b]/[83.1mb]} 
{[old] [21.9gb]->[4.9gb]/[30.1gb]} 

Từ những gì tôi hiểu (Tôi không phải là người java), dòng này chỉ ra rằng ES đang dọn sạch bộ thu gom rác. Vì vậy, trong 5 giây đó, nút không phản hồi, cũng không phải cụm của tôi, cũng không phải là trang web của tôi. Thời gian chết này xảy ra từ 5 đến 10 lần mỗi ngày.

Tôi có làm gì sai ở đây hoặc thời gian chết này không thể tránh khỏi? Tôi có nên thêm một cân bằng tải Elasticsearch (tức là một nút với dữ liệu = false, master = false) đến cụm và có điểm trang web của tôi để loadbalancer này? Hoặc tôi nên thêm một loại cân bằng tải (HAProxy?) Ở phía trước của các nút của tôi? Hay điều này có nghĩa là có gì đó sai với các máy chủ, dữ liệu?

Thanks a lot trước

Một số thông tin về cấu hình cluster

  • Elasticsearch 1.6.0 cụm làm bằng 2 nút (5 mảnh, 1 bản sao)
  • Cụm chứa ~ 10 triệu tài liệu, chiếm ~ 30 Gb.
  • Mỗi nút là một máy chủ RAM 64GB với một MAX_HEAP_SIZE thiết lập để 31g
  • Trang web chạy ~ 300 truy vấn tìm kiếm mỗi giây và ~ 100 truy vấn chỉ số mỗi sử dụng đống
  • Các JVM thứ hai luôn là giữa 50% và 75% , không bao giờ ở trên
+1

Có, trong GC cũ, nút mà GC chạy sẽ bị đóng băng. Đây là cách nó liên quan đến Java. Về điều chỉnh này không phải là dễ dàng :-). Có nhiều điều cần xem xét và không dễ để bạn chia sẻ những điều đó. –

+0

Nếu việc sử dụng heap luôn ở mức từ 50% đến 75% thì Garbage Collector sẽ không chạy lâu (và từ nhật ký bạn đăng nó trông giống như đống đã gần đầy khi GC chạy trong 6 giây). Phân bổ nhiều RAM hơn cho heap sẽ giúp ích, nhưng có thể có các yếu tố khác trong công việc gây ra quá nhiều RAM đang được sử dụng ngay từ đầu. Những yếu tố đó sẽ khó theo dõi và/hoặc sửa chữa. – mhlz

+0

Ngoài ra, hãy đảm bảo bạn luôn chạy phiên bản Java và Elasticsearch mới nhất nếu có thể. – mhlz

Trả lời

-1

Vì khi GC chạy heap đi từ 21,9gb đến 4,9gb, tôi nghi ngờ việc sử dụng đống là từ 50% đến 75%, nhiều khả năng GC được kích hoạt trên 75% và sau đó giảm xuống ~ 15%. Nếu bạn chưa cài đặt Marvel - hãy cài đặt nó và theo dõi các thông số như đếm phân đoạn và sử dụng đống. Để giảm số lượng phân đoạn, hãy chạy Tối ưu hóa trên các chỉ mục có ít hoặc không viết (https://www.elastic.co/guide/en/elasticsearch/reference/2.1/indices-optimize.html). Nếu bạn tiếp tục bị chậm lại khi chạy GC, hãy thử giảm kích thước heap. Tôi biết nó có vẻ phản tác dụng, nhưng trong trường hợp này nó có ý nghĩa. Có một ghi chú tốt về chủ đề trên trang web Đàn hồi - https://www.elastic.co/blog/a-heap-of-trouble