2010-01-10 18 views
6

Tôi đang đọc tệp và tôi đã đọc một hàng dữ liệu (1600 lần đọc tuần tự là 17 byte) hoặc cột dữ liệu (1600 lần đọc 17 byte cách nhau 1600 * 17 = 27.200 byte). Tệp này nằm trên ổ đĩa cục bộ hoặc ổ đĩa từ xa. Tôi đọc 10 lần vì vậy tôi mong đợi trong mỗi trường hợp để đọc trong 272.000 byte dữ liệu.Đọc tệp qua mạng chậm do đọc thêm

Trên ổ đĩa cục bộ, tôi thấy những gì tôi mong đợi. Trên ổ đĩa từ xa khi đọc tuần tự, tôi cũng thấy những gì tôi mong đợi nhưng khi đọc một cột, tôi thấy một tấn đọc bổ sung đang được thực hiện. Chúng dài 32.768 byte và dường như không được sử dụng nhưng chúng làm cho số lượng dữ liệu được đọc nhảy từ 272.000 byte đến bất cứ nơi nào từ 79 MB đến 106 MB. Đây là kết quả sử dụng Process Monitor:

 
1:39:39.4624488 PM DiskSpeedTest.exe 89628 ReadFile \\BCCDC01\BCC-raid3\SeisWareInc Temp Dir\BPepers_Temp\Projects\PT_4\Horizons\BaseName3D_1\RR_AP SUCCESS Offset: 9,390,069, Length: 17 
1:39:39.4624639 PM DiskSpeedTest.exe 89628 FASTIO_CHECK_IF_POSSIBLE \\BCCDC01\BCC-raid3\SeisWareInc Temp Dir\BPepers_Temp\Projects\PT_4\Horizons\BaseName3D_1\RR_AP SUCCESS Operation: Read, Offset: 9,390,069, Length: 17 
1:39:39.4624838 PM DiskSpeedTest.exe 89628 ReadFile \\BCCDC01\BCC-raid3\SeisWareInc Temp Dir\BPepers_Temp\Projects\PT_4\Horizons\BaseName3D_1\RR_AP SUCCESS Offset: 9,388,032, Length: 32,768, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O, Priority: Normal 
1:39:39.4633839 PM DiskSpeedTest.exe 89628 ReadFile \\BCCDC01\BCC-raid3\SeisWareInc Temp Dir\BPepers_Temp\Projects\PT_4\Horizons\BaseName3D_1\RR_AP SUCCESS Offset: 9,417,269, Length: 17 
1:39:39.4634002 PM DiskSpeedTest.exe 89628 FASTIO_CHECK_IF_POSSIBLE \\BCCDC01\BCC-raid3\SeisWareInc Temp Dir\BPepers_Temp\Projects\PT_4\Horizons\BaseName3D_1\RR_AP SUCCESS Operation: Read, Offset: 9,417,269, Length: 17 
1:39:39.4634178 PM DiskSpeedTest.exe 89628 ReadFile \\BCCDC01\BCC-raid3\SeisWareInc Temp Dir\BPepers_Temp\Projects\PT_4\Horizons\BaseName3D_1\RR_AP SUCCESS Offset: 9,444,469, Length: 17 
1:39:39.4634324 PM DiskSpeedTest.exe 89628 FASTIO_CHECK_IF_POSSIBLE \\BCCDC01\BCC-raid3\SeisWareInc Temp Dir\BPepers_Temp\Projects\PT_4\Horizons\BaseName3D_1\RR_AP SUCCESS Operation: Read, Offset: 9,444,469, Length: 17 
1:39:39.4634529 PM DiskSpeedTest.exe 89628 ReadFile \\BCCDC01\BCC-raid3\SeisWareInc Temp Dir\BPepers_Temp\Projects\PT_4\Horizons\BaseName3D_1\RR_AP SUCCESS Offset: 9,441,280, Length: 32,768, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O, Priority: Normal 
1:39:39.4642199 PM DiskSpeedTest.exe 89628 ReadFile \\BCCDC01\BCC-raid3\SeisWareInc Temp Dir\BPepers_Temp\Projects\PT_4\Horizons\BaseName3D_1\RR_AP SUCCESS Offset: 9,471,669, Length: 17 
1:39:39.4642396 PM DiskSpeedTest.exe 89628 FASTIO_CHECK_IF_POSSIBLE \\BCCDC01\BCC-raid3\SeisWareInc Temp Dir\BPepers_Temp\Projects\PT_4\Horizons\BaseName3D_1\RR_AP SUCCESS Operation: Read, Offset: 9,471,669, Length: 17 
1:39:39.4642582 PM DiskSpeedTest.exe 89628 ReadFile \\BCCDC01\BCC-raid3\SeisWareInc Temp Dir\BPepers_Temp\Projects\PT_4\Horizons\BaseName3D_1\RR_AP SUCCESS Offset: 9,498,869, Length: 17 
1:39:39.4642764 PM DiskSpeedTest.exe 89628 FASTIO_CHECK_IF_POSSIBLE \\BCCDC01\BCC-raid3\SeisWareInc Temp Dir\BPepers_Temp\Projects\PT_4\Horizons\BaseName3D_1\RR_AP SUCCESS Operation: Read, Offset: 9,498,869, Length: 17 
1:39:39.4642922 PM DiskSpeedTest.exe 89628 ReadFile \\BCCDC01\BCC-raid3\SeisWareInc Temp Dir\BPepers_Temp\Projects\PT_4\Horizons\BaseName3D_1\RR_AP SUCCESS Offset: 9,498,624, Length: 32,768, I/O Flags: Non-cached, Paging I/O, Synchronous Paging I/O, Priority: Normal 

