2010-07-02 45 views
11

Chúng tôi đang sử dụng File.Copy đơn giản trong C# để di chuyển các bản sao lưu cơ sở dữ liệu của chúng tôi sang các vị trí bổ sung.Tốc độ giới hạn của File.Copy

Tuy nhiên trên một số máy chủ, điều này khiến máy chủ SQL ngừng hoạt động khá nhiều. Những máy chủ này có bộ nhớ rất hạn chế, do đó, chúng thường phân trang dữ liệu ra đĩa cứng thường xuyên.

Trong khi chúng tôi nên mua thêm bộ nhớ, điều này sẽ không xảy ra trong một thời gian dài: -/

Vì vậy, tôi tự hỏi nếu tôi bằng cách nào đó có thể giới hạn tốc độ của hoạt động File.Copy? (Qua đó cung cấp cho máy chủ SQL một số phòng để truy cập đĩa cứng)

Tôi có thể sử dụng phương pháp "trường học cũ" với hai luồng, đọc và viết qua bộ đệm và chỉ cần ngủ 5 phút hoặc hơn. Nhưng tôi thực sự thích một giải pháp neater, nếu như vậy là có sẵn.

+0

Bạn có muốn giới hạn tốc độ hoặc trên thực tế bộ nhớ không? – Frank

+0

Bạn đã thử chạy mã Sao chép trên chuỗi có 'mức độ ưu tiên tối thiểu' chưa? Bạn không chắc chắn nó sẽ giúp mặc dù nó sử dụng hàm kernel32 'CopyFile'. –

+0

Chỉ cần không thực hiện sao lưu vào cùng một ổ đĩa như một máy chủ SQL đang sử dụng cho dbase của nó. –

Trả lời

7

CopyFileEx có thể làm những gì bạn cần - nó có một hàm callback mà bạn có thể sử dụng như là một nhân tạo slowing method (đã không cố gắng mà cho kịch bản này mặc dù vì vậy tôi không chắc chắn về các hiệu ứng thực - đáng thử IMHO).

+0

Tôi có thể cho rằng một đi - Tôi sẽ xem nếu MSDN có một số thông tin thêm về gọi lại (thường xuyên nó được gọi là như vậy) – Steffen

+1

Nó phải là cách nhanh hơn so với sử dụng C# suối. Bộ đệm là ** 65536B ** trên WXP (thông báo xảy ra khi đoạn được sao chép). Trên Vista và W7, nó lớn hơn. Bạn cũng có thể sao chép tệp chỉ vào 1 máy và sao chép tệp từ đó đến các vị trí sao lưu khác. –

+0

Âm thanh tốt, mối quan tâm chính của tôi với luồng thực tế là hiệu suất của nó so với chức năng API gốc (File.Copy cũng là: CopyFile) Tôi sẽ kiểm tra vào thứ ba, vì tôi không thể để làm việc trên nó sớm hơn. – Steffen

2

Bạn đã cố gắng ưu tiên cho quy trình sao chép của mình dưới mức bình thường chưa? Bạn có thể làm như vậy thông qua Task Manager hoặc sử dụng start lệnh:

> start myCopyApp.exe /BELOWNORMAL 
+3

Điều đó sẽ hoạt động nếu hệ thống bị ràng buộc CPU, nhưng có thể không nếu nó là I/O-ràng buộc? – ChrisW

+0

Khi các tiểu bang OP 'Các máy chủ có bộ nhớ rất hạn chế', tôi sẽ giả định nó không phải là những, nhưng hạn chế bộ nhớ. – Frank

+0

@Frank Tôi nghĩ rằng hạn chế bộ nhớ gây ra truy cập đĩa (vào tệp hoán đổi), và do đó tương đương với I/O-ràng buộc. – ChrisW

2

Không có sẵn thông qua File.Copy. Bạn có một số tùy chọn khác. Bạn có thể, như bạn nói, truyền các byte qua thủ công, thỉnh thoảng ngủ. Bạn có thể sử dụng một triển khai BITS, mặc dù đây là một chút OTT.

Ngoài ra, nếu sự cố là bộ nhớ - hãy nén tệp hoặc chia nhỏ tệp thành các tệp nhỏ hơn để được xây dựng lại sau.

+1

Lưu ý: đối với SQL Server 2008+, bạn có thể bật nén bản sao lưu trong trang "Sao lưu cơ sở dữ liệu". –

+0

Cuộc gọi tốt với nén, tuy nhiên chúng vẫn bị mắc kẹt với SQL Server 2005 :-( – Steffen

1

Tôi có thể sử dụng phương pháp "trường học cũ" với hai luồng, đọc và viết thông qua bộ đệm và chỉ cần ngủ 5 phút hoặc giữa các lần đọc.

Nếu bạn làm như vậy, hãy xem bằng cách sử dụng cờ FILE_FLAG_NO_BUFFERING: nếu bộ đệm ứng dụng của bạn nhỏ đến mức nào, hệ thống tệp sẽ được lưu vào bộ đệm (và do đó gây thêm hoán đổi).

+1

Vì bộ nhớ đệm sẽ được sử dụng rất nhiều, Windows * nên * không trao đổi phần bộ nhớ đó (+ nó có dấu chân bộ nhớ khá nhỏ) Ngoài ra, các hoạt động của CPU và đĩa IO sẽ tăng đáng kể –

+0

@Jaroslav Jandek - FILE_FLAG_NO_BUFFERING trên các tệp đầu vào và đầu ra sẽ ảnh hưởng/vô hiệu hóa bộ đệm (ví dụ: bộ đệm đọc trước). Tôi gợi ý rằng bộ đệm này nên bị vô hiệu hóa, bởi vì hệ thống tập tin đệm này được kích hoạt (mặc định là nó) sẽ mất bộ nhớ và do đó gây ra sự hoán đổi, và anh ta thậm chí không cần nó (vì một bản sao tệp chỉ muốn chạm vào từng phần của tệp một lần) – ChrisW

+0

@ChrisW: Bạn cần đọc dữ liệu một cách dễ dàng tái (vào một bộ đệm) và sau đó ghi vào một tập tin (có thể được unbuffered - viết trực tiếp). Nếu hoạt động sẽ không được tuần tự, bộ đệm sẽ bị lãng phí. Trong trường hợp này, nó là cần thiết không có vấn đề gì. Để sao chép, cách tiếp cận đó là vô ích vì hệ thống đã thực hiện điều đó một cách hiệu quả (nếu bạn đang làm ReadFile và WriteFile theo cách thủ công, nó sẽ khác). Ngoài ra nó sẽ đòi hỏi rất nhiều xử lý WINAPI và kích thước bộ đệm chính xác và liên kết, cho nhiều lĩnh vực của hệ thống tập tin ... –

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