2010-08-18 33 views
8

Tôi đang gặp sự cố với cầu tàu bị rơi liên tục, tôi đang sử dụng Jetty 6.1.24.Các sự cố với cầu tàu bị rơi liên tục

Tôi đang chạy một ứng dụng web Spring MVC neo4j, Jetty sẽ tiếp tục chạy trong khoảng 1 giờ và sau đó tôi phải khởi động lại Jetty. Nó đang chạy trên phiên bản amazon ec2 nhỏ, debian với 1,7 GB RAM.

tôi bắt đầu sử dụng Jetty java -Xmx900m -server -jar start.jar

Tôi đang kết nối đến máy chủ sử dụng putty, khi Jetty treo những ngắt kết nối phiên putty, tôi không thể nhìn thấy những gì lỗi gây ra nó sụp đổ.

Tôi muốn có thể biết nếu đó là lỗi do Spring tạo ra, tôi không chắc chắn cách đăng xuất kết quả từ ứng dụng mùa xuân bằng Jetty. Hoặc nếu nó là Jetty hoặc một vấn đề bộ nhớ, thì cách tốt nhất để giám sát Jetty là gì? Tôi không thể tạo lại điều này trên các cửa sổ đang chạy máy cục bộ của mình. Bạn nghĩ điều gì sẽ là cách tốt nhất để tiếp cận điều này? Cảm ơn

+0

Bạn có thể làm rõ câu hỏi của mình không? Ý của bạn là gì bởi "giao diện điều khiển ứng dụng web của tôi"? Ứng dụng web của bạn có đang gửi đăng nhập tới stdout (System.out) không? Bạn đang chạy hệ điều hành nào? – Tim

+1

Tại sao câu hỏi này được đánh dấu là CW? – BalusC

+0

cảm ơn tôi đã bắt đầu một ví dụ debian ec2 mới, tôi sẽ cài đặt lại cầu cảng và tôi sẽ thử tất cả các đề xuất, không chắc chắn câu trả lời nào để sử dụng vì chúng là tất cả các câu trả lời phù hợp – patrickandroid

Trả lời

4

Khi bạn nói sự cố bạn có nghĩa là JVM sẽ phân tách và biến mất không? Nếu đó là trường hợp tôi muốn kiểm tra và chắc chắn rằng bạn không làm cạn kiệt bộ nhớ có sẵn của máy.Java trên linux sẽ sụp đổ khi bộ nhớ hệ thống quá thấp nên JVM không thể cấp phát bộ nhớ tối đa của nó. Ví dụ: bạn đã đặt bộ nhớ JVM tối đa là 500MB trong đó hiện tại nó đang sử dụng 250MB. Tuy nhiên, hệ điều hành Linux chỉ có 128MB. Điều này tạo ra kết quả không ổn định và JVM sẽ phân đoạn.

Trên các cửa sổ, JVM hoạt động tốt hơn trong trường hợp này và ném OutOfMemoryError khi hệ thống sắp hết bộ nhớ.

  1. Xác thực lượng bộ nhớ hệ thống có sẵn trong khoảng thời gian xảy ra sự cố.
  2. Xác minh xem các quy trình khác trên hộp của bạn có đang ăn quá nhiều bộ nhớ hay không. Tắt mọi thứ có thể cạnh tranh với JVM.
  3. Chạy jconsole và kết nối nó với JVM của bạn. Điều đó sẽ cho bạn biết làm thế nào bộ nhớ đang được sử dụng trong quá trình JVM của bạn và cung cấp cho bạn một lịch sử để nhìn lại thông qua khi nó sụp đổ.
  4. Loại bỏ bất kỳ mã gốc nào mà bạn có thể tải vào JVM khi thực hiện loại thử nghiệm này.

Tôi tin rằng Jetty có một số mã gốc để xử lý yêu cầu khối lượng lớn. Hãy chắc chắn rằng nó không được sử dụng. Bạn muốn cách ly các sự cố với Java và KHÔNG phải là một số lib gốc lạ. Nếu bạn đưa ra các công cụ bản địa và tìm thấy nó hoạt động sau đó bạn có câu trả lời của bạn là những gì gây ra nó. Nếu nó tiếp tục sụp đổ thì nó rất tốt có thể là những gì tôi mô tả.