Thông báo các phụ đọc của 32.768 với I/O Flags thiết lập để không lưu trữ, Paging I/O, đồng bộ Paging I/O, ưu tiên: Bình thường. Những đọc thêm là những gì mang nó từ 272 KB đến 106 MB và đang gây ra sự chậm chạp. Họ không xảy ra khi đọc từ một tập tin địa phương hoặc nếu tôi đang đọc một hàng để nó tất cả tuần tự.

Tôi đã thử đặt FILE_FLAG_RANDOM_ACCESS nhưng dường như điều này không có tác dụng. Bất kỳ ý tưởng về những gì đang gây ra những lần đọc thêm và làm thế nào để làm cho họ dừng lại?

Các thử nghiệm đang được chạy trên hệ thống 64 bit của Vista. Tôi có thể cung cấp mã nguồn cho một chương trình để chứng minh vấn đề cũng như một chương trình điều khiển thực hiện các bài kiểm tra.

+1

Có thể bạn có thể dán phần mã mà bạn đọc. Điều đó sẽ loại trừ một số lỗi mã hóa, vốn phổ biến hơn lỗi nền tảng :-) – Ariel

Trả lời

2

Bạn có thể gặp phải sự cố về khóa op trên smb. Thông thường khi đọc/lưu một tập tin qua các cửa sổ mạng sẽ kéo toàn bộ tập tin vào máy khách và thực hiện gửi lại các thay đổi. Khi bạn đang làm việc với cơ sở dữ liệu tệp phẳng hoặc tệp, nó có thể gây ra những lần đọc không cần thiết trên một tệp chia sẻ smb.

Tôi không chắc chắn nếu có một cách để chỉ cần kéo trên toàn bộ tập tin, đọc các hàng từ tập tin đó trên bản sao địa phương và sau đó đẩy trở lại những thay đổi hay không.

Bạn sẽ đọc một số cơn ác mộng về khóa móc và cơ sở dữ liệu tệp phẳng.

http://msdn.microsoft.com/en-us/library/aa365433%28VS.85%29.aspx

Không chắc chắn nếu điều này giải quyết vấn đề của bạn, nhưng nó có thể giúp bạn có được chỉ trong đúng hướng. Chúc may mắn!

