Thống kê về sự cố RAM


8

Có ai biết về bất kỳ số liệu thống kê hoặc nghiên cứu nào về tần suất máy tính bị hỏng RAM không?

Cập nhật: Máy tính của tôi vẫn ổn! Tôi không có vấn đề về RAM, tôi quan tâm đến số liệu thống kê. Tôi nhận được báo cáo lỗi cho phần mềm của mình vì một nguyên nhân có thể làm hỏng RAM trên máy tính của người dùng và tôi muốn biết khả năng đó là như thế nào.

Cảm ơn!

Carl


Bạn có thể đưa ra một số chi tiết cụ thể về vấn đề mà bạn đang đổ lỗi cho sự thất bại của ram không?
Dave Cheney

Một chút. Chúng tôi tính toán tổng kiểm tra từ các tệp và từ các phần của các tệp đó từ ổ cứng và một khi chúng được tải vào RAM. Chúng tôi đã nhận thấy một số kết quả rất lạ trên một số hệ thống của người dùng, điều này có thể được giải thích bằng lỗi hoặc do bộ nhớ bị hỏng.
Carl Seleborg

Câu trả lời:


6

Trong một quần thể máy chủ lớp 36, tôi thấy một lỗi có thể sửa được được phát hiện bởi mạch ECC cứ sau 3 tháng một lần.

Nếu bạn nghi ngờ lỗi bộ nhớ, bạn nên chạy memtest86, đi kèm với mọi phân phối linux phổ biến hiện nay.


Làm thế nào để bạn theo dõi điều đó?
Antoine Benkemoun

Hầu hết các hệ thống LOM theo dõi nó trong nhật ký của họ.
Chris S

3

Từ tỷ lệ lỗi DRAM của Robin Harris : Cơn ác mộng trên đường DIMM :

Một nghiên cứu kéo dài hai năm rưỡi về DRAM trên 10 nghìn máy chủ Google cho thấy tỷ lệ lỗi DIMM cao hơn hàng trăm đến hàng nghìn lần so với suy nghĩ - trung bình là 3.751 lỗi có thể sửa được trên mỗi DIMM mỗi năm.

Harris trích dẫn một nghiên cứu được thực hiện trong hơn 2,5 năm trên đội máy chủ của Google . Lưu ý rằng các máy chủ thường sử dụng RAM EEC, thực hiện một số sửa lỗi. Máy tính cấp tiêu dùng thường không có cái này.

Berke Durak của Lambda Diode tính toán :

Trước tiên, giả sử bạn có một hệ thống không có sửa lỗi cũng như tương đương. Xác suất bạn sẽ gặp một chút lỗi trong thời gian T sẽ là 1- (1-p) ^ m.

Trong T = 1 giờ, p = 1,3e-12 và m = 4 * 2 ^ 30 * 8 mang lại 0,044 hoặc 4,4%. Đó là một xác suất khá cao. Thật vậy, trong một ngày, điều đó dẫn đến xác suất 66% và trong 72 giờ đến xác suất 96%.

Vì vậy, xác suất có ít nhất một lỗi bit trong 4 gigabyte bộ nhớ ở mực nước biển trên hành tinh Trái đất trong 72 giờ là hơn 95%.

Tôi sẽ không cười vào lần tới khi một đồng nghiệp nói "tia vũ trụ" khi chúng tôi không xác định được nguyên nhân của một vụ tai nạn ...


2
"20% máy có lỗi chiếm hơn 90% tất cả các lỗi được quan sát", "nghiên cứu cho thấy tỷ lệ lỗi phụ thuộc vào bo mạch chủ". Tôi nghĩ rằng tôi sẽ gắn bó với sự khôn ngoan thông thường trong thời gian này. Nghiên cứu có mùi "dối trá, dối trá chết tiệt và thống kê". (chỉ 2 xu của tôi)
Chris S

2

Bạn có thể khởi động máy tính với memtest86 + và chạy kiểm tra qua đêm. Đó là cách tôi tìm thấy vấn đề.

Vâng, tôi đã thấy những ký ức trở nên tồi tệ khi chúng chỉ thất bại với một kiểu ghi nhớ cụ thể. BIOS của máy tính không phát hiện ra sự cố, nhưng memtest86 đã tìm thấy nó khi chạy qua đêm.

Tôi đã thấy hai thanh RAM bị hỏng trong khoảng năm mươi máy tính mà tôi đã sử dụng trong mười năm qua. Nó xảy ra, nhưng không thường xuyên.


Một phiếu bầu khác cho memtest86 +. Nó đi bộ nhớ của bạn từng chút một để tìm lỗi.
Dave Drager

Cảm ơn mọi người, nhưng tôi thực sự cần số liệu thống kê: sự cố không xảy ra trên máy tính của tôi, nhưng trên máy tính của người dùng (và chúng tôi có hơn 200000 người dùng).
Carl Seleborg