Bạn có thể buộc JVM phân bổ tất cả bộ nhớ khi khởi động với -Xms900m có thể đảm bảo JVM không chiến đấu với các quy trình khác cho bộ nhớ. Khi nó có số tiền Xmx đầy đủ, nó sẽ không sụp đổ. Không phải là một giải pháp, nhưng bạn có thể dễ dàng kiểm tra nó theo cách này.

+0

. , tôi sẽ thử tất cả các đề xuất của bạn – patrickandroid

+0

tung ra cầu cảng với -Xms900m có vẻ đã cố định nó, nhờ – patrickandroid

5

Đây không phải là câu hỏi lập trình thực sự; có lẽ nó sẽ được chuyển sang ServerFault.

Bạn đã không chỉ định rõ hệ điều hành nào bạn đang sử dụng, nhưng tôi đang phân tích dự đoán tại một số bản phân phối Linux. Bạn có hai tùy chọn để tìm ra điều gì sai:

  1. Bắt đầu phiên của bạn trên màn hình. Màn hình sẽ hoạt động miễn là máy thực sự được bật trên, cho đến khi bạn khởi động lại hệ điều hành (hoặc bạn thoát khỏi màn hình).

    bạn khởi động màn hình như thế này

    screen 
    

    và bạn nhận được một nhắc nhở mới, nơi bạn có thể bắt đầu chương trình của bạn (cd foo, cầu cảng, vv). Khi bạn đang hạnh phúc và bạn chỉ cần đi đâu đó, bạn có thể ngắt kết nối màn hình bằng cách nhấn CTRL + A và sau đó nhấn CTRL + D. bạn sẽ quay trở lại nơi bạn đã ở trước khi bạn gọi screen.

    Để quay lại xem screen bạn nhập screen -R có nghĩa là tiếp tục màn hình hiện có. bạn sẽ thấy cầu cảng một lần nữa.

    Những điều tốt đẹp là nếu bạn bị mất kết nối (hoặc bạn putty gần một cách tình cờ hoặc bất cứ điều gì) sau đó bạn có thể sử dụng screen -list để có được một danh sách các hoạt động màn hình, và sau đó buộc phải tách chúng -D và lắp lại họ đến putty hiện -R , không có hại gì!

  2. Sử dụng nohup. Nohup nhiều hay ít làm gián đoạn quá trình bạn đang chạy từ bảng điều khiển, do đó, không có đầu ra nào của nó đi tới thiết bị đầu cuối. Bạn bắt đầu chương trình của mình theo cách thông thường, nhưng bạn thêm từ nohup vào lệnh của mình.

    Ví dụ:

    nohup ls -l & 
    

    Sau ls -l hoàn tất, đầu ra của bạn được lưu trữ trong nohup.out.

+0

nhờ trợ giúp, màn hình rất hữu ích – patrickandroid

2

Khi bạn khởi động java, chuyển hướng cả hai kết quả đầu ra (stdout và stderr) vào một tập tin:

Sử dụng Bash:

java -Xmx900m -server -jar start.jar > stdout.txt 2> stderr.txt 

Sau vụ tai nạn, kiểm tra các tập tin.

Nếu sự cố là do tín hiệu (như SEGV = lỗi phân đoạn), cần có tệp kết xuất bởi JVM tại vị trí bạn đã bắt đầu java. Đối với Sun VM (hotspot), nó giống như hs_err_pid12121.log (ở đây 12121 là ID tiến trình).

+0

cảm ơn đây là giải pháp lý tưởng cho tôi để ghi nhật ký đầu ra từ cầu cảng vào tệp văn bản – patrickandroid

1

Tắt ngắt kết nối Gợi ý mạnh mẽ rằng máy chủ hết bộ nhớ và bắt đầu tắt quy trình sang trái và sang phải. Nó có lẽ là trường hợp jetty của bạn phát triển quá lớn.

Điều dễ nhất hiện tại là thêm 1-2 Gb thêm không gian hoán đổi và thực hiện lại. Cũng lưu ý rằng bạn có thể sử dụng jvisualvm để đính kèm vào cá thể jetty để lấy thông tin thời gian chạy trực tiếp.

+0

cảm ơn tôi đã thêm trao đổi bằng cách sử dụng: http: // www.debian-administration.org/bài viết/550 – patrickandroid

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