0

Tôi thấy điều này mọi lúc và điều đó nằm ngoài tầm kiểm soát của bạn: mạng thực hiện những gì họ muốn.

Nếu bạn biết tệp sẽ nhỏ hơn 1MB, chỉ cần kéo toàn bộ nội dung vào bộ nhớ.

0

Tôi đoán là hệ điều hành đang thực hiện đọc trước tập tin của riêng mình khi bạn tắt dữ liệu vào lúc sau. Nếu nó không làm tổn thương bạn thì nó không thành vấn đề.

Kiểm tra phần caching behavoir của API CreateFile.

Bạn có thể muốn thử 'FILE_FLAG_NO_BUFFERING' để xem liệu nó có dừng thêm lần đọc hay không. Được cảnh báo tho, sử dụng cờ này có thể làm chậm ứng dụng của bạn. Thông thường bạn sử dụng cờ này nếu bạn hiểu cách truyền dữ liệu ra khỏi ổ đĩa nhanh như bạn có thể và bộ nhớ đệm của hệ điều hành chỉ nhận được theo cách này.

Ngoài ra, bạn có thể nhận được cùng một loại hành vi như tệp mạng với các tệp cục bộ nếu bạn sử dụng cờ 'FILE_FLAG_SEQUENTIAL_SCAN'. Gợi ý cờ này cho trình quản lý bộ nhớ cache của cửa sổ những gì bạn sẽ làm và sẽ cố gắng lấy dữ liệu cho bạn trước thời hạn.

0

Tôi nghĩ SMB luôn chuyển khối, thay vì một tập hợp các byte nhỏ.

Một số thông tin về thương lượng kích thước khối có thể được tìm thấy tại đây. http://support.microsoft.com/kb/q223140

Vì vậy, bạn đang thấy đọc để sao chép khối có liên quan, theo sau là (các) đọc cục bộ 17 byte trong khối. (Nếu bạn nhìn vào mô hình, có một số cặp đọc 17 byte mà hai lần đọc nằm trong cùng một khối).

Sửa chữa rõ ràng phụ thuộc vào sự kiểm soát bạn có trên ứng dụng và kích thước và cấu trúc của cơ sở dữ liệu. (ví dụ: nếu cơ sở dữ liệu có một cột cho mỗi tệp thì tất cả các lần đọc sẽ là tuần tự. Nếu bạn đã sử dụng máy chủ cơ sở dữ liệu, bạn sẽ không sử dụng SMB, v.v.)

Nếu có bất kỳ sự an ủi nào, iTunes performs abysmally when using a network drive too.

2

Tôi đã tìm thấy câu trả lời cho điều này. Windows không đọc tập tin thông qua bộ nhớ cache trang vì vậy khi tôi đọc 17 byte, nó đầu tiên phải chuyển một trang đầy đủ của 32K hơn và sau đó có thể sao chép 17 byte tôi muốn ra khỏi bộ nhớ cache trang. Kết quả khó chịu về hiệu suất!

Điều tương tự thực sự xảy ra lần đầu tiên khi đọc được thực hiện trên một tệp cục bộ vì trong trường hợp đó, nó vẫn tải toàn bộ trang tại một thời điểm vào bộ đệm trang. Nhưng lần thứ hai tôi chạy thử nghiệm cục bộ, các tệp đều đã có trong bộ nhớ cache của trang nên tôi không thấy nó. Và nếu SuperFetch được bật và tôi đã thực hiện các thử nghiệm này một lúc, Windows sẽ bắt đầu tải tệp vào bộ nhớ cache trước Tôi thậm chí chạy ứng dụng thử nghiệm của mình để tôi không thấy trang đọc xong.

Vì vậy, hệ điều hành đang thực hiện rất nhiều thứ đằng sau hậu trường khiến việc thử nghiệm hiệu suất tốt trở nên khó khăn!