2

Bạn có thể muốn xem qua nghiên cứu google này :

Trung bình, khoảng một trong ba máy chủ Google gặp lỗi bộ nhớ có thể sửa được mỗi năm và một trong một trăm lỗi không thể sửa được

Nhưng họ nói về RAM ECC, không phải RAM người dùng hàng ngày của bạn


2

Tôi đã thấy một số ít các mô-đun bộ nhớ bị lỗi hoàn toàn trong các máy chủ hoạt động trong thập kỷ qua hoặc lâu hơn và số lỗi cao hơn một chút khi thực hiện ghi Memtest86 trong các thử nghiệm trên phần cứng mới được phân phối. Đây là các hệ thống máy chủ, hầu hết tất cả trong số chúng sẽ có bộ nhớ ECC loại này hoặc loại khác vì vậy tôi mong đợi các sự cố thường xuyên hơn trên các hệ thống máy khách có RAM không sửa lỗi. Mặc dù vậy, tôi không có một mẫu lớn để làm việc, chúng tôi có một vài chục máy chủ của riêng chúng tôi và về mặt vận hành hệ thống khách hàng, tôi nói rằng tôi đã làm việc ở mức một trăm ở mức độ tôi d thực sự chú ý đến RAM.

Về phía khách hàng, tôi có thêm một chút kinh nghiệm ở quy mô doanh nghiệp - Tôi là kỹ sư cao cấp cho một nhóm quản lý PC người dùng cuối 50 nghìn trong một vài năm và chúng tôi chưa bao giờ thấy lỗi RAM cứng hay mềm là một vấn đề quan trọng, chắc chắn không phải vậy một cái gì đó ảnh hưởng đến bất kỳ tỷ lệ phần trăm có thể đo lường được của các hệ thống. Điều đó không có nghĩa là nó đã không xảy ra, chỉ là tôi rất ngạc nhiên nếu đó là một vấn đề ảnh hưởng đến> 1% máy tính để bàn và máy tính xách tay hạng thương gia. Một số mô hình cụ thể sẽ chứng minh tỷ lệ thất bại thực sự cao liên quan đến kiểm soát chất lượng xây dựng, lô IBM Thinkpad T30 đầu tiên gặp sự cố với khe DIMM thứ hai của chúng dẫn đến việc chúng tôi phải sửa chữa một vài nghìn máy tại một điểm.

Bài đăng trên blog này của Microsoft Larry Osterman từ năm 2005 có thể đưa ra lời giải thích khả dĩ cho một số trong số đó - phân tích của ông về một số lỗi kỳ lạ được báo cáo trong bộ dữ liệu khá lớn xuất phát từ Báo cáo Lỗi Windows cho thấy nhiều vấn đề lạ đó là do quá mức gây ra. đồng hồ. Nếu một số lượng đáng kể người dùng cuối của bạn có khả năng đang sử dụng bộ mức độ tiêu dùng quá giờ thì điều này có thể liên quan đến lỗi của bạn.


0

Bạn có tùy chọn sử dụng 'bộ nhớ được nhân đôi' trong hệ thống của mình không - điều đó sẽ cho bạn biết bạn có vấn đề về bộ nhớ hay không - với điều đó, ít có khả năng xảy ra lỗi nào do vấn đề bộ nhớ vật lý.


Cảm ơn Chopper3, nhưng một lần nữa: câu hỏi là về thống kê. Máy tính của tôi vẫn ổn và tôi không thể yêu cầu hơn 200000 người dùng sử dụng bộ nhớ được nhân đôi :-)
Carl Seleborg

Điểm tốt, được thực hiện tốt - tuy nhiên không nhận thức được phạm vi.
Chopper3

-1

Nếu bạn đang chạy Linux:

Nếu bạn không muốn khởi động lại vào memtest86 + bạn có thể nhận được một số kết quả bằng cách chạy memtester để kiểm tra bộ nhớ để tìm xem nó có bị lỗi hay không. Nó thực sự là một công việc thực sự tốt để tìm ra các lỗi không đều cũng như với các lỗi không xác định trong đó. Nó có một số bài kiểm tra để bắt được đường biên của bộ nhớ và tạo ra một báo cáo dài dòng về các lỗi được định vị, các bài kiểm tra chạy và thời gian tìm kiếm các lỗi trong máy tính. Không cần phải khởi động lại, bạn có thể chạy nó trên hệ thống Linux đang chạy.

Tôi không tìm thấy bất kỳ liên kết nào cho ứng dụng nhưng đây là thông tin gói debian :


Tôi xin lỗi, nhưng câu hỏi của tôi không phải là về hệ thống của riêng tôi. Xin vui lòng đọc kỹ hơn.
Carl Seleborg
